[Bug] Mythicmobs animation skill issue

[JuliGame]

✔️ Pre-check

• Tested with the latest snapshot of BetterModel from Modrinth
• Confirmed the issue occurs without other optional/experimental plugins or clients (see Disclaimer below)

Im using nexo, but that shouldn't affect. Also the issue is with MythicMobs.

---

🐞 Problem Description

Weird ghost model on first frame of animations when using the mythic mobs model and state (animation) properties.
Its like in the first frame its not hiding things as it should, it has a small delay of one tick.
When testing the animation with /bettermodel test, it seems to work fine, its an issue with the bettermodel skill implementation.

---

🖼️ Screenshot / Video

Your in-game screenshot.
https://youtu.be/4kSh8qQ1Vzo

---

🧪 Test Model / Code

Upload the model, resource pack, or test code that can reproduce the issue if possible.
.bbmodel: https://anonfilesnew.com/s/KStWSxSJXGe

VFX_DRAGON_COMBO_DOWN_DIAG:
  Type: block_display
  DisplayOptions:
    Block: AIR
    Billboard: FIXED
  Options:
    Invincible: true
    Collidable: false
  Skills:
  - model{usestatemachine=true;mid=dragon_combo_1;lockpitch=true} @self ~onSpawn
  - brightness{b=15;s=15} @self ~onSpawn
  - state{s=slash_down_diag;speed=0.1} @self ~onSpawn

---

🌍 Environment

• OS: Linux
• Server software & version: Purpur 26.1.2
• Bettermodel: 3.3.0-SNAPSHOT-508 (this has been happening for a long time, not just this version)

---

[JuliGame]

I debugged this issue locally with Codex/AI against the BetterModel v3-dev source, using the exact MythicMobs setup from this issue.

The problematic setup is:

• model{usestatemachine=true;mid=dragon_combo_1;lockpitch=true} @self ~onSpawn
• brightness{b=15;s=15} @self ~onSpawn
• state{s=slash_down_diag;speed=0.1} @self ~onSpawn

The important difference is that /bettermodel test creates the model first and applies the animation before the normal MythicMobs entity/model spawn flow finishes. In the MythicMobs skill flow, BetterModel was spawning/registering the model before the following state skill had been applied.

The relevant sequence was approximately:

1. model creates the tracker.
2. The tracker immediately starts spawning display entities.
3. Initial packets are sent using the model's default transformation/state.
4. state is applied afterwards.
5. The animation then changes the first keyframe, causing parts that should start at scale 0 or hidden to briefly appear at their default scale and interpolate away.

This explains why the issue looked like a client-side race: depending on packet/tick timing, the client could receive either the base transformation or the animation's initial transformation first.

I also compared this behavior with ModelEngine R4.1.0. ModelEngine's MythicMobs StateMechanic uses a default lerpIn value of 0, while BetterModel's StateMechanic was defaulting li to 1. That made the initial transition even more visible.

The local fix that worked in repeated manual testing was:

• Change BetterModel's MythicMobs state default from li=1 to li=0.
• Initialize the first animation keyframe immediately when the animation is registered.
• Mark the initial bone transformation as dirty so the first spawn/load packet uses the animation's first frame.
• Defer and coalesce entity tracker spawn refreshes until the next region tick. This allows all MythicMobs skills from the same ~onSpawn sequence (model, brightness, state, etc.) to be registered before BetterModel sends the initial model packets.

The relevant source changes are in:

• AnimationStateHandler
• RenderedBone
• EntityTrackerRegistry
• MythicMobs StateMechanic

With these changes, the model no longer starts from the default scale 1 and then interpolates toward scale 0. It starts directly from the animation's initial state, which removes the ghost/extra first-frame model.

This was tested locally with the exact example from this issue using a freshly built Paper JAR. The build succeeded and the behavior was fixed in the affected setup.

I have not yet added an automated integration test for the complete MythicMobs model -> state -> spawn packet ordering, so this should still be validated across Paper/Purpur and Folia before considering it a final upstream fix. However, the issue appears to be caused by BetterModel's spawn/animation initialization ordering rather than by Nexo or the Minecraft client itself.

If you want @toxicity188, I could make a pr with my code but its made by codex so idk how clean it is.