How to add new monsters (BMD) to the MU Online client

Inserting a brand-new monster into MU Online is the kind of customization that impresses any veteran player: an exclusive event boss, a creature no one has seen on another server, a themed mob that gives a new map its own identity. But behind that effect lies some of the most technical work on the client side, because a monster in MU is not an image — it is a three-dimensional model with a mesh, a skeleton, animations and textures, packed into the BMD format and tied to a model slot that the game executable expects to find. And, just as important, that model only becomes a real enemy once the server knows it exists, how much life it has, what damage it deals and where it appears. This tutorial is for the advanced administrator who wants to master the entire flow: preparing the BMD, handling the textures, fitting it into the correct client slot and syncing it with the server. As always, file names, slot numbering and folder structure vary by season and client; use the examples as illustrations of real concepts and validate them in your own package.

Prerequisites

Before importing any model, have the right environment ready:

• Full backup of the client's Data\Monster folder and of the server's monster files (MonsterList, Monster.txt, spawns).
• An isolated test client, so you never ship a broken model straight to players.
• A BMD manipulation tool compatible with your season (BMD editors/viewers or an import/export plugin for 3D software).
• OZT/OZJ converters to prepare the textures in the encrypted format the client reads.
• Access to the server's MonsterList/Monster.txt and to the spawn files.
• A server base already running. If you don't have one yet, start with the guide on how to create a MU Online server.

> Never edit the original BMD that is already in use. Work on renamed copies and keep the base model intact so you can roll back.

Anatomy of a BMD file

The BMD (Binary Model Data) is the heart of everything three-dimensional in MU Online. A single monster .bmd file contains, in compressed form:

• Mesh: the vertices, faces and texture coordinates (UV) that form the visible geometry.
• Bones: the skeleton hierarchy that lets the model deform and animate.
• Actions: the animations, each one indexed — walk, attack, take damage, die. The client calls these actions by index.
• Texture references: the names of the texture files (OZT/OZJ) that each part of the mesh uses.

The crucial detail is that the BMD references textures by name, and those textures must exist in the same folder as the model. If you import a monster from another package and forget to bring the textures over — or you rename the BMD without adjusting the references — the client loads the geometry but paints it white, black, or makes the model "flicker".

Where monsters live in the client

In most clients, monster models sit in the Data\Monster folder. The naming convention is usually MonsterXX.bmd, with XX being a number that identifies the model slot, accompanied by its textures. A monster can use more than one texture: an OZJ for the solid body and an OZT for parts with transparency, for example.

The model number (123 in the example) is what ties everything together: when the server describes a monster, it reports a type that the client translates into a model index. Depending on the season, this type-to-model mapping lives in the executable or in a client definition file. Finding where that mapping lives in your package is an essential part of the job.

Step by step to add the monster

1. Choose a free model slot. Check which MonsterXX.bmd numbers are already taken and pick an unused index, or a slot you intend to replace.
2. Prepare the BMD. If the model came from another package, open it in your tool and confirm that the essential animations exist: idle/walk, attack, damage and death. Adjust scale and orientation if needed.
3. Adjust the texture references. Make sure the texture names inside the BMD match the files you are going to place in the folder.
4. Convert the textures. Turn the images into OZJ (solid) or OZT (with alpha) using your package's converter.
5. Rename and position. Place MonsterXX.bmd and its textures in Data\Monster, using the number of the slot you chose.
6. Register the model mapping. Make the client associate the server's monster type with the model slot, whether in the executable or in the definition file, according to your season.
7. Test in the local client before any distribution.

> A monster can load visually without HP, drops or AI — that is the server's responsibility. Confirm the visuals first, then tie the behavior on the server side.

Animations and actions: why the index matters

Each of a monster's actions (walk, attack, die) is an indexed animation inside the BMD. The MU engine calls these actions by number: when the server tells the monster to attack, the client plays the action at the corresponding index. If the imported model has its animations in a different order than expected, you will see bizarre behavior — the monster "attacks" by playing the death animation, or stands frozen in a permanent damage pose. That is why, when bringing in a model from outside, you often need to reorder or remap the actions so the indices match what the client expects for that category of creature. Boss models and ordinary mob models can have different animation sets, so respect the category of the slot you are occupying.

# Conceptual illustration of the expected action indices (varies by season/client)
Action 0 : Stop/Idle      # standing still
Action 1 : Walk           # walking
Action 2 : Attack         # attack
Action 3 : Shock/Damage   # taking damage
Action 4 : Die            # death

Textures: when to use OZT and when to use OZJ

The choice between OZT and OZJ is not aesthetic, it is technical, and getting it wrong produces visual artifacts:

• OZJ is an encrypted JPG. It has no alpha channel (transparency). Use it for solid surfaces: skin, armor, stone, metal. It is lighter and compresses continuous colors well.
• OZT is an encrypted TGA. It preserves the alpha channel, meaning real transparency. Use it for wings, membranes, effects, see-through hair, any part that needs transparent edges.

If you apply a solid texture (OZJ) to a part that should be see-through, the monster ends up with opaque "rectangles" around wings or tentacles. If you use OZT unnecessarily, you waste memory. Prefer power-of-two dimensions (256x256, 512x512) for maximum engine compatibility.

Syncing with the server: MonsterList

The model in the client is only half the work. The monster exists for the game once the server defines it. On the server side, typically in a MonsterList/Monster.txt file, you declare the monster's attributes: name, type (which points to the client's model slot), level, HP, minimum and maximum damage, defense, resistances, and you associate the drop table and the AI behavior.

# Conceptual illustration of a MonsterList entry (format varies by emulator)
# Type  Name              Level  HP     MinDmg MaxDmg Def  MoveRange AttackType
  123   "Shadow Guardian"  120   45000   850    1100   420   3         1

The Type field is the bridge between server and client: it is what has to match the MonsterXX.bmd model slot. If the server spawns type 123 but the client has no Monster123.bmd, or it is mapped to something else, players see an invisible monster, a generic model, or the client crashes. After registering the monster in the MonsterList, you still need to add it to the spawn of some map (spawn file/MonsterSetBase), providing the same type, the map, the coordinates and the quantity. Client, MonsterList and spawn all need to speak the same number.

Distribution via the launcher

Once tested locally, the monster needs to reach the players. The MonsterXX.bmd and its textures go into the launcher/updater patch package: the player downloads the model and the textures before connecting. If a player doesn't have the files, they won't be able to render the creature — at best they see a generic model, at worst the client closes when it tries to draw it. That is why, whenever you add a monster that appears in production, the client files go into the mandatory update. Version the patch so that those who already downloaded don't repeat the download and so that new players receive the full set of models.

Common errors and fixes

Launch checklist

• Backup of Data\Monster (client) and of the server's monster files
• Free model slot chosen and confirmed
• BMD with the essential animations (idle, walk, attack, damage, death)
• BMD texture references checked and aligned
• Textures converted correctly (OZJ solid, OZT with alpha)
• MonsterXX.bmd and textures placed in Data\Monster
• Type-to-model mapping adjusted according to the season
• Monster registered in the MonsterList with attributes and drops
• Spawn added to the map with the same Type
• Behavior tested in the local client (visuals, attack, death)
• Model files added to the launcher/updater and versioned
• Final test with a "clean" client downloading via the patch

Adding a monster is an exercise in precision: the model, the textures, the animations and the server registration all have to be consistent, tied together by the same type number. When everything fits, the result is a creature that feels like a native part of the game — and it is exactly that "this doesn't exist on any other server" feeling that keeps your community loyal.

Frequently asked questions