👾Sample Custom Rules

Below are a collection of sample Custom Rules which you can implement into your LevelledMobs4 Rules file. Each rule provides a general description of what it accomplishes, and how you might use it on your own server.

---

Deny a Level to Specified Mobs

  - custom-rule: 'Deny Level to Specified Mobs'
    is-enabled: true
    conditions:
      entities:
        included-list: ['BABY_']
        included-groups: ['all_passive_mobs']
    settings:
      maxLevel: 0

This rule has a conditions check for the specified entities , using included-list: to specify individual mob types (with BABY_ representing all Baby type entities), and included-groups: to specify a universal mob group of entities.

Custom Mob Stat Changes

  - custom-rule: 'Custom Ender Dragon Stats'
    is-enabled: true
    conditions:
      entities: ['ENDER_DRAGON']
    settings:
      attribute-modifier:
        max-health: 5.0
        xp-drop: 10.0
        item-drop: 2.0
        attack-damage: 2.5
        ranged-attack-damage: 1.0

This rule provides a custom set of attribute modifiers for the Ender Dragon mob.

Use Boss-Bar Style Health Indicators for Nametags

A sample of the output of this rule on mobs.

  - custom-rule: 'Boss-Bar Style Nametags'
    is-enabled: true
    settings:
      nametag: '%health-indicator%'
      health-indicator:
        indicator: '█'
        indicator-half: '▌'
        scale: 6
        max: 10
        colored-tiers:
          tier-1: '&#22E76B' #Green
          tier-2: '&#528CFF' #Blue
          tier-3: '&#FFCD56' #Yellow
          tier-4: '&#FE803C' #Orange
          tier-5: '&#F2003D' #Red
          tier-6: '&#B447FF' #Purple
          default: '&#FFFFFF' #White

This custom rule lacks a condition, so it would apply to any mob which was levelled at the point of this rule taking place; you can add your own conditions to limit this.

Unique Mob name based on it's level

  - custom-rule: 'Level dependent custom names'
    is-enabled: true
    settings:
      entity-name-override:
        1-5:
          all_entities: ['Teething %displayname%']
        6-10:
          all_entities: ['Scratching %displayname%']
        11-20:
          all_entities: ['Biting %displayname%']
        21-25:
          all_entities: ['Hunting %displayname%']

This custom rule would give a unique name to entities based on their level. This rule applies to all mobs, though you can instead specify individual mobs.

A Custom Rule for External Plugin Mobs

  - custom-rule: 'EliteMobs 3rd Party Mobs'
    is-enabled: true
    conditions:
      external-plugins: ['elite-mobs']
    settings:
      attribute-modifier:
        max-health: 3.0
        xp-drop: 2.5
        item-drop: 1.5
      minLevel: 5
      maxLevel: 10

For any 3rd party mob plugin supported via the externalplugins.yml or any other internally supported 3rd party mob plugin can be conditioned against, and then you can apply any set of unique rules to those type of mobs. You can further narrow the conditions by the entity type, or custom name, etc.

Nerfed Spawner Cube Mobs

  - custom-rule: 'Nerf Spawner Cube Mobs'
    is-enabled: true
    conditions:
      spawn-reasons: ['SPAWNER']
    settings:
      entity-name-override:
        all_entities: 'Spawner %displayname%'
      attribute-modifier:
        max-health: 0.0  # For Farms
        armor-bonus: 0.0
        armor-toughness: 0.0
        xp-drop: 0.0
        item-drop: 0.0

This custom rule will listen for any mob which was spawned from a vanilla Spawner Cube. These mobs will be given a prefix to their name, Spawner, and given altered stats in order to prevent any common player farms from breaking.

Modifying Construct-Level for new Strategies

  - custom-rule: 'Custom Levelling Strategy for Nether'
    is-enabled: true
    conditions:
      worlds: ['world_nether']
    strategies:
      y-coordinate:
        start-height: 100
        period: 0
        end-height: 60
    settings:
      construct-level: '%y-coordinate%'

When you need to create a new levelling strategy for a mob, it needs to be given a new construct-level: if the changes made do not fit into the previously established construct-level:, likely from the default-rule: .

The Startled Creeper | Requires NBT-API Plugin

  - custom-rule: 'Custom Creepers - Startled with Short Fuse'
    is-enabled: true
    conditions:
      chance: 0.1
      entities: ['CREEPER']
    settings:
      nbt-data: '{Fuse:2,Attributes:[{Name:"generic.follow_range",Base:1f}]}'
      entity-name-override:
        CREEPER: ['Startled %displayname%']

This rule utilizes a compatibility with the 3rd party plugin NBT-API.

This will, at a 10% chance, apply custom NBT data to Creeper mobs. This custom NBT alters their view distance and fuse timer, making both very short. This means that the Creeper will not recognize the player unless they are nearby, and if they do recognize the player they will explode using a shorter fuse timer than normal.

Using Drop Tables from Custom Rules

  - custom-rule: 'Apply Drop Table from Custom Drops'
    is-enabled: true
    settings:
      use-droptable-id: name-of-table, other-table

This custom rule will apply the drop-table's name-of-table and other-table.

These tables are referenced in the customdrops.yml

Using Custom Placeholders with the Player Variable Modifier

  - custom-rule: 'Set the Player Level Modifier'
    is-enabled: true
    modifiers:
      player-variable-mod:
        player-variable: '%level%'
        player-variable-scale: 1.0
        player-variable-tiers:
          '31-45': 3-7
          '16-30': 2-5
          '0-15': 1-3
          default: 1
        match-variable: false
        use-variable-as-max: false
        recheck-players: true
        decrease-output: true
        output-cap: 25
        preserve-entity: 60s
    settings:
      construct-level: '%player-variable-mod% + %rand_-5_5%'

This custom rule utilizes the player variable modifier (PVM) and the construct level mechanic to alter the level applied to mobs. The Construct Level generates a number based on the Player Variable Mod settings, and that is added to a random number from -5 to 5.

Limit a custom rule to specified WorldGuard region

  - custom-rule: 'WorldGuard Region Rule'
    is-enabled: true
    conditions:
      worldguard-regions: ['worldguard-region-name']
    settings:
      maxLevel: 0

This rule would check if the mob spawned in the specified WorldGuard region, and if so apply the settings specified.

Limit a custom rule to Specified Coordinates

 - custom-rule: 'Within Coordinates (Sample of Single Point Coordinate [1D-Point])'
   is-enabled: true
   conditions:
     within-coordinates:
       start-x: 50
       start-y: 64
       start-z: 50
   settings:
     minLevel: 1
     maxLevel: 5

 - custom-rule: 'Within Coordinates (Sample of Straight Line Coordinate [2D-Line])'
   is-enabled: true 
   conditions:
     within-coordinates:
       start-x: 50
       end-x: 75
       start-y: 64
   settings:
     minLevel: 1
     maxLevel: 5

 - custom-rule: 'Within Coordinates (Sample of Plane Coordinate [2D-Plane])'
   is-enabled: true
   conditions:
     within-coordinates:
       start-x: 50
       end-x: 75
       start-y: 64
       start-z: 50
       end-z: 75
   settings:
     minLevel: 1
     maxLevel: 5

 - custom-rule: 'Within Coordinates (Sample of Cuboid Coordinate [3D-Cube])'
   is-enabled: true 
   conditions:
     within-coordinates:
       start-x: 50
       end-x: 75
       start-y: 64
       end-y: 90
       start-z: 50
       end-z: 75
   settings:
     minLevel: 1
     maxLevel: 5

These are several examples of how to use the within-coordinates conditions when isolating a specific set of coordinates or a region of coordinates for which a custom rule would be applied.

In the first sample you can see an example of how to specify a specific point or coordinate by specifying the start- coordinate for each of the start-x, start-y, and start-z conditions. By not specifying the end- coordinate, that condition is automatically populated with the same value as it's corresponding start-. This means, in the example, the rule would only apply to the coordinate location (50, 64, 50). This might be useful for specifying a special command block or spawner cube that generates entities in an always specific location.

In the second sample you can see an example of how to specify a straight line of coordinates. We specify the start-x and end-x, with the start-y specified. Using the same logic as mentioned above, we have the start-y set but not the end-y, so those values will be equal. Since we've specified a start-x and end-x, then that means any X coordinate value between those two set numbers would be valid. This means, in the example, the rule would only apply to entities spawned y=64 and any X coordinate between x=50 and x=75. This would create a line between x=50 and x=75 at the y=64 height; removing the start-y would create the same effect at any height, thereby creating a 2D plane of coordinates at any height rather than a line.

In the third sample you can see an example of how to specify a 2D plane of coordinates. We specify a start-x/end-x and start-z/end-z, with the start-y specified. With both the X and Z coordinate ranges specified, that means any coordinate between those start- and end- of each coordinate type will be valid. Since we specified a Y coordinate, that generates the 2D plane; removing the start-y would create the same effect at any height, thereby creating a 3D cuboid of coordinates at any height rather than a 2D plane.

In the final sample you can see an example of how to specify a 3D cuboid of coordinates. We specify all three of the start- and end- coordinate types, meaning that any value between those start- and end- values would be valid. In the example that would generate a cube with one corner of (50, 64, 50) and the opposite corner being (75, 90, 75).

For all of the end- options, you can specify the value of + or -. These values simply represent 'all numbers above' or 'all numbers below' the corresponding start- value. As well, you can specify negative numbers for all start- and end- values. Finally, a reminder that any value that has a start- specified but not the corresponding end- will have the end- populated with the same value as start-, creating a single-point coordinate. If neither corresponding start- or end- is specified (example being start-y and end-y together), then that coordinate type will not be checked against when considering the entities' location.

Syncing Levels from Overworld to Nether

  - custom-rule: 'Overworld - Nether Sync 1 of 3'
    is-enabled: true
    conditions:
      worlds: 'world'
    strategies:
      distance-from-origin:
        increase-level-distance: 1000
        start-distance: 0
        spawn-location:
          x: 0
          z: 0
    settings:
      construct-level: '%distance-from-origin%'

  - custom-rule: 'Overworld - Nether Sync 2 of 3'
    is-enabled: true
    conditions:
      worlds: 'world'
      apply-below-y: 65
    strategies:
      distance-from-origin:
        increase-level-distance: 1000
        start-distance: 0
        spawn-location:
          x: 0
          z: 0
    settings:
      # Presumes sea level, y=64, is transition zone.
      construct-level: '%distance-from-origin% + (((%y%/8)-8)*-1)'

  - custom-rule: 'Overworld - Nether Sync 3 of 3'
    is-enabled: true
    conditions:
      worlds: 'world_nether'
    strategies:
      distance-from-origin:
        increase-level-distance: 125
        start-distance: 0
        spawn-location:
          x: 0
          z: 0
    settings:
      construct-level: '%distance-from-origin% + (((%y%/8)-16)*-1) + 16'

The idea behind these series of custom rules is to arrange a levelling system which applies a single level every 1000 blocks from a centerpoint using the distance from origin levelling strategy in the Overworld. Then, it says that the level will increase one level every 8 blocks downward from the sea level in Minecraft, established at y=64 blocks. This increase continues downward until the player reaches the Minecraft bedrock level at y=-64 blocks. This gives us an increase of a maximum of 16 levels from the y=64 to bedrock. That means that, at the centerpoint itself, the highest level I should encounter at bedrock would be level 17; 1 level for the distance, and 16 additional for the depth.

We then establish a similar levelling structure for the Nether, using known information about the Nether to compensate for the difference in the Overworld. For example, every 1000 blocks in the Overworld would only represent 125 blocks in distance within the Nether. If we want to presume that the Overworld is 'on top' of the Nether and that the level would continue to increase from the base of the Overworld to the ceiling of the Nether, then we need to include those added 16 levels we gained from the second custom rule downward 'into' the Nether realm custom rule. We do that by artificially subtracting those 16 levels worth of distance from the Nether formula, so that the mobs at the ceiling are already starting with an additional 16 levels.

The Nether ceiling is officially at y=127, and the Nether floor is officially y=0. If we continue the 'every 8 blocks' we increase in level, then we have nearly another 16 levels to add at the end of the Nether.