How to edit textures (OZJ/OZT) in the MU Online client

Editing the MU Online client's textures is probably the most accessible and, at the same time, the most misunderstood visual customization in the game. Accessible because, at heart, you are working with images — recoloring an armor, redesigning the login screen, reworking the glow of a wing, or giving an item a fresh look. Misunderstood because these images are not in a common format: MU stores everything in encrypted files with the extensions OZJ and OZT, which no image editor opens directly, and which carry technical rules — alpha channel, power-of-two dimensions, mipmaps — that, if ignored, turn a simple edit into a blurry texture, one with the wrong background, or one that makes the client stutter. This tutorial is for the advanced admin who wants to truly understand MU's texture pipeline: what OZJ and OZT are, how to decrypt them, edit them without destroying quality, and re-encrypt them into the format the client reads, ending with distribution through the launcher. As always, tools, extensions, and details vary by season and client; treat the examples as illustrations of real concepts and validate them in your own package.

Prerequisites

Before converting your first image, prepare the environment:

• A full backup of the client's texture folders (Data and subfolders like Item, Interface, Object, Player, Monster).
• A test client separate from the one players use.
• An OZJ/OZT conversion tool compatible with your season, capable of decrypting and re-encrypting in batch.
• An image editor that supports JPG and TGA with an alpha channel (Photoshop, GIMP, or equivalent).
• The patience to test each texture in the game before distributing it.
• A working server and client base already in place. If you are still setting up the project, start with the guide on how to create a MU Online server.

> Textures are cosmetic, but a backup is still mandatory. Saving over the original encrypted file without a copy is the mistake that causes the most rework.

What OZJ and OZT are

MU Online does not distribute "raw" JPG or TGA images inside the client; it wraps them in proprietary encrypted formats to discourage casual editing and standardize loading. The two most common are:

In practice, an OZJ is a JPG file with a small extra header prefixed to the start of the data. The OZT is a TGA with equivalent handling, and because it's a TGA it carries the alpha channel, which stores transparency pixel by pixel. That difference is the most important point of the format: OZT has transparency, OZJ does not. Choosing the wrong format for a texture results in opaque edges where there should be transparency, or in wasted memory.

The pipeline: decrypt, edit, re-encrypt

Editing a MU texture always follows the same three-stage cycle. Understanding this cycle is understanding 90% of the work.

1. Decrypt/convert. You take the OZJ or OZT and convert it to the corresponding common format (JPG or TGA) using your package's tool. It's that common file that opens in the image editor.
2. Edit. You alter the image in Photoshop, GIMP, or similar — changing colors, redrawing, applying effects — respecting dimensions and the alpha channel.
3. Re-encrypt/convert back. You turn the edited JPG/TGA back into an OZJ/OZT and replace the original file in the client folder.

# Conceptual flow
armadura01.OZJ  --(convert)-->  armadura01.jpg
armadura01.jpg  --(edit in GIMP)-->  armadura01_nova.jpg
armadura01_nova.jpg  --(convert)-->  armadura01.OZJ   # replaces it in the client

# For transparency, the path is analogous with TGA:
asa03.OZT  --(convert)-->  asa03.tga  --(edit preserving alpha)-->  asa03.OZT

The delicate point is stage 3: when re-encrypting, you must keep the exact name of the original file, because the BMD models and the interface reference textures by name. Renaming breaks the reference and the texture simply doesn't show up.

Power-of-two dimensions and why they matter

MU's graphics engine expects textures with power-of-two dimensions: 32, 64, 128, 256, 512, 1024 pixels per side (they don't have to be square, but each side must be a power of two). This comes from a classic graphics-hardware limitation and from the mipmap system — reduced versions of the texture that the engine uses when the object is distant, to save processing and avoid shimmering.

If you save a texture at, say, 500x300, one of two things happens: either the tool resamples it to the nearest power of two (blurring the image), or the client displays artifacts. That's why, when editing, you should keep the original resolution whenever possible. If you need more detail, go up to the next power of two (for example, from 256 to 512), never to an intermediate value. Downsizing follows the same rule.

> When editing interfaces (HUD, windows, buttons), dimensional fidelity is even more critical: one pixel more or less misaligns the entire screen layout, because the interface's clipping coordinates are fixed.

Alpha channel: the secret of OZT

The biggest stumbling block for those starting to edit MU textures is the alpha channel. In an OZT, on top of the color channels (red, green, blue), there is a fourth channel — the alpha — that defines, for each pixel, how opaque or transparent it is. White in the alpha = fully visible; black = fully transparent; shades of gray = semi-transparent.

When you edit a wing, a magic effect, or an interface icon with soft edges, it's the alpha channel that makes the edges dissolve into the scene instead of appearing as a solid rectangle. When saving a TGA, you must export with the alpha channel preserved (32-bit TGA). If you save as a 24-bit TGA, you lose transparency and the wing becomes an opaque block. In the editor, work the alpha as a separate mask and check it before exporting. Different tools call this "save alpha" or "include alpha channel" — find that option and keep it checked.

Where the textures live and what you can rework

The client's textures are spread across themed subfolders within Data. Knowing this organization helps you locate what you want to edit:

Reworking the login screen and the logo, for example, is one of the first customizations that give a server its identity. Swapping the color palette of an armor set creates exclusive sets. Redesigning interface icons modernizes an old client. It all goes through the same pipeline of decrypt, edit, and re-encrypt.

Distribution through the launcher

Here's an important distinction compared to maps and monsters: textures do not require synchronization with the server, because they are purely cosmetic — the server never validates the appearance of an image. This means that, technically, each player could have different textures. In practice, you want everyone to see the same look, both for identity and because custom interface and item textures are part of the experience you designed.

For that reason, distribute the edited textures through the launcher/updater, packaging the OZJ/OZT files into the patch. The player downloads the new images before logging in. Since textures tend to be larger files than configuration files, organize the patch's versioning well so you don't force huge downloads for every small color change. A game-security detail: because the server doesn't validate textures, malicious players sometimes edit their own textures to "see through walls" or highlight enemies — that's an inherent limitation of MU's client model and is countered by other layers (anti-cheat), not by the texture itself.

Common errors and fixes

Launch checklist

• Backup of the client's texture folders before any editing
• Correct format identified (OZJ solid, OZT with alpha)
• Textures converted to JPG/TGA with the package's tool
• Editing done keeping power-of-two dimensions
• Alpha channel preserved in the OZT files (32-bit TGA)
• Original resolution kept, especially in interfaces
• Files re-encrypted with the exact original name
• Each texture tested in the game (item, scenery, interface, distance)
• Mipmaps/level of detail checked up close and from afar
• Textures packaged into the launcher/updater and the patch versioned
• Final test with a "clean" client downloading via the patch

Editing textures is the perfect entry point for starting to customize the MU client: the risk is low (nothing breaks the server), the visual payoff is immediate, and the pipeline is the same for everything — decrypt, edit while respecting alpha and power-of-two, re-encrypt keeping the name. By mastering this cycle, you can give your server a unique face, from a memorable login screen to armor sets players will only find in your world.

Frequently asked questions