B
BlackSpigot Guides
Guest
Scope and prerequisites
This walkthrough connects a saved Generic Model bbmodel to a MythicMobs test mob using Model Engine 4. Install compatible, legitimately obtained versions of both plugins on a development server and confirm they enable without errors. Check their compatibility information for your Minecraft version. The example is intentionally a pig with a visual model, not a finished combat mob.
1. Prepare the blueprint
Save the original robot project as
Copy the bbmodel into
2. Apply the generated resource pack
Locate Model Engine’s generated resource pack using its output/configuration. Apply that pack to the Minecraft client used for testing. Model Engine does not automatically deliver the pack to players simply because you imported a blueprint. If your server uses another pack manager, merge and distribute using that system’s documented workflow rather than overwriting unrelated assets.
Keep a note of which pack build you applied. When you change geometry or textures, regenerate and reapply it. If the server model loads but the client shows missing assets, verify the client’s active pack before touching the mob YAML. A server reload and a client pack refresh solve different problems.
3. Define the test mob
Put this in
Run
The model mechanic targets the spawned entity itself. This example enables its state-machine behavior with usm and saves the model attachment with save. The Model Engine model mechanic reference documents those options; confirm them against your installed major version.
4. Test one layer at a time
First confirm the mob exists. Next confirm the custom geometry and texture display. Observe idle while still and walk when the pig moves. Spawn a new copy after edits; an onSpawn mechanic is not a general update command for every existing entity. Test leaving and returning to the chunk to check persistence on your actual setup.
If there is only a normal pig, inspect the model ID and skill load errors. If the visual model exists but the texture is missing, inspect pack generation and the active client pack. If it is frozen, verify state names and loop settings. If you see two visuals, inspect the model mechanic’s invisibility configuration and any other disguise plugins before adding a second disguise layer.
This configuration follows the documented Model Engine 4/MythicMobs mechanics. Import, pack delivery, animation and chunk persistence must be checked in your own running server; this guide does not claim an in-game test.
This walkthrough connects a saved Generic Model bbmodel to a MythicMobs test mob using Model Engine 4. Install compatible, legitimately obtained versions of both plugins on a development server and confirm they enable without errors. Check their compatibility information for your Minecraft version. The example is intentionally a pig with a visual model, not a finished combat mob.
1. Prepare the blueprint
Save the original robot project as
workshop_bot.bbmodel. Keep the filename lowercase with underscores. Reopen it in Blockbench to confirm the texture and bones are present. Start with idle and walk only if you are still debugging the geometry.Copy the bbmodel into
plugins/ModelEngine/blueprints/, then run /meg reload models. Read the console for that model ID. Stop and fix an import error before testing skills: a missing blueprint cannot be repaired by a spawn trigger. The official import instructions describe the blueprint folder and generated pack.2. Apply the generated resource pack
Locate Model Engine’s generated resource pack using its output/configuration. Apply that pack to the Minecraft client used for testing. Model Engine does not automatically deliver the pack to players simply because you imported a blueprint. If your server uses another pack manager, merge and distribute using that system’s documented workflow rather than overwriting unrelated assets.
Keep a note of which pack build you applied. When you change geometry or textures, regenerate and reapply it. If the server model loads but the client shows missing assets, verify the client’s active pack before touching the mob YAML. A server reload and a client pack refresh solve different problems.
3. Define the test mob
Put this in
plugins/MythicMobs/Mobs/workshop-bot.yml. Use spaces rather than tabs:
YAML:
WorkshopBot:
Type: PIG
Display: 'Workshop Bot'
Health: 30
Skills:
- model{mid=workshop_bot;usm=true;save=true} @self ~onSpawn
/mm reload, check the console, and then /mm mobs spawn WorkshopBot 1 in a safe test area. WorkshopBot is the MythicMobs configuration key; workshop_bot is the imported Model Engine blueprint ID. They are separate identifiers.The model mechanic targets the spawned entity itself. This example enables its state-machine behavior with usm and saves the model attachment with save. The Model Engine model mechanic reference documents those options; confirm them against your installed major version.
4. Test one layer at a time
First confirm the mob exists. Next confirm the custom geometry and texture display. Observe idle while still and walk when the pig moves. Spawn a new copy after edits; an onSpawn mechanic is not a general update command for every existing entity. Test leaving and returning to the chunk to check persistence on your actual setup.
If there is only a normal pig, inspect the model ID and skill load errors. If the visual model exists but the texture is missing, inspect pack generation and the active client pack. If it is frozen, verify state names and loop settings. If you see two visuals, inspect the model mechanic’s invisibility configuration and any other disguise plugins before adding a second disguise layer.
This configuration follows the documented Model Engine 4/MythicMobs mechanics. Import, pack delivery, animation and chunk persistence must be checked in your own running server; this guide does not claim an in-game test.
