Entity Modifiers

This is a new 1.21.11 feature (for now) that allows you to make Entity Models emit Particles

The file will have to be in assets/[entity namespace]/polytone/entity_modifiers/[entity name].json.

Alternatively, if you want to manually specify your targets you can place this json in assets/[your pack namespace]/polytone/biome_modifiers/[some name].json (Any path will work but this is recommended to avoid overwriting Implicit defined targets).

Then you can add the targets field to the json containing a list of valid Biome ids as follows:

{
   "targets": ["minecraft:zombie", "minecraft:pig"]
}

Json Syntax

Fow now Entity Modifiers just contain the emitters field. Each entry in emitters defines a particle emitter attached to a model bone. All numeric values are Entity Scripting Expressions. Position and velocity are evaluated in the bone’s local coordinate space, not world space, so rotated bones affect emission direction. EMF and ETF fields are only relevant when those mods are present.

Here is a practical example

{
  "emitters": [
     {
        "bone": "left_arm",
        "particle": "minecraft:flame",
        "chance": "1",
        "count": "1",
        "y": "0.5",
        "dy": "0.1"
     }
  ]
}

And here is the full syntax

Field	Type / Default	Description
bone	string	Model bone where particles spawn. Nested bones can be referenced with dot notation (arm.hand.thumb).
particle	identifier	Particle type ID from the particle registry.
target_texture	identifier or Identifier list (optional)	Only apply this particle to model renderers that are using a specific (base) texture.
target_etf_variant	int or Int list (optional)	ETF variant index to match.
target_emf_variant	int or Int list (optional)	EMF variant index to match.
max_distance	float (default 32)	Max distance from the camera after which the particle won't even attempt to spawn
chance	expression (default 1)	Probability per tick that the emitter triggers.
count	expression (default 1)	Number of particles spawned per trigger.
x,y,z	expression (default 0)	Position offset relative to the bone’s local coordinates.
dx,dy,dz	expression (default 0)	Initial particle velocity in bone-local space.
r,g,b,a	expression (optional)	Color and alpha override.
roll	expression (optional)	Particle roll angle.
size	expression (optional)	Particle size multiplier.
custom	expression (optional)	Particle-specific custom parameter.

The bone field is the bone name in your model that the particles should spawn at. If your model has nested bones you can reference them like this "left_arm.left_hand.thumb".

The chance and count are optional fileds that can hold an Entity Scripting Expression (see its page). Together with these two you can also set the following fields, just like in Particle Modifiers: x, y, z, dx, dy, dz, r, g, b, a, roll, size, custom.

Also note that position and direction are relative to the model part. if a model part own coordinates, not the world coordinate. thats's why the zombie arm needs to have dy instead of dz to shoot foward as the arm itself is rotated!

How to view the bone names

Each model is made of bones, each bone can contain one of more cubes. Bones are what you see as folders in blockbench.

To view the vanilla bone names you can use third parties programs or ask around as many are known. Even asking the developers is an option. You could even use the blockbench custom entity models plugin but note that those were done by hand and just look like the vanilla models and might not match at all what the game actually uses.

A better way to view the existing bones is through the use of the Entity Model Features Mod which allows us to view the vanilla models ingame.

The below instruction works for EMF but you can also use it just to see what names vanilla uses.

When addressing EMF models try this:

1. First open the EMF settings screen, goto > models > all models > {modelname} > export to .jem, then look at your game log and see if there is any difference between the OptiFine format name mappings (which is the part names the .jem file will likely use) and the vanilla names. (e.g. most vanilla mobs use "leg1..." in OptiFine but the vanilla name is actually different!)

2. Once you are sure these parts are correct then there is one more thing to consider, ANY part that is not one of these parts that exist in the vanilla model may potentially have the prefix "EMF_" applied internally (you can verify this by turning on the setting to log model creation info and checking the final part names it prints upon closing the config, fyi they might only print properly if your model has animations) (fyi this may change soon in emf)

3. Less likely to be an issue, if a part has multiple other parts with the same id, it may have any number of "#"'s added to the end of it (this can also be verified via the same steps above)

4. Lastly, some/most people name their top level .jem groups the same as the part they attach to (e.g. id="head" in the .jem attaches to part="head") this can be confusing when needing to address its final layout, in this case the model layout in-game would look like this head.EMF_head.EMF_child_of_head_in_the_jem