-
Notifications
You must be signed in to change notification settings - Fork 0
Basic Configuration
Configuring SolusRpg is as straight forward as I could possible make it, considering it's extensive features. I've even gone so far as to include a stock file containing all the classes that I use on the server I am currently working for as lead tech admin. However, for the purpose of this tutorial, I will be starting from scratch.
If you looked at the Directory Map on the Installation page, you already know where to put the main configuration file. It belongs in plugins/dbstudios/SolusRpg/config/ with the name config.yml. Using your favorite text editor (I would suggest Notepad++ in YAML mode), open config.yml. On the first line, type:
config:
Then press enter, and indent twice.
At the moment, SolusRpg only supports setting one of many default values. In the future, more will be added.
Each config.yml should have a default-class node set as such:
config:
default-class: Classless
This will define what class a player who has not been given a class should be.
SolusRpg uses deny message nodes, configurable in config.yml, to notify a player when they do something their class cannot do. As Solus expands, these messages will include everything that SolusRpg will tell a player. They can include anything you'd like, just be sure to keep them relevant to their subject, since they're the only indication to a player that they can't perform an action.
At the moment, the only configurable messages are those that fire on deny events. They are named following the pattern <event>-deny. So, for example, a complete message configuration would look like this:
config:
*snip*
messages:
place-deny: "{aqua}You may not place {item}..."
use-deny: "{green}You cannot use {item}..."
break-deny: "{AQUA}You may not break {item}..."
wear-deny: "{gold}You may not wear {item}..."
wear-deny-item-drop: "{GOLD}Your inventory was full, so your {item} was dropped..."
craft-deny: "{dark_aqua}You may not craft {item}..."
smelt-deny: "{dark_aqua}You may not place {item} in a furnace..."
Most of these are pretty self explanatory. The only node that may be confusing is the wear-deny-item-drop. This will be displayed to the user when they try to wear something they are not allowed to, but Solus can't put it back into their inventory because it is full. In that case, the item is dropped at their feet.
Also, you'll notice that the lines are encased in "double quotes". This is because each one starts with a color tag (which will be explained in a moment), and YAML does not support starting lines with a curly brace. As an important caveat, it's general good practice to enclose strings in double quotes, since it will prevent YAML from complaining if there is something it doesn't like in your string.
In addition to messages, Solus also supports configuring the default color of command output. The name of the node (list, skill, stats, etc) is also the command's label (i.e. /list matches up with the list node).
config:
*snip*
messages:
*snip*
colors:
info1: AQUA
info2: Green
list: aqua
skill: gold
stats: dark_aqua
sr: dark_red
help1: GREEN
help2: dark_green
For command labels with numbers after them, the higher the number, the less important the color will be in the command output. <command>1 will always be the emphasis color, and all subsequent colors for that command will be less and less emphasized. Currently, the values above are the only accepted command color nodes.
SolusRpg supports special tags in it's messages. You can view a complete list on the Message Tags page.
Basically, any color value supported by Bukkit can appear in these tags. Simply surround your desired color in {curly braces}, place it in the text where you want the color to begin, and profit! In the earlier message configuration example, you'll notice color tags are kinda thrown around and aren't following any specific pattern (capitalization, etc). This was meant to show that so long as it's spelled correctly, Solus will be able to interpret it.
Also, there are some other tags, such as {player} and {item}, which are kind of self explanatory. Again, for a complete definition of each of the available tags, see the Message Tags page.
Skills to be loaded are defined under the config.skills node in config.yml. This is, simply put, and list of the system names of the skills you wish to have Solus load when it is enabled. Generally, a system name is the skills name minus any spaces or punctuation, but you should check the developer's documentation to be sure. A generic skills node might look something like this:
config:
*snip*
skills:
- FrostTomb
- Vampirism
- Photosensitivity
- Dash
Each skill, regardless of whether or not it is an active or passive skill, or what class will get the skill, must be defined here.
Next, each class has their own list of skills, divided into two categories, active and passive. Setting up skills for each class, however, will be covered in Part 7: Creating Classes.
SolusRpg allows you to define different "weights" for armors, which is different then an item weight in your inventory. The special weights, which are listed under the config.speeds nodes, allow you to modify a player's speed based on what armor they currently are wearing. The speeds nodes follow the pattern: config.speeds.<armor-type>.<armor-piece>. So, to set the speed reduction of an iron helmet, you would change the node at config.speeds.iron.helmet. An example of the speeds node block would look like this:
config:
*snip*
speeds:
leather:
helmet: 2
chestplate: 4
leggings: 2
boots: 2
chainmail:
helmet: 3
chestplate: 6
leggings: 3
boots: 3
iron:
helmet: 9
chestplate: 18
leggings: 9
boots: 9
gold:
helmet: 1
chestplate: 2
leggings: 1
boots: 1
diamond:
helmet: 5
chestplate: 10
leggings: 5
boots: 5
Note that if no speed is defined, Solus will not slow the wearer. An absent node is equivalent to a 0.
When calculating armor speed, the values at the nodes that correspond to what the player is wearing are totaled, then subtracted from 100%. The resulting percentage is then multiplied by the players current speed (thus taking away a percentage of their max speed).
SolusRpg also supports max inventory weights, and configurable, per item weights. Item weights, and certain default values, are defined under config.item-weights in the config file.
config:
*snip*
item-weight:
default: 0.01
overweight-slow: 35.0
BEDROCK: 0.0
BOOKSHELF: 1.0
BREWING_STAND_ITEM: 5.0
BRICK: 0.5
BRICK_STAIRS: 1.25
*BIG snip*
In the above example, default is the default value for any item whose weight is not defined in the file. overweight-slow is the percentage to slow a player who has exceeded their max carrying weight. Everything else, BEDROCK, BOOKSHELF, BRICK, etc., is the Material Enum of the corresponding item, followed by a weight value.
Creating a class is relatively simple. First, you'll need to define the class sub-section:
config:
*snip*
classes:
This section contains all of your class definitions. It is important that all classes are defined in this section, and this section only. Any class not listed here cannot be loaded by Solus.
Next, you will need to set your classes name and bio. Since YAML does not support spaces in path nodes, you can use the name directive to define the true name of the class. For example, if I was creating a class called Engineer Tyler, I would have to define it like this:
config:
*snip*
classes:
EngiTyler:
name: Engineer Tyler
bio: Lead Redstone engineer for the Kree
The name used to define the section is not important; the only time it will ever be used is when you are assigning a class to a player. The name defined after the name directive, however, is the display name for that class. Any time the player is shown their class's name, they will see that, rather then it's path name. The bio directive is merely a short blurb about the class. You can include anything you want here, including color tags.
Our next step is to define how the player is allowed to interact with the world. For example, what a player with this class can wear, break, or smelt. This is done by using permit nodes, denoted by can-<node>. For example, lets say we want the Engineer Tyler class to be able to wear only leather armor. This could be done by defining each leather armor piece in the permit node can-wear.
config:
*snip*
classes:
EngiTyler:
*snip*
can-wear:
- LEAHTER_HELMET
- LEATHER_CHEASTPLATE
- LEATHER_LEGGINGS
- LEATHER_BOOTS
This is perfectly valid. The above configuration will allow this class to only wear the armor pieces defined above. However, it would become tedious to type this, or even copy and paste all four lines for every class. For this reason, I designed the Item Group system, which will be covered in depth later on, in the Advanced Configuration tutorial.
You will need to repeat the above step for each of the permit nodes, can-wear, can-break, can-place, can-smelt, and can-craft. Each one is rather self explanatory.
Next will be the health system. SolusRpg supports per class health values and names, in order to allow for greater class diversity. For this example, I will be creating a new class, Berserker, who has greatly buffed health, a rage meter, a buffed damage output, and a lower damage resistance. Here's our current class setup.
config:
*snip*
classes:
Berserker:
name: Berserker
bio: A fierce warrior, the Berserker will not stop fighting until he lies broken and beaten atop the bodies of his foes.
As his bio states, the Berserker focuses more on the fight at hand then his own safety. Because of this, he can take more of a beating while dishing out massive damage, much more then any other class. We'll start with modifying his health, so he can stay in battle longer.
config:
*snip*
classes:
Berserker:
*snip*
health:
name: Health
max: 40
regen:
enabled: true
delay: 200
amount: 2
degen:
enabled: false
Let's take a look at the new sub-section we just added.
The name node defines what this classes health meter will be called. In this example, our Berserker's health will simply be called "health", but this can be anything; a vampire could live on Blood for their health, or a peasant could have their health display as "life force".
Next, we have the max node. This defines the classes max health. Keep in mind that the default Minecraft health is 20. In this case, without any other modifiers, our Berserker class can already absorb twice as much punishment as the normal Minecraft player can.
After that is the regen and degen nodes. Both are fairly self explanatory; regen defines the rules for an additional health regen (in addition to the stock Minecraft health regeneration that works with the hunger system) and a passive degeneration of a class's health.
Regeneration, at the moment, follows a very simple rule set. If the enabled node is set to true, Solus will wait for delay number of ticks before incrementing the class's health by the amount defined by amount. In the future, more advanced options will be available, such as the ability to set conditions for the regeneration to begin.
Now, on to the energy system. Since this is a Berserker class, lets say that his abilities will require Rage to cast.
config:
*snip*
classes:
Berserker:
*snip*
energy:
name: Rage
max: 100
regen:
enabled: true
delay: 100
amount: 25
degen:
enabled: false
The above works just as the health system does, except it will affect the energy meter of this class, rather then the health meter. This system is current in development, however. Though your class will display the accurate energy and will regenerate/degenerate according to your configuration, there is currently no use for such as feature until the skill system is implemented in the next update.
Next, let's modify the Berserker's stats. Since he is such a crazed warrior, he deals more damage then a normal player, but will also take more damage on each hit. Since he doesn't care about his own safety, he is able to push his body's limits further then that of a normal man, allowing him to run slightly faster, carry more, and jump a bit higher. Let's take a look at how that's achieved.
config:
*snip*
classes:
Berserker:
*snip*
stats:
damage-dealt: x2.5
damage-taken: x1.75
speed: x1.25
jump-height: x1.5
max-weight: 500
The above values will have these effects, going from the top value to the bottom: multiply the damage dealt by this class by 2.5, multiply the damage taken by 1.75, multiply the base movement speed by 1.25, multiply the base jump-height by 1.5, and set the max carrying weight of this class to 500.
And that's all. Once you're done, be sure to restart your server, if it was running when you edited the file.
<=== Back to Installation | Basic Configuration | Go to Useful Commands ===>