How to add new maps to the MU Online client

Adding a new map to the MU Online client is one of the most complete tasks an administrator can take on from the client side: it involves understanding how the game represents terrain, collision, height, lighting and three-dimensional objects, and how all these files need to talk to each other and, above all, to the server. It's not a "copy and paste a folder" job; it's an exercise in understanding MU's world architecture and respecting the dependencies between client and emulator. This tutorial was written for the advanced administrator who already masters the basic structure of a server and now wants to expand the game world with a new map, be it a custom event scene, a PvP arena or an exclusive farm zone. As always in the world of emulators, the exact file names, IDs and folder structure vary by season and client; treat the examples below as an illustration of real concepts and always check your own package's organization before applying them.

Prerequisites

Before touching any file, make sure you have the minimum environment and knowledge to work safely:

• Full backup of the client's Data folder and the server's map configuration files. This is the non-negotiable step.
• A test client separate from the one players use, so you don't distribute broken files.
• A MU map editor compatible with your season (commonly called World Editor, MU Map Editor or similar).
• Encryption/decryption tools for EncTerrain files and converters for OZB, OZJ and OZT from your package.
• Access to the server's map configuration files (definitions for gates, safe zones, movement and spawns).
• If you haven't built the server base yet, start with the guide on how to create a MU Online server before moving forward here.

> Always work on copies. A single wrong byte in an encrypted terrain file can freeze the client at the loading screen with no clear error message.

How the client represents a map

In MU Online, each map is a grid of cells, traditionally 256 by 256 in the classic engine. Each cell carries texture, height, lighting and collision attribute information. The client assembles this scenery by reading a set of files that live inside a world folder, usually named WorldN, inside Data. The most common convention associates the World1 folder with map ID 0 (Lorencia), World2 with ID 1 (Dungeon), and so on — that is, N = ID + 1. This correspondence varies by client, so the first thing to do is open the Data folder and map which WorldN corresponds to which known map in your package.

Each world folder typically gathers the following files, which work together:

The number in the EncTerrain file names follows the map. In many packages EncTerrain1.* belongs to World1; in others the numbering is different. Don't assume — verify.

Step by step to create the new map folder

The safest way to start is from an existing map similar to what you want, and transform it, rather than generating everything from scratch. That way you inherit a file structure that already works.

1. Choose the map slot. Decide whether you'll reuse a rarely used slot or register a new ID. Reusing is simpler and more compatible; a brand-new ID requires support in the executable and the emulator.
2. Duplicate a base folder. Copy, for example, World1 to a new folder, say World52, if your client accepts that ID. Rename the internal files according to the convention (e.g., EncTerrain52.att, EncTerrain52.map, EncTerrain52.obj).
3. Open it in the map editor. Load the decrypted folder in your World Editor. This is where you'll redraw the terrain, paint textures, adjust height and position objects.
4. Edit the terrain and textures. Paint the tile layers, sculpt the relief with the height map and adjust the lightmap to the desired atmosphere.
5. Position the BMD objects. Trees, gates, statues and structures are .bmd models referenced by the objects file. They must exist in the world's corresponding object folder.
6. Define the collision attributes. In the attributes file, mark blocked cells (walls, impassable water), safe zones (where there's no PvP or damage) and walkable areas.
7. Re-encrypt the files. When you're done, generate the encrypted EncTerrain files and the OZB/OZJ back in the format the client reads.

> Poorly marked safe zones are a classic source of complaints: players dying in what should be a protected area, or PvP being impossible in an arena. Review the .att carefully.

Height map, lightmap and the scene's atmosphere

The height map (TerrainHeight.OZB) is what gives the map its relief. It's essentially a grayscale image where each pixel's value represents the height of that cell: lighter, higher; darker, lower. Editing it lets you create hills, depressions, ramps and plateaus. A common mistake is generating height variations that are too abrupt, creating invisible "walls" where the character gets stuck. Work with smooth transitions and test by walking around the map.

The lightmap (TerrainLight.OZJ) controls the static lighting. It's where you define whether the map has a sunny, dark, reddish (typical of infernal maps) or bluish (icy maps) mood. Since it's an OZJ — an encrypted JPG — you can edit it in any image editor after converting it, painting areas of light and shadow. The combination of a well-sculpted height map and a coherent lightmap is what makes a map look professional instead of "flat".

The scene's BMD objects

The objects that populate the map — buildings, vegetation, decoration — are .bmd models stored in the world's object folder (something like Object52, matching the world number). The terrain's objects file (.obj) stores, for each instance, which model to use and where to position it, with rotation and scale. If you reference an object index that doesn't exist in the folder, the client may crash or simply not render that item. When bringing objects from another map, copy both the .bmd and its textures (OZJ/OZT) to the new world's folder.

# Conceptual illustration of an object entry in the scene
# (the real binary format is generated by the editor; this is only didactic)
ObjectIndex : 12        # which BMD from the world's Object folder
PositionX   : 128.0     # coordinate on the grid
PositionY   : 96.0
PositionZ   : 40.0      # height, aligned to the height map
Rotation    : 0,0,90    # degrees on the axes
Scale       : 1.0

Mandatory synchronization with the server

Here's the point that separates those who understand MU's architecture from those who just edit files: the map doesn't exist just because the client draws it. The server is the authority over where the player can go, what the real safe zones are, where the gates (teleport/entry points) are and which monsters appear. The client and the server must agree on the same map ID.

On the server side, adding the map typically involves:

• Registering the map ID in the emulator's map definitions.
• Configuring the gates (the movement/portals file) so there's a way to enter and leave the new map — by command, teleport NPC or connection to another map.
• Defining safe zones and PvP rules on the server side, which must match what you marked in the client's .att.
• Adding monster spawns if the map is for farming, referencing the same ID.

If the client has World52 but the server doesn't recognize map 51 (remembering the N = ID + 1 convention), the player will be disconnected or will see the scene with no coherent collision. The golden rule: same ID on both sides, always.

Distribution via launcher

After testing exhaustively in a local environment, the map needs to reach players. The launcher/updater is what does this: you package the complete WorldN folder (the EncTerrain, OZB, OZJ, tile files) and the corresponding object folder, and add these files to the patch. When the player opens the game, the launcher downloads the new files before connecting. Without the local files, the client can't assemble the scene — so distribution isn't optional. Keep the patch versioning organized so those who already have the map don't download everything again, and so new players receive the complete set.

Common errors and fixes

Launch checklist

• Full backup of the client's Data folder and the server's map configs
• Map slot/ID defined and confirmed on both sides (client and server)
• WorldN folder created with all EncTerrain, height, light and tiles
• BMD objects and their textures present in the world's object folder
• Collision attributes and safe zones reviewed in the .att
• Height map tested by walking across the whole map
• Lightmap coherent with the intended atmosphere
• Files re-encrypted in the format the client reads
• Server with ID registered, gates, safe zones and spawns configured
• Entering and leaving the map tested by command and/or NPC
• Map package added to the launcher/updater and versioned
• Final test with a "clean" client downloading via patch

Adding a map is, at its core, a coordination job: dozens of files that need to be coherent with each other and with the server. Take it slow, test each stage in isolation and never skip the backup. A well-made new map is one of the most striking ways to give your server an identity and surprise players who have already seen every classic MU scene.

Frequently asked questions