How to add custom visual effects (particles) in MU Online

Particle effects are what bring MU Online to life: the flaming trail of a skill, the pulsing glow of a +13 item, the golden aura of a VIP character. For a private server, mastering the client's particle system is one of the most effective ways to build your own visual identity without relying on third parties. This advanced guide shows how the client's built-in particle emitter works, how to prepare the right textures, how to register new effects, and — perhaps most importantly — how to keep everything performant so you don't sacrifice FPS during events and mass PvP.

All the work here is done on the client side. The server merely fires the trigger ("activate aura X on this character"); the appearance is 100% defined by the files you distribute. This means you have almost total freedom to reinvent the look — but it also means any conversion error or excess of particles will be felt by every player. If you don't yet have the client and server base ready, start with the guide on how to create a MU Online server before diving in here.

Prerequisites

• A MU client compatible with the server's season, working and connecting.
• An image editor with alpha support — GIMP or Photoshop, indispensable for particle textures (transparency is the heart of everything).
• A MU format converter (MU Image Converter) to generate .ozt/.ozj.
• A text/code editor — Notepad++ or VS Code for the effect definition files.
• An FPS monitoring tool (the client's own counter, or an external overlay) to measure the impact.
• A full backup of the Data/Effect folder and of any definition file before editing.

How MU's particle system works

The client's particle emitter follows a classic "emitter → particles → death" model. Understanding this cycle is what lets you build convincing effects:

1. Emitter — an origin point in 3D space (the character's hand, the center of an item, the feet of someone with a buff). It "spits" particles at a certain rate.
2. Individual particle — each particle is a billboard: a flat square with a texture that always faces the camera. It is born with a position, velocity, color, size, and lifetime.
3. Life cycle — over its life, the particle normally changes: it rises/falls, rotates, shifts color, and gradually turns transparent (fade out) until it dies and is recycled.

The final look emerges from the combination of three things: the texture (the drawing of each particle), the emission curve (how many are born per second and how long they live), and the color/opacity over time. A single "soft blob" sprite becomes fire, smoke, or glow depending only on these curves.

Effect types in MU

Effect file structure

The typical layout, remembering that it varies by season/client:

MUClient/
├── Data/
│   └── Effect/
│       ├── Fire01.ozt         ← flame sprite (with alpha)
│       ├── Spark01.ozt        ← spark
│       ├── Glow01.ozt         ← glow blob
│       ├── Smoke01.ozt        ← smoke
│       └── Effect.dat         ← definition (name/format varies)
├── Interface/
└── Main.exe

Step 1 — Create the particle texture

The texture is the "brick" of the effect. Golden rules:

1. Work on a small, square canvas — 32×32 or 64×64 pixels is enough for the vast majority of effects.
2. Draw on a transparent background (alpha channel). A bright center and soft edges are what make particles blend well when they overlap.
3. For glows and fire, use near-white tones in the center with a gentle falloff toward the edge — the final color will be applied by the emitter, so the texture can be practically monochrome.
4. Avoid hard, jagged edges: in motion they produce an unnatural "cut-out" look.
5. Export as a 32-bit .png (RGBA) to later convert to .ozt.

# PowerShell — check dimensions and presence of alpha in the source textures
# (requires ImageMagick installed)
Get-ChildItem "assets_effect\*.png" | ForEach-Object {
    $info = magick identify -format "%f %wx%h %[channels]" $_.FullName
    Write-Output $info
}

Step 2 — Convert the textures to the MU format

1. Open the MU Image Converter.
2. Drag in the RGBA .png and select .ozt output (the format with an alpha channel, essential for particles).
3. Check the generated file size — a valid 64×64 .ozt is a few KB; if it comes out tiny, the conversion failed.
4. Name it exactly as the index the effect expects (for example Fire01.ozt).
5. Copy it to Data/Effect/.

Step 3 — Register/parameterize the effect

If your client exposes text definitions, this is where the sprite gains behavior. The syntax varies, but the conceptual pattern of fields is quite stable:

// Effect.dat  (ILLUSTRATIVE format — varies by season/client)
// ID   Texture     Qty  LifeMs  InitVel  Grav   ColorRGB      FadeOut
[Effect]
201     Fire01.ozt   40   700     0.8     0.3    255,120,20    1
202     Glow01.ozt   20   1200    0.1     0.0    255,215,90    1
203     Spark01.ozt  60   500     1.5     0.6    255,255,200   1

Guide to the conceptual fields:

• Qty — how many particles the emitter keeps alive. It's the parameter that weighs most heavily on FPS.
• LifeMs — the lifetime of each particle in milliseconds. Long life + high count = a full screen.
• InitVel — initial velocity; defines the "spread".
• Grav — gravity; positive pulls down (heavy smoke), negative makes them rise (fire, sparks).
• ColorRGB — base color multiplied over the texture.
• FadeOut — whether the particle loses opacity over its life (almost always 1).

Practical steps:

1. Choose a free effect ID — never reuse an ID already used by another active effect, at the risk of a visual conflict.
2. Point to the converted texture.
3. Start conservative: low count and short life, then increase during testing.
4. Save as ANSI/UTF-8 without BOM.

Step 4 — Bind the effect to an item, skill, or state

Registering the effect isn't enough — something has to trigger it. The three most common bindings:

1. Item — associate the effect ID with the glow of a specific item (for example, the aura of a +13 item or an excellent set). The item→effect mapping varies by season/client.
2. Skill — link the effect to the skill's ID, so it appears on the cast or on impact.
3. State/buff — link it to a state the server activates (VIP, transformation, event buff), so the aura follows the character for as long as the state lasts.

Step 5 — Test and optimize performance

A beautiful effect that tanks the FPS in PvP is a bad effect. Test in a realistic scenario:

1. Enter an area and fire the effect repeatedly (multiple characters/items at once, if possible).
2. Watch the FPS counter. A buff aura that many players use simultaneously needs to be lightweight.
3. If the FPS drops, first reduce the count of particles, then the life, and only then the texture size.
4. Simulate a Castle Siege / crowded event scenario: dozens of active auras on the same screen. That's the worst case and what decides whether the effect is acceptable.

Suggested particle budget

Common errors and fixes

Launch checklist

• Backup of Data/Effect and the definition files done
• Textures created at 32×32 or 64×64 with an alpha channel
• Soft edges, bright center, ready for additive blending
• All textures converted to .ozt with a consistent size
• Effect IDs free, with no conflict with existing effects
• Count/life parameters started conservatively
• Effect bound to the correct item/skill/state
• Trigger validated with a GM character
• FPS test in a crowded PvP/event scenario passed
• Particle budget respected per usage type
• Definition files saved without BOM
• Client repackaged and the verification hash updated

With the particle pipeline mastered — a lightweight texture, a lean definition, the correct trigger, and a passed FPS test — you can produce an entire library of effects exclusive to your server. The gain isn't only aesthetic: well-made auras and glows communicate rarity, status, and power, and that directly feeds player engagement around items and achievements.

Frequently asked questions