Documentation rules.yml

This page was last updated for LevelledMobs 3.14.0 b811

---

Rules Configuration

LevelledMobs' rules.yml file allows you to craft truly modular Custom Rules which either modify or extend the Default Rule that are applied to any and all EntityTypes. The rules file is broken into three major sections: Presets, Default Rule, and Custom Rules. This documentation provides a general understanding of how the rules file works.

For more details, learn how to use the different conditions, strategies, and apply-settings.

For a collection of sample custom rules, check out this link here.

---

Universal Mob Groups:

LevelledMobs includes several groups of entities which are bundled together in a convenient to recognize format. Each of these groups function as their own EntityType when using allowed-groups: or excluded-groups:, which allows you to select multiple entities at once. You can include as part of the conditions an included-list: or excluded-list: to make an exception to a specific entity within the group.

You can also craft your own entity or biome custom groupings within the rules file at the top. Only the Universal Groups work within the custommdrops.yml file, not custom groups.

EntityType Universal Groups	Description
all_mobs	All entities whether they are levelled or not.
all_levellable_mobs	All entities which have been levelled.
all_hostile_mobs	All hostile entities, whether they are levelled or not.
all_passive_mobs	All passive entities, whether they are levelled or not.
all_overworld_mobs	All Overworld entities, whether they are levelled or not.
all_nether_mobs	All Nether entities, whether they are levelled or not.
all_flying_mobs	All flying entities, whether they are levelled or not.
all_ground_mobs	All ground-limited entities, whether they are levelled or not.
all_aquatic_mobs	All aquatic entities, whether they are levelled or not.

---

Presets:

LM allows you to craft certain sets of configuration options into reusable sets known as Presets, which can be applied within either the Default Rule or any Custom Rules utilizing the use-preset: config line. We make use of the presets: section heavily in the default-rule:, as it makes things far easier to switch between and then configure.

For example, a Custom Rule which utilizes the use-preset: config option:

custom-rules:
  - enabled: true
    name: 'Custom Rule Name or Description'
    use-preset: presetName, otherPresetName
    #Or
    use-preset:
      - presetName
      - otherPresetName

Another example, how to create your own Preset:

presets:
  presetName:
    name: 'Preset Name or Description'
    conditions:
    strategies:
    apply-settings:

The Presets section covers the first third of the file, and by default it is used to mostly populate the Default Rule with multiple different out-of-the-box solutions to common features. You can edit or add your own presets to the list, or choose to not use the preset system at all. This is meant to be an aid in preventing duplicate text across the rules file in situations where you'd like to incorporate most or all of a preset into a Custom Rule.

When crafting a preset, the above structure should be followed. Beginning with the presets: tag to start that section, for each preset you want to create, you would need to indent two spaces and then give your preset a name to reference later, replacing presetName: with this value. Make sure to only use alphanumeric values, without spaces, for this value. For each subsequent preset, simply create a new presetName: section and repeat the process. On each preset you should give easy-to-read name: config option, providing an easy to understand name or short description of the preset being created. While this is not required, you will thank yourself later. It makes debug systems much easier to understand, and reading your rules.yml file far quicker. Then you want to provide the content of the preset; we have included all three conditions:, strategies:, and apply-settings: from which the formatting and such should match the formatting as displayed in the rules elsewhere or the wiki here. You can include any single, multiple, or all of the systems listed above as part of the preset.

Default Rule:

LM requires this section to be populated with the following minimal information in order to work with a minimum of functionality and to prevent downstream issues. By default, LM uses the Presets system explained above to populate the Default Rule with most of the necessary values, plus several more, in order to make things quick and easy to switch between preconfigured settings.

Below represents the minimum of information LevelledMobs requires for all of it's main systems to function. It first needs to know what worlds it is allowed to function in. If this is not specified in the default rule, then LevelledMobs will assume that it is not allowed in any worlds, essentially disabling the plugin. The next necessary information is to tell LevelledMobs how it needs to determine the level of entities by establishing it's levelling strategies:. If this is not specified, LevelledMobs will still attempt to function by defaulting to random:; however this is known to not be fully compatible with custom rules which are checking against an unspecified value. Also, you must use an established Levelling Strategy and not a Level Modifier Strategy by itself; Only a Levelling Strategy can establish a level, while a Level Modifier Strategy can only modify an existing level. The final bit of information LevelledMobs is required to know to function is the minLevel: and maxLevel: that entities are expected to level as a baseline setup for all mobs, which can then be modified later for specific conditions: with custom-rules:. You will also need to establish your multipliers:, or how much LevelledMobs will adjust things like entity health, attack damage, movement speed, etc. The last thing to note would be the nametag: configuration option. While this is not necessary for LevelledMobs to apply levels to entities, it is necessary for the packet based nametags to display the names, levels, etc. of the entities to players. If left to the default entity names, they will be automatically translated for each players' set Minecraft client language (though you can craft your own custom names).

default-rule:
  conditions:
    worlds:
      allowed-list: ['*']
    strategies:
      random: true
    apply-settings:
      minLevel: 1
      maxLevel: 25
      multipliers:
        max-health: 5.0
        movement-speed: 0.15
        attack-damage: 2.25
        ranged-attack-damage: 2.0
        creeper-blast-damage: 1.0
        item-drop: 3
        xp-drop: 5
      nametag: '&8&l༺ %tiered%Lvl %mob-lvl%&8 | &f%displayname%&8 | &f%entity-health-rounded% %tiered%%heart_symbol% &r%health-indicator% &8&l༻'

Custom Rules:

LM comes out-of-the-box with several different Custom Rules which are enabled by default. LevelledMobs has the benefit of having years of player and developer testing under it's belt. The default custom rules have been play tested and adjusted and experimented with in such a way to improve the average server experience: preventing mob farm abuse or breakage, prevent mob specific characteristics from being overwhelming (an example being the reduced Enderman movement-speed: multiplier, due to their teleporting ability making them extra deadly to players even at low level), provide example rules which like the rest of the system can be copied and entirely modified to suite your servers' needs. We simply tested the server under average conditions and expectations and leave the customizations to you, providing many examples in the rules.yml and here on the wiki.

Below represents the basic framework of a Custom Rule:

custom-rules:
  - enabled: true
    priority: 1
    name: ''
    use-preset: 
    conditions:
    strategies:
    apply-settings:

Config Line Option	Description
- enabled:	This represents whether the custom rule is enabled or disabled.
priority:	This value overrides the custom rule's processing order (see below).
name:	This represents an easy-to-read name or description of the Custom Rule for debug purposes.
use-preset:	This allows you to use a Preset within a Custom Rule.
conditions: strategies: apply-settings:	These are elaborated on further here.

Any detail not specifically listed within the custom rule will gather that information from the Default Rule when constructing the final custom rule. For example:

default-rule:
  conditions:
    worlds:
      allowed-list: ['*']
    entities:
      allowed-list: ['all_mobs']

custom-rules:
  - enabled: true
    name: 'Disable Passive Entities'
    conditions:
      entities:
        allowed-list: ['all_passive_mobs']
    apply-settings:
      maxLevel: 0

The way the above structure is read, starting from the default rule: All worlds are levellable, and all entities are levellable based on the Default Rule. When the custom rule was crafted, I did not need to specify what world the rule would apply to, since it grabs the value 'all worlds' from the Default Rule. I do however, have to specify the entities, because if I didn't the custom rule would apply to 'all entities' as stated in the Default Rule. Finally, I have applied the level 0 which disables levelling to the passive entities in all worlds.

Priority:

By default, LM processes the rules in a linear order: from top to bottom; from the Default Rule to the first through last Custom Rule. You can establish a priority config line within a custom rule which will override it's position in the queue, allowing it to process earlier or later than the rest of the stack. Remember that the Default Rule will ALWAYS process first before any Custom Rules to populate any necessary default values.

Below represents an example of how priority alters the 'stack queue' of Custom Rules:

custom-rules:
  - enabled: true
    name: 'Run before the stack, as the highest priority, as the first rule processed after the Default Rule'
    priority: 2

  - enabled: true
    name: 'Run before the stack, after any higher priority'
    priority: 1

  - enabled: true
    name: 'Run the queued stack (same as not listing priority)'
    priority: 0

  - enabled: true
    name: 'Run the queued stack (same as priority: 0)'

  - enabled: true
    name: 'Run after the stack, before any lower priority'
    priority: -1

  - enabled: true
    name: 'Run after the stack, as the lowest priority, at the very end'
    priority: -2

---

Modal-List Config Options:

Note: Most conditions: utilize a Modal-List to configure it.

Below demonstrates how to use the Modal-List feature:

conditions:
  condition:
    allowed-list: ['']
    allowed-groups: ['']
    excluded-list: ['']
    excluded-groups: ['']
    merge: true

The Modal-List config option is fairly simple to read, as they're used exclusively within the Conditions section. If a config option requires a Modal-List to be used, you can specify either one allowed or excluded list and one allowed or excluded groups when using the condition entities:. If you use both allowed-list: and excluded-list: as part of the same conditions: check, then the allowed-list: will be read and excluded-list: will be ignored, as allowed is more explicit. Below are several examples of to use a Modal-List:

Example: If you want the Condition to check whether an entity is a zombie, husk, or skeleton, you would use the allowed-list:, meaning the list will only allow those which you have approved to meet the Condition.

conditions:
  entities:
    allowed-list: ['ZOMBIE', 'HUSK', 'SKELETON']

Example: If you want the Condition to apply to all worlds, except for the default world_the_end, then you would use excluded-list:, meaning the list will allow all worlds except for the world you excluded from meeting the Condition.

conditions:
  worlds:
    excluded-list: ['world_the_end']

Example: 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 allowed-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:
    allowed-groups: ['all_passive_mobs']
    excluded-groups: ['all_flying_mobs']
    excluded-list: ['DONKEY', 'MULE']

The groups feature Modal-List will be accepted on biomes: (referencing the custom biome group maker at the top of the rules.yml file) and entities: (referencing both the universal mob groups and the custom entity group maker at the top of the rules.yml file).

You can also include merge: true which which means that the custom rule will accept any other conditions: of the same 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 type where the same entity successfully took on that rules' settings. This essentially means that any Modal-List 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 allowed-list: and excluded-list: options into one larger list. This is a more advanced-user option and not recommended for the average user.