B
BlackSpigot Guides
Guest
Use one known-good mob
Begin with the imported workshop_bot blueprint and the WorkshopBot MythicMobs configuration. Keep the plain model attachment working before adding a new state or custom hitbox. Save copies of the bbmodel and YAML so each experiment has an obvious undo.
1. Trigger a custom animation
Add the one-shot wave animation from the Blockbench animation lab. Regenerate the model and refresh the client resource pack as needed for your changes. Add this line underneath the existing model skill in WorkshopBot’s Skills list:
Reload MythicMobs, check errors and spawn a fresh copy. Interact with it and watch for the head tilt. mid identifies the attached model, s selects the animation, and li/lo set the transition lengths in ticks. The state mechanic reference lists the available controls. Keep wave in play-once mode so it can return to normal movement.
If interaction does nothing, first add a simple MythicMobs message on the same trigger to establish that the trigger fires. Then check the imported animation name, model ID and attachment. Do not change all three at once. If wave works but never releases its pose, inspect the playback mode and last keyframe; if it jerks, inspect the transition and neutral endpoints.
2. Make a predictable hitbox experiment
In a separate copy of the model, add the special hitbox bone according to your Model Engine version’s modeling rules. For this small robot, start with one cube from (-3, 0, -3) to (3, 14, 3), and place the hitbox bone pivot at (0, 12, 0) for the eye-height experiment. This intentionally makes X and Z equal. Do not animate this bone.
The model creation reference explains the special hitbox and eye-height behavior. Treat these values as a test shape rather than proof of perfect collision. Rebuild, refresh the pack if required, and spawn a new mob. Compare where interactions register and how it fits beside a block. Restore the prior version if the change is worse.
3. Diagnose by symptom
• No custom geometry: confirm the import succeeded, blueprint ID matches, and model skill ran on the entity you are inspecting.
• Missing or incorrect texture: confirm the generated pack contains the assets and that the client actually loaded that build; check UV placement in the source model.
• Walk never plays: get the mob moving, then check the exact walk state name and looping settings.
• Model drifts away: remove root translation from the first test and inspect bone pivots.
• Interaction or collision feels oversized: compare the special hitbox cube to the intended scale; visual bounds and collision are different things.
4. Keep a short test record
Record server version, Model Engine version, MythicMobs version, blueprint filename, pack build and one reproduction action. Attach a screenshot in Blockbench and one in game when asking for help. Include the first relevant console error rather than a screenful of later failures, and remove private information. The official FAQ is a useful next check once you can name the failing layer.
The mechanics and diagnostic steps are documentation-based; exact animation, hit detection and plugin interactions require an in-game check on your versions.
Begin with the imported workshop_bot blueprint and the WorkshopBot MythicMobs configuration. Keep the plain model attachment working before adding a new state or custom hitbox. Save copies of the bbmodel and YAML so each experiment has an obvious undo.
1. Trigger a custom animation
Add the one-shot wave animation from the Blockbench animation lab. Regenerate the model and refresh the client resource pack as needed for your changes. Add this line underneath the existing model skill in WorkshopBot’s Skills list:
YAML:
- state{mid=workshop_bot;s=wave;li=2;lo=2} @self ~onInteractIf interaction does nothing, first add a simple MythicMobs message on the same trigger to establish that the trigger fires. Then check the imported animation name, model ID and attachment. Do not change all three at once. If wave works but never releases its pose, inspect the playback mode and last keyframe; if it jerks, inspect the transition and neutral endpoints.
2. Make a predictable hitbox experiment
In a separate copy of the model, add the special hitbox bone according to your Model Engine version’s modeling rules. For this small robot, start with one cube from (-3, 0, -3) to (3, 14, 3), and place the hitbox bone pivot at (0, 12, 0) for the eye-height experiment. This intentionally makes X and Z equal. Do not animate this bone.
The model creation reference explains the special hitbox and eye-height behavior. Treat these values as a test shape rather than proof of perfect collision. Rebuild, refresh the pack if required, and spawn a new mob. Compare where interactions register and how it fits beside a block. Restore the prior version if the change is worse.
3. Diagnose by symptom
• No custom geometry: confirm the import succeeded, blueprint ID matches, and model skill ran on the entity you are inspecting.
• Missing or incorrect texture: confirm the generated pack contains the assets and that the client actually loaded that build; check UV placement in the source model.
• Walk never plays: get the mob moving, then check the exact walk state name and looping settings.
• Model drifts away: remove root translation from the first test and inspect bone pivots.
• Interaction or collision feels oversized: compare the special hitbox cube to the intended scale; visual bounds and collision are different things.
4. Keep a short test record
Record server version, Model Engine version, MythicMobs version, blueprint filename, pack build and one reproduction action. Attach a screenshot in Blockbench and one in game when asking for help. Include the first relevant console error rather than a screenful of later failures, and remove private information. The official FAQ is a useful next check once you can name the failing layer.
The mechanics and diagnostic steps are documentation-based; exact animation, hit detection and plugin interactions require an in-game check on your versions.