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

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

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

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

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

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

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

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

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

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

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

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.

PreviousSettingsNextcustomdrops.yml

Last updated