🌟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.

rules.yml

presets:
  preset-Name:
    name: 'Preset Name or Description'
    conditions: 
      x: 
    strategies: 
      x: 
    modifiers:
      x: 
    settings: 
      x: 

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:

default-rule:
  use-preset:
    - presetName
    - otherPresetName

custom-rules:
  - enabled: true
    name: 'Sample of Custom Rule Presets'
    use-preset: presetName, otherPresetName

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:

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༻'

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:

custom-rules:
  - custom-rule: 'A Sample Custom Rule'
    is-enabled: true
    use-preset: 
    conditions: 
      x: 
    strategies: 
      x: 
    modifiers:
      x: 
    settings:
      x: 

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.

conditions:
  x: 
    included-group: ['']
    included-list: ['']
    excluded-group: ['']
    excluded-list: ['']
    merge: false

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.

conditions:
  biomes:
    included-list: ['ICE_SPIKES', 'DEEP_DARK']

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.

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

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']

---