Bone Behaviors

In Model Engine, it is possible to use specific prefixes (called Tags) in the bone name or specific bone ids in order to give bones special behaviors.

Please note that the id of each bone is the name of the bone without the Tag. For instance, if we had a bone called phead_playerhead

  • phead_playerhead would be the Complete name of the bone
  • phead_ would be its Tag
  • playerhead would be its Id

There are several types of Tags, and each of them brings about a different behavior.
The following is a list of all of them:

General tags

**Tag: h_**
When mobs look around, the head turns before the rest of the body does. You can do this in Model Engine too!

All bones rotate like a body by default. If you want a bone to rotate like a head, you need to use the h_ Tag. Model Engine will interpret this as a head bone, remove the h_ in the resource pack, and move this part like a normal head.

A model can have multiple head bones so you can create models with multiple heads. Head bone can also have child bones, but all child bones would also need the h_ flag in front to act like a head.

Inherited Head

**Tag: hi_**
Same as the Head behavior, but with this tag every child bone will also inherit the head behavior without the need of using the h_ tag

Head Parameters

**Tag: h[...]_ or hi[...]_**
Head bones can be limited and slowed down with parameters in square brackets. For example, h[yaw=60;pitch=30;speed=10]_head turns at most 60 degrees to each side and 30 degrees up and down, by at most 10 degrees per tick.

Parameter Description
yaw Turns at most this many degrees to the left and to the right
pitch Turns at most this many degrees up and down
minyaw The furthest the head turns to the left, in degrees (negative)
maxyaw The furthest the head turns to the right, in degrees
minpitch The furthest the head looks up, in degrees (negative)
maxpitch The furthest the head looks down, in degrees
speed The most the head turns per tick, in degrees. Not set means instant

A plain h_ or hi_ head behaves exactly as before. The limits and speed can be changed at runtime with HeadConfig, and HeadTarget makes the head look at an entity or a location.

Mount

**Id: mount**
If you want your mob to be controllable, you can set a specific location to mount on.
Create an empty bone named mount and place it wherever you like. The mount point can be animated, and if it is parented to another bone, it will follow the parent bone. Otherwise, it will follow the base mob.

Note: In your mob's MythicMob code you'll want to add drive=true into your model spawning mechanic to enable mounting, then use Model Engine's mountmodel mechanic instead of MythicMob's mount mechanic for mounting the model. (Don't worry about this part until you get to coding!)

Seat

Tag: p_ You can create multiple passenger seats for other players/mobs to mount on. Unlike the driver seat, they cannot control the mount, and can have more than one point.
Create an empty bone and place it wherever you like, then add p_ in front of the bone name. The passenger point can be animated, and if it is parented to another bone, it will follow the parent bone. Otherwise, it will follow the base mob.

Note: Same as the driver seat, you should add ride=true in your model spawning mechanic, and use mountmodel{driver=false} to mount your entity.

Item

Sometimes you would like items to be synced in your model.
You can do so by creating special, cube-less bones with a specific tag written before the actual bone name. Depending on the tag used, the item that will be displayed will be treated as if it was equipped in the corresponding slot.

Head Display

Tag: ih_

Main Hand Display

Tag: ir_

Offhand Display

Tag: il_

You can create as many item bones as you want. You can then equip items there via the SetItemModel mechanic.

Ghost

Tag: g_ Normal ghost bones (bones without cubes inside) are only used internally and do not spawn armor stands. Marking them as rendered would cause them to spawn an entity, but will not display any models

You can set the model of a rendered ghost bone using the ChangePart mechanic

Nametag

Tag: tag_ To display the name of the model, or add an HP bar on top, you would need a name tag bone.
Each model can have as many name tag bones as you need. They don't need to be centered, and they can have animations.
To create a name tag bone, add tag_ in front of the bone name.

Once you get to coding, if you want to use a specific tag bone as the display bone of your model, you can use the model mechanic's nametag attribute to specify one.
Example: if you had a bone called tag_yournametag, your would need to use model{mid=your_model;nametag=yournametag}

Leash

**Tag: l_**
By making a cube-less bone and using a special tag before the bone name, you can mark a bone as the attachment point when being leashed.

You can create as many bones as you want. You can leash the model using the Leash or LeashSelf mechanics

Inverse Kinematics

Segment

**Tag: seg_**

Segment bone is a special type of bone that is animated procedurally, following the parent bone using the least amount of movement required through rotation or position. This is very useful when creating long, dynamic models such as worms.

This bone tag would mark the bone as a child pivot of the model, where child bones will originate from the new pivot instead of the base pivot. If your segments are long enough that some bones will not move in world space when the base entity moves, use this behavior. Otherwise, check the Tail behavior.

As of R4.0.7, segment tag can only be used on cube-less bones. The pivot point of the bone should also be placed at the back. The bones can be further configured by using the Segment mechanic.

The seg_ tag places the segment's pivot at the back of the bone. If you want the pivot at the front instead, use the segf_ tag.

Check out this segment demo as reference for how to set up the bones and use the segment mechanic.

Tail

**Tag: tl_**

Tail bone visually works exactly the same as segment bone, however instead of creating a separate pivot for display entities, the bones would use the base pivot. If your tail bones move a lot and generally stay around the base model, use this behavior. Otherwise, check the Segment behavior.

As of R4.0.7, tail tag can only be used on cube-less bones. The pivot point of the bone should also be placed at the back. The bones can be further configured by using the Segment mechanic.

The tl_ tag places the tail's pivot at the back of the bone. If you want the pivot at the front instead, use the tlf_ tag.

Blockbench IK

Model Engine solves Blockbench's (5.2+) inverse kinematics in game. Add a null object, set its IK Target to the end bone of the chain (a bone or a locator), and optionally set an IK Source and an IK Pole. Animate the null object and the chain follows it.

  • A chain is active while a playing animation has position keyframes for its null object, which is how Blockbench exports it. Use IK with alwaysactive=true to keep it on.
  • IKTarget makes the chain reach for an entity or a location instead.
  • "Lock IK Target Rotation" is supported.
  • The null object and the pole cannot be inside the chain. Such chains are skipped with a warning.
  • Chains can also be created at runtime with the IKChain mechanic.

Joint Limits

**Tag: ik[...]_**
Limits how far a joint of an IK chain can rotate, in Blockbench degrees. For example, ik[minx=0;maxx=140]_elbow lets an elbow bend one way only. The parameters are minx, maxx, miny, maxy, minz and maxz; axes that are not set are free. The tag needs the square brackets, so existing bones named ik_... are not affected. Limits can be changed at runtime with the IK mechanic.

Physics

**Tag: jig_ or jig[...]_**
Physics bones swing with inertia when the model moves, turns or is animated: ears, antennas, tails, ropes, chains.

A single jig_ bone springs around its animated pose. jig_ bones placed inside each other form one chain that swings as a whole, like a rope or a tail. Inner links copy every setting they do not set themselves from the link above them.

Parameter Description Default
stiff How fast the bone returns to its animated pose, from 0.01 to 1. Low values make loose ropes 0.15
damp How fast the swinging dies down, from 0.01 to 1 0.25
grav Gravity in blocks per second squared. Ropes look right around 20 0
angle How far the bone can swing away from its animated pose, in degrees, from 0 to 180. One value limits the swing in every direction. Three values x,y,z limit it around each of the bone's own axes separately, for example angle=10,20,10 45
repeat How many links this one bone becomes, see "Repeating a link" below. Inner links do not copy it 1

Examples:

  • jig_ear makes a springy ear.
  • jig[stiff=0.01;damp=0.1;grav=20;angle=180]_rope1 > jig_rope2 > jig_rope3 makes a hanging rope.
  • jig[angle=10,20,10]_tail swings up to 20 degrees around its Y axis and up to 10 degrees around X and Z. For a bone that hangs down, X swings it forward and back, Z swings it to the sides and Y only twists it.

Setting up links: put the pivot of each link where it hangs from, usually the top of the link. A link points at the pivot of the next link, and the last link points at the center of its cubes. That center is also the point that gets tied. To tie a rope by its very end, finish the chain with an empty jig_ group at the end and tie that bone. A link whose pivot sits in the center of its cubes has nothing to swing around and does not move.

Repeating a link: model one link and let Model Engine copy it. jig[repeat=16]_rope_segment turns one link into 16, each copy hanging from the end of the one before. Anything inside the link, like an empty jig_rope_end group with a hook, moves to the last copy, so iktarget{p=rope_end} always ties the real end. A copy hangs at the pivot of the link's first child bone, or at twice the distance to the center of its cubes when it has none. The copies reuse the link's model, so the resource pack does not grow, but each copy is still one more display entity. They are named rope_segment_2, rope_segment_3 and so on, and the count can be changed live with ik{p=rope_segment;repeatjig=24}. Repeat does not work on bones of a Blockbench IK chain.

By default a new count is applied at the far end of the chain, all at once. With repeatjigat=start, for example ik{p=rope_segment;repeatjig=4;repeatjigat=start}, links are added or removed one per tick where the chain hangs from, so the far end stays in place and the rope reels in or out like a winch. The count a model spawns or loads with is always applied at once.

Tying the end of a chain:

  • To an entity or a location: use IKTarget on the last link, for example iktarget{p=rope_end;y=1.2} @trigger. To tie it to a bone of another mob's model, even while it animates, add the bone: iktarget{p=rope_end;tp=arm} @target. The rope sags between both ends. When the target is farther away than the rope is long, the rope goes straight and stops short.
  • To another part of the model: make a Blockbench IK chain out of jig bones and place its null object where the end should be tied, for example on the second post of a rope bridge. Such chains are always tied to their null object.

Notes:

  • Settings can be changed live with IK and are saved with the model. JiggleImpulse kicks the bones.
  • Physics bones do not collide with blocks, never stretch, and never pull the entity they are tied to.
  • Lower links follow the links above them but do not pull them, unless the end of the chain is tied.
  • Every link swings around the link above it, so swinging adds up along a chain. A long chain that should keep its modeled shape, like a cord wrapped around a body, can swing harder and harder toward its end with the default settings. For such chains set damp higher than stiff, for example jig[stiff=0.8;damp=0.9;angle=8], and only make the part that hangs free a physics chain.
  • Physics bones ignore ik[...] joint limits, the IK pole and global rotation keyframes. Use angle to limit the swing.
  • A bone with more than one jig child ends the chain there, and each child starts its own chain.
  • IK mechanics with no partid affect every IK bone of the model, physics bones included.



Hitbox Tags

Model Engine allows you to add different kinds of sub-hitboxes to the model. Depending on the type, the specific functionalities will vary. The following is a list of all possible sub-hitbox you can employ in your model.

Axis Aligned Bounding Box

**Tag: b_**
They are like the normal hitbox, but cannot collide with blocks and take suffocation damage. These hitboxes would act like bones and follow their parent, however, they will not rotate with the parent bone, and they must still be square-based.

Create a sub-hitbox by adding a bone starting with b_ and a cube inside. The size of the cube is the hitbox size. Same as the normal hitbox, it must obey Minecraft's hitbox limit, and X and Z values must be the same.

Oriented Bounding Box

**Tag: ob_**
This type of bounding box is, essentially, an Axis Aligned Bounding Box with the ability to be rotated. These hitboxes would act the same as normal sub-hitboxes, but they can rotate with the parent bone, and they can be any size.

Similar to a normal sub-hitbox, create a bone with a cube inside, but the bone name starts with ob_, and unlike normal hitboxes, your cube can be any size you want, meaning the X and Z values can be different.



Player Limbs Tags

Player limb tags allow a model to use player skin and limb. You can recreate the entire player model, only use parts, or have multiple of the same parts.
To create a player limb bone, create a bone that starts with one of the tags listed below. Any cubes inside these bones will be ignored automatically.
You can apply a skin to the bone using the ModelPlayerSkin Mechanic
If you need some guide on how to create these bones, check out this demo player model (right click and save link as).

This is a modified version of Bradleyq's Stable Player Display. It requires core shader, works on vanilla, optifine and sodium, but does not work when modded shaders are used.
Massive thanks to them for sharing this technology. For more information, check out their repository.

Tag Player Part
phead_ Head
prarm_ Right Arm
plarm_ Left Arm
pbody_ Body
prleg_ Right Leg
plleg_ Left leg

Custom User Limbs

**Tag: limb[type=X]**
limb is a separate, more granular player-limb system. Instead of the six fixed parts above, it renders a single limb region of the player skin chosen by the required type parameter, which lets you split a model into finer pieces such as an upper and lower torso, or upper and lower arms and legs. As with the tags above, any cubes inside the bone are ignored unless you set cube=true, and you apply a skin with the ModelPlayerSkin mechanic.

The available type values are:

Type Skin Region
head Head
chest Upper torso
body Lower torso
right_arm Right upper arm
right_forearm Right lower arm
left_arm Left upper arm
left_forearm Left lower arm
right_leg Right upper leg
right_foreleg Right lower leg
left_leg Left upper leg
left_foreleg Left lower leg

For example, a bone named limb[type=right_forearm]_myarm renders the lower half of the player's right arm.

Cube Size

**Tag: limb[type=X;cube=true]**
By default a limb always has the vanilla player proportions. With cube=true, the limb takes its size and position from the cube inside the bone instead, so limbs can be longer, thicker or smaller than a player's. For example, limb[type=right_arm;cube=true]_myarm. The skin region of the chosen type is stretched over the cube.

  • Use one cube per bone. Cubes whose name starts with hat_ are skipped because the outer skin layer is drawn automatically.
  • The cube's size in Blockbench is used. Its inflate and rotation are ignored.
  • Slim (Alex) skins make arm limbs 3/4 as wide, like vanilla, keeping the side that faces the body in place.

A plain limb[type=X] bone behaves exactly as before.

Updated Oct 17, 2026