How to add visual items (wings, sets) to the MU client

Adding visual items like wings and sets to the MU Online client is one of the most rewarding — and at the same time most delicate — customizations an administrator can make. Unlike tweaking an experience rate or a drop value, here you touch directly what the player sees on screen: three-dimensional models, textures, glow effects and the way all of that fits onto the character. The core concept you need to lock in before anything else is that MU Online works with two halves that need to speak the same language. The server knows there's an item with a certain ID, attributes and restrictions; the client knows how to draw that item on screen. If the two halves aren't perfectly synchronized, the result is an invisible item, a question mark floating over the character or, in the worst case, a client that crashes every time it tries to render that object. This tutorial is aimed at the advanced administrator who already masters the server side and now wants to deliver new visuals safely. As always in the world of emulators, the exact file names, folders and definition structures vary by season and client, so treat every example here as an illustration of a real concept, not a literal copy for your package.

Prerequisites

Before touching any file, make sure you have the minimum environment and knowledge to work safely. Adding visual items is an advanced-level task precisely because it involves several layers at once, and skipping steps tends to cost hours of rework.

• Full client backup: copy the entire client folder, paying special attention to the Data subfolder. Also keep a copy of the item definition file you're going to edit.
• Server backup: export the item table from the database and copy the GameServer definition files that control the item.
• BMD file editing tool: models and some MU definitions are in BMD format, which is encrypted or packed. You'll need an editor compatible with your season to open, view and save these files.
• Texture editor: textures are usually in formats like OZJ, OZT or OZB, which are variations of JPG, TGA and BMP with a small header. An OZ conversion tool is essential.
• A base item to clone: the safest way to start is from a visual item that already works, understanding its structure and only then modifying it.
• Testing environment: never make your first attempt on the production server. Have a test client pointing to a local server.

How MU represents a visual item

A visual item in MU isn't a single file, but a set of pieces the client assembles in real time. Understanding this anatomy is what separates those who add items with confidence from those stuck in trial and error. Broadly, three blocks make up any wing or set.

The first block is the geometric model, the BMD file that describes the three-dimensional mesh, the animation bones and the attachment points. It's what defines the shape of the wing or the cut of an armor. The second block is the texture, the image that covers this model and gives it color, shine and detail. The third block is the item definition, the entry in a table or file that tells the client which category and index that item occupies, which model to load and which effects to apply. The server keeps its own parallel definition, with the game attributes. When a player equips the wing, the server sends the ID; the client receives that ID, looks up in its definition which model and texture correspond, and draws it on screen.

The golden rule that follows from this anatomy is simple: the item's ID must be identical on the server and the client, and all three visual blocks must exist in the client's folder. If any piece is missing, the item breaks.

Categories and indexes: choosing a free slot

Each item in MU is identified by a pair of values: the category, generally from 0 to 15, which separates types like weapons, armors and wings, and the index within that category, typically from 0 to 511. Wings usually live in their own category, while set pieces are distributed across the armor, pants, gloves, boots and helmet categories. Before adding anything, you need to find a category/index pair that's vacant, because reusing an occupied pair overwrites the original item and causes silent conflicts that only show up weeks later.

On the server side, you check availability by querying the database:

-- Checks whether the category/index pair is already in use
-- (table and column names vary by emulator)
SELECT ItemCategory, ItemIndex, ItemName
FROM Item
WHERE ItemCategory = 12 AND ItemIndex = 40;
-- If it returns no row, the slot is free to use

On the client side, the check is done by opening the item definition file and looking for the same pair. The pair must be free on both sides at the same time. A common mistake is choosing an index that's free on the server but already occupied on the client by a system item, which makes the new item inherit the wrong look.

Step by step: adding a new pair of wings

With the concepts firm, let's get to the practical process. I'll use wings as an example because they exercise all the layers at once, including effects. The steps for a set follow the same logic, with the difference that a set involves several pieces, each in its own category.

1. Choose the source model. Select a wing BMD file that already works and has a geometry similar to what you want. Reusing drastically reduces the chance of errors in attachment points.
2. Define the free category/index pair. Confirm availability on the server and the client, as described in the previous section. Note the chosen pair in a notepad so you don't lose track.
3. Prepare the texture. Edit or create the wing image in your graphics editor, respecting the original's dimensions. Convert it to the correct OZ format and name it following your client's convention.
4. Adjust the BMD model. Open the model in the BMD editor, point it to the new texture and, if needed, adjust scale and position. Save it with the name that matches the new index pair.
5. Register the definition in the client. Add the entry that maps the new category/index pair to the newly created model and texture. This is where the client learns the item exists.
6. Register the definition on the server. Insert the item in the database table and in the GameServer definition files, with name, attributes and class restrictions. Without this, the item can't be dropped or equipped.
7. Configure the effect, if any. Wings usually have a glow or aura. Point the effect definition to the desired particle texture.
8. Sync and test. Copy the visual files to the test client, bring up the local server and verify.

; ILLUSTRATIVE example of a client item definition entry
; The real syntax varies by season and client
[Item]
Category = 12        ; wings category (example)
Index    = 40        ; chosen free index
Name     = "Asa da Aurora"
Model    = "Wing40.bmd"
Texture  = "Wing40.OZJ"
Effect   = 3         ; glow effect identifier

Notice that the field names above are illustrative. The point that doesn't change between emulators is the relationship: a category/index pair pointing to a model, a texture and, optionally, an effect.

Visual sets: the quirks of multiple pieces

A set is more work than a pair of wings because it isn't a single piece. It's made up of armor, pants, gloves, boots and, sometimes, a helmet, each living in its own category and index. For the look to be cohesive, all pieces need to use the same texture theme and, ideally, the same relative index within their categories, which makes maintenance easier. Many clients expect the pieces of the same set to share a common numeric index across the different categories, so planning this numbering before creating the files avoids rework.

Besides the pieces, sets often have a set effect, that glow that appears when the player equips all the parts. This effect is usually controlled by a separate definition, which checks whether the character has the complete set and only then applies the aura. If you add a new set and the set glow doesn't appear, the problem is almost always in that set-bonus definition, not in the individual models. It's also worth paying attention to modeling by race and sex: in MU, many sets have mesh variations for male and female characters, and forgetting one variation makes the set disappear for only one of the sexes.

Synchronizing server and client

This is the section that solves ninety percent of the problems reported by those who add visual items. Synchronization isn't an optional finishing step; it's the heart of the process. The server and the client keep independent definitions that need to agree on three things: the item's ID, that is, the category and index pair; the item's existence, that is, it must be registered on both sides; and distribution, that is, all players must have the visual files.

The healthy publishing flow is always the same. First you add and test everything in a local environment. Then you package the new visual files into a client patch, that set of files the launcher downloads before the game opens. Only then do you apply the change on the production server and release the patch to players at the same time. Order matters: if the server starts dropping an item whose visual players don't yet have, they'll see broken items and report bugs en masse. An experienced administrator coordinates both ends so the server definition and the client patch arrive together. To understand the other side of this equation, with the preparation of the infrastructure that hosts these definitions, it's worth reviewing the guide on how to build a MU server from scratch, which puts into context where item definitions fit in the overall architecture.

Testing the item before publishing

Testing isn't equipping the item once and finding it pretty. A serious test goes through several scenarios that reveal bugs which only appear in specific situations. Start by equipping and unequipping the item several times, watching whether the model loads and unloads without leaving any visual residue. Then test with characters of different sexes and classes, because many visuals have variations that may be missing. Check the item in motion, with the character running, attacking and using skills, since wings in particular have animation and attachment points that can fail during movement.

A test many people forget is the multiplayer one. Put two characters on the same screen, one equipping the item and another observing, to make sure the visual appears correctly to third parties and not only to the person using it. Finally, monitor memory usage and stability: a poorly optimized model can crash the client when many players with the same item gather on one screen, as in castle siege events.

Common errors and fixes

The table below gathers the problems that appear most when adding visual items and the diagnostic path for each. Use it as a quick reference when something goes wrong.

In most of these cases, diagnosis starts by asking whether the problem is server, client or synchronization. Items that disappear only for some players are almost always a patch distribution problem; items that appear broken for everyone are a visual file problem; items that can't even be equipped are a server definition problem.

Optimization and best practices

Once you master the basics of adding an item, it's worth investing in practices that keep the project healthy in the long run. Keep a spreadsheet or document with all the custom items you've added, recording category, index, name and the date they went in. This control avoids future conflicts and makes life easier for anyone who inherits the administration. Standardize the naming of the visual files following the item's index, which makes it obvious which file belongs to which item.

Also take care of model optimization. A wing model with an excessive polygon count may look great on an empty screen and destroy performance in an event with dozens of players. Prefer models with lean geometry and textures at a resolution compatible with what your season's client supports. Finally, version your patches: every time you release a set of new items, keep a copy of that patch with a version number, so you can revert to a known state if a new item causes problems in production.

Launch checklist

Before releasing new visual items to players, go through this list. Each checked item is one eliminated source of bugs.

• Full client and server backup done
• Category/index pair confirmed as free on both sides
• BMD model saved with the compatible tool and tested
• Textures converted to the correct OZ format and correct dimensions
• Item definition registered in the client
• Item definition registered on the server with attributes and restrictions
• Glow or aura effects configured, when applicable
• Variations by sex and class checked
• Equip, unequip and movement test done
• Visibility test for other players done
• Client patch packaged and versioned
• Publishing coordinated between server and patch distribution
• Custom item control document updated

Following this flow turns a task that scares many people into a repeatable, predictable process. The first wing you add will take hours; the tenth will take minutes, because you'll have internalized the logic that server and client are two halves that must always speak the same language. Remember that everything here is an illustration of real concepts, and that file, folder and field names vary by season and client, so adapt each step to your specific package and always test in a local environment before exposing it to the community.

Frequently asked questions