# rules.yml The **Rules** file allows you to craft truly modular **Custom Rules** which either modify or extend the **Default Rule** which is applied at the start of LevelledMobs' processing cycles. The file is broken into three major sections: **Presets**, **Default Rule**, and **Custom Rules**. This documentation is meant to provide a general understanding of each of these sections. ## Modular Options The entire premise of LevelledMobs3+ has been it's use of a *modular option* system consisting of three main components: **Conditions**, **Strategies**, and **Settings**. Each of these **Modular Options** are documented in their own sections. The premise behind how LevelledMobs functions is that you instruct how it will level mobs with a baseline setup established through the **Default Rule**. These instructions are given in the form of *conditions*, *strategies*, and *settings*. You need to first **Condition** what LevelledMobs would consider a valid target. This might including limiting the *worlds* or *entities* which are affected, or targeting mobs from specific external plugins. Then you should establish your **Settings**, or how you want LevelledMobs to modify these mobs. This typically includes a max level, nametag, custom drops, etc. Finally, you need to establish your **Strategy**, which will provide LevelledMobs the tools to determine how to assign a level to the mob to get the process of attribute and equipment modifications rolling. ## Presets LevelledMobs allows you to craft certain sets of configuration options into reusable sets known as **Presets**. These **Presets** can be applied within either the **Default Rule** or any **Custom Rules** utilizing the `use-preset:` configuration option. Here is an sample of the **Presets** section of the config, including all potential pieces of the preset, as it is formatted within the `rules.yml`. {% code title="rules.yml" overflow="wrap" %} ```yaml presets: preset-Name: name: 'Preset Name or Description' conditions: x: strategies: x: modifiers: x: settings: x: ``` {% endcode %} The `presets:` section of the `rules.yml` covers the upper third of the file, and we use this section by default to populate many of the **Default Rule** and **Custom Rules**. This area is meant to be an aid in preventing duplicate configration options being applied in a similar but redundant way over multiple **Custom Rules**. You do not need to use the **Presets**, but it's highly recommended and it gives you an easy to reference area for over 90% of our features which are included out-of-the-box. Referencing the code above:
presets:The start of the Presets section of the file.
preset-Name:The unique name of the preset, to be referenced in use-preset:.
name:The unique description or name of the preset, only used for debug.
conditions:
strategies:
modifiers:
settings:		The possible options which can be included as part of the preset. Any one or combination of these Modular Options are acceptable pieces of any preset.
x:Any sub-setting of the respective Modular Options.
You can apply a **Preset** to either the **Default Rule** or to any **Custom Rule** via the `use-preset:` configuration option. Below are samples of both usages: {% code overflow="wrap" %} ```yaml default-rule: use-preset: - presetName - otherPresetName custom-rules: - enabled: true name: 'Sample of Custom Rule Presets' use-preset: presetName, otherPresetName ``` {% endcode %} ## Default Rule LevelledMobs requires the **Default Rule** to be populated with certain minimal information in order to have a minimum amount of functionality. By default, we use the **Presets** system to populate many of these options. The plugin needs to know what *world* and what *mobs* the plugin can function on; by default if no *world* or *mob* is specified, then the system will presume it does not have access to any *world* or *mob*, effectively disabling it. The second necessary information would be at least one enabled *levelling strategy*. This will inform LevelledMobs how it will calculate the level output for each mob. The final necessary information would be the min-level (suggested to be `1`) and max-level of the mob and any attribute-modifiers that would apply. There are several other optional but suggested features that we encourage you to have enabled by default, such as some form of nametag or the Custom Drops system. Here is a sample of what a **Default Rule** might look like with all the minimum information populated: {% code overflow="wrap" %} ```yaml default-rule: conditions: worlds: included-list: ['*'] entities: included-list: ['*'] strategies: weighted-random: true settings: minLevel: 1 maxLevel: 25 attribute-modifier: max-health: 5.0 movement-speed: 0.15 attack-damage: 2.25 item-drop: 3 xp-drop: 5 nametag: '&8&l༺ &f%displayname%&8 | &f%entity-health-rounded% &8&l༻' ``` {% endcode %} ## Custom Rules LevelledMobs comes out-of-the-box with several **Custom Rules** which were enabled by default. This plugin has many years of player-tested and developer experiences under it's belt, allowing us to craft a configuration which casts the widest net from the start in terms of challenge spread and feature-set. Some of the default custom rules are designed to reduce the challenge of certain mobs that are themselves challenging even under vanilla conditions, or to customize the boss and mini-boss type mobs, or to monitor mob farming and reduce boosted drops accordingly. All of these tests are done under Minecraft's Normal difficulty under average server conditions. Here is a sample of what any **Custom Rules** might look like with the all possible options: {% code overflow="wrap" %} ```yaml custom-rules: - custom-rule: 'A Sample Custom Rule' is-enabled: true use-preset: conditions: x: strategies: x: modifiers: x: settings: x: ``` {% endcode %} Referencing the code above:
custom-rules:The start of the Custom Rules section of the file.
- custom-rule:Marks the start of a new Custom Rule.
The unique description or name of the custom rule, only used for debug.
is-enabled:Allows for a rule to be enabled or disabled quickly.
use-preset:Include any preset of the Presets section.
conditions:
strategies:
modifiers:
settings:		The possible options which can be included as part of the preset. Any one or combination of these Modular Options are acceptable pieces of any preset.
x:Any sub-setting of the respective Modular Options.
## Included and Excluded Lists Several **Modular Option Conditions** can be expressed by using various *included* and *excluded* list or group options. The sample below represents all possible list options:\ Note: `x:` represents the various available sub-setting of the respective **Modular Option Conditions**. {% code overflow="wrap" %} ```yaml conditions: x: included-group: [''] included-list: [''] excluded-group: [''] excluded-list: [''] merge: false ``` {% endcode %} These list options are fairly simple to read. You can specify either one *included list* or *excluded list* and one *included group* or *excluded groups* when using the lists (only `entities:` and `biomes:` accept *group* type lists). For any option, you can use `*` to signify all available options. You can also include `merge: true` alongside any listed entry, which would mean that the custom rule will accept any other `conditions:` of the same defined type from the `default-rule:` as a part of the acceptable conditions. It will also accept any prior custom rule's `conditions:` of the same defined type where the same entity successfully took on that rules' settings before proceeding. This essentially means that any list option which uses `merge: true` is taking the `conditions:` set for that setting in the rule, as well as any previously successful application of that condition on the same entity, and combine the list of `included-list:` and `excluded-list:` options into one larger list. This is a more advanced-user option and not recommended for the average user. If you use both `included-list:` and `excluded-list:` as part of the same `conditions:` check, then the `included-list:` will be read and `excluded-list:` will be ignored, as only listening to the *included list* is more explicit. Below are several examples of to use a list-option: ### Example: How to use lists *** **Example One:** If you want the **Condition** to check whether the biome where the entity is was the Ice Spikes or Deep Dark biomes, you would use the `included-list:`, meaning the list will only allow those which are being processed in those established biomes to meet the **Condition**. {% code overflow="wrap" %} ```yaml conditions: biomes: included-list: ['ICE_SPIKES', 'DEEP_DARK'] ``` {% endcode %} **Example Two:** If you want the **Condition** to check for mobs in all accessible worlds, except for the default `world_the_end` world, then you would use `excluded-list:`, meaning the list will allow all worlds except for the world you excluded from meeting the **Condition**. {% code overflow="wrap" %} ```yaml conditions: worlds: excluded-list: ['world_the_end'] ``` {% endcode %} **Example Three:** If you want the Condition to apply to the `all_passive_mobs` group, but want to skip the birds, the bees, donkeys, and mules, you would use a combination of `included-groups:`, `excluded-groups:`, and `excluded-list:`.\ First you would allow the all passive mobs group to meet the Condition check, then remove the all flying mobs group to cover the birds and bees, then you would remove the individual entities of the donkeys and mules. 
conditions:
  entities:
    included-groups: ['all_passive_mobs']
    excluded-groups: ['all_flying_mobs']
    excluded-list: ['DONKEY', 'MULE']
***