How to create custom items in the MU Online ItemList

Adding an item that nobody else has is one of the fastest ways to give your MU Online server its own identity. An exclusive wing, a set with a unique look or a memorable event weapon make players feel that world is not a generic copy. But "creating a new item" in MU is not a single action: it is a chain of steps that has to line up on three fronts at once — the server item list, the client item list and the graphics files (BMD model and textures). If any of those fronts falls out of sync, the result ranges from an invisible item to a mass disconnection when someone drops the item on the ground.

This tutorial walks through the full ItemList process: understanding how items are organized by section and index, finding a genuinely free index, registering the item on the server side, mirroring that entry on the client, associating the 3D model and texture, defining options and excellents, testing in an isolated environment, and finally packaging everything into a patch to distribute. The focus is on the real, reusable concept; wherever file names and columns vary, I treat them as an example and flag that they "vary by emulator." If you don't have a server base running yet, it's worth first following the guide on how to set up a MU Online server and coming back here afterward.

Prerequisites

Before touching any file, make sure the environment is ready and that you have a way to roll back.

• A working server in a test environment. Never make your first attempt straight in production. Keep a local copy (or a VM) of the GameServer, DataServer/ConnectServer and the database.
• A client compatible with the server's season. The ItemList format and folder structure change a lot between seasons.
• Your emulator's ItemList editor. It may be a dedicated GUI tool, a plain text editor or a utility that reads/writes the binary format. It varies by emulator.
• A full backup. Copy the original ItemList files (server and client), the database and the client's data folder before you start. A 30-second backup saves a 3-hour reinstall.
• Model tools, if you're going to use a new look. A BMD viewer/converter and an image editor that exports in the expected texture format (usually OZJ/OZT/OZB, depending on the season).
• A sense of which indexes are taken. Keep your emulator's default item list handy so you don't pick an index that is already used.

With that in place, the work is safe and reversible.

How the ItemList is organized

In MU, each item is identified by a pair: section (type) and index. The section groups categories — for example, swords, axes, bows, armor sets, wings, pets and consumables live in distinct sections. Within each section, the index is that item's number in that category.

Think of the layout as a spreadsheet with tabs: each tab is a section, each row is an index. A "Dragon Set" and a "Legendary Staff" live in different sections, but both have a row number inside their tab. When the server tells the client "the character is wearing the item from section X, index Y," the client looks up exactly that row to know the name, the model, the inventory size and the appearance.

That is why server and client must agree on the same section+index pair. If on the server index 300 of the weapons section is your "Phantom Weapon" and on the client index 300 is still empty (or is something else), the game breaks.

The table below shows a conceptual example of how sections are usually split. The exact numbers vary by emulator and season, so treat it as an illustration, not a fixed value.

Step 1 — Pick a free index

This is the most important step and the most overlooked. An "apparently empty" index may be reserved internally for a summon, an event item or a system placeholder.

1. Open your emulator's default item list (documentation or the original ItemList itself).
2. Choose the correct section for your item's type (a sword goes in the swords section, a wing in the wings section).
3. Scroll through the indexes and find a number that is clearly unused — no name, no associated model, outside the reserved ranges.
4. Prefer high indexes, well away from system items. Many emulators reserve the early ranges for official items and the higher ranges for customization.
5. Write the section+index pair down in a document. You'll reuse that same pair on the server, the client and the patch.

Golden rule: when in doubt, don't use it. Better to spend 5 minutes confirming in the documentation than to find out in production that the index collided with the "Box of Kundun."

Step 2 — Register the item on the server

With the pair defined, register the item in the server-side ItemList. This is where the GameServer learns that the item exists, along with its base level, class requirements, damage/defense, durability and drop rules.

The exact fields and file format vary by emulator. In some it's a text/CSV file; in others, a database table or a binary edited by a dedicated tool. Conceptually, you'll fill in something like the example below (illustrative format):

# Conceptual example of a server ItemList entry
# Real fields vary by emulator
Section=0
Index=300
Name=Phantom Sword
Level=0
Slot=1            # equipment type (one-handed weapon)
Width=2 Height=4  # space taken in the inventory
DropLevel=120
MinDmg=180 MaxDmg=210
Durability=45
ReqStrength=520 ReqAgility=280
ReqClass=DK,MG    # classes that can use it
Serial=1          # generates a unique serial number
Option=1          # accepts options (+add)

Steps:

1. Locate the server's ItemList file/table (e.g. ItemList in the GS data folder — varies by emulator).
2. Add a new line/entry using exactly the Section and Index you chose.
3. Fill in the name, attribute requirements, allowed classes and combat values consistent with the server's balance.
4. Set the inventory size (width x height). If you get it wrong, the item can overlap other slots.
5. Flag whether the item accepts a serial (unique number) and an option (extra bonus). Sets and wings normally accept both.
6. Save the file keeping the original encoding (many emulators require ANSI, not UTF-8).

Step 3 — Mirror the item on the client

Now repeat the registration of the same section+index pair in the client ItemList. The client doesn't need to know about damage or combat requirements — that's the server's job — but it does need to know the name, inventory size, associated model and texture.

1. Open the client ItemList (usually inside the game's Data folder — name and format vary by emulator).
2. Create the entry at the index identical to the server's.
3. Set the displayed name. Ideally the same as the server's to avoid confusion, but what the player reads is decided by the client.
4. Point to the model (BMD file) and the texture the item will use (next step).
5. Save keeping the expected encoding.

If the client doesn't have the entry and the server tries to send the item, the typical behavior is an invisible item, a "corrupted" name or a connection drop when equipping/dropping. That's why mirroring is mandatory.

Step 4 — Associate the BMD model and texture

Here you decide whether the item will have its own look or a reused one.

Option A — reuse an appearance (simpler): point to the model and texture of an existing item. Your "Phantom Sword" uses a standard sword's BMD but has an exclusive name, attributes and options. Great for a quick launch.

Option B — brand-new look (more work): import a new BMD and its textures.

1. Place the BMD file in the model folder that matches the section (e.g. Data\Item\ for items — varies by emulator).
2. Name the BMD following the convention the client expects for that section and index. Many emulators use a naming pattern derived from the index; check yours.
3. Export the textures in the accepted format (OZJ/OZT/OZB per the season) and place them in the same folder.
4. Verify that the BMD references the correct texture names internally — a BMD pointing to a nonexistent texture shows up black or invisible.
5. Confirm the scale and attach point: a weapon with the wrong scale can look gigantic on the character's back or misaligned in the hand.

Naming blocks vary quite a lot by emulator, so use the pattern of a neighboring item in the same section as a reference.

Step 5 — Define options, excellents and sockets

A new item is rarely just "base." In MU, competitive value comes from the extra layers:

• Additional option (+add): increments like +damage, +defense, +life.
• Excellent: a set of special bonuses (life/mana leech, extra % damage, speed).
• Ancient/Set: set bonuses when several pieces are worn together.
• Sockets/Seed: slots for elemental stones (when the season supports it).

On the server, you enable which of these layers the item accepts and, in the drop/chaos machine system, define the odds of each one appearing. Keep it consistent with the balance: a new item with a guaranteed excellent and stats above the official ones will wreck the server's economy within a week.

Step 6 — Test in an isolated environment

Never skip the test. Use a GM account on the test server.

1. Restart the GameServer to load the new ItemList.
2. Spawn the item via a GM command or a forced drop.
3. Check: correct name, inventory icon, space taken, appearance when equipped.
4. Drop the item on the ground — this is the test that most often reveals desync; badly registered items tend to drop the connection right here.
5. Equip it, unequip it, store it in the vault and trade it with another account.
6. Apply an option/excellent and confirm the bonuses work in combat.

Only move on to distribution when all these steps pass without errors.

Step 7 — Distribute the item to players

You update the server once; every player's client needs to receive the new files.

1. Identify the files that changed on the client side: the client ItemList, the new BMD and the textures.
2. Package only those files into a patch (don't force everyone to re-download the entire client).
3. Publish the patch through your autoupdate/launcher, bumping the version.
4. Test the download on a clean machine, the way an ordinary player would.
5. Announce on the site/Discord that there's an update and what it brings.

The player opens the launcher, downloads only what changed and sees the item. If you update the server but forget to publish the client patch, everyone who receives the item will see a bug — so server and patch go together.

Common errors and fixes

Launch checklist

• Backup of the ItemLists (server and client), database and client data folder
• Section+index pair confirmed free in the emulator documentation
• Entry created in the server ItemList with consistent stats and requirements
• Entry mirrored in the client ItemList at the identical index
• BMD and textures in the correct format and name (or reused from an existing item)
• Options/excellents/sockets configured per the balance
• GameServer restarted in the test environment
• Item tested: inventory, equip, drop on the ground, vault and trade
• Patch with only the changed files built and versioned
• Patch download tested on a clean machine
• Announcement published on the site/Discord

Following this sequence, creating a custom item stops being trial and error and becomes a predictable process. The secret is always to remember the three fronts — server, client and graphics — on the same index, to test the ground drop before anything else, and to distribute with a lean patch through the launcher.

Frequently asked questions