How to Configure Drops by Map and Monster on Your MU Server

Understanding the MU Online Drop System

Item drops in MU Online are not random in a simple sense. The server evaluates a structured loot table every time a monster dies, running through probability checks for each configured entry. Knowing how this system is layered lets you craft a balanced economy where players feel rewarded without trivializing progression.

At a high level, the drop pipeline works as follows:

1. The GameServer identifies the dead monster by its numeric ID.
2. It looks up all drop entries associated with that monster.
3. For each entry it rolls a random number against the configured probability.
4. The first entry that passes (or all entries, depending on emulator settings) becomes the dropped item.
5. If a map-level override exists for that monster on that map, it takes precedence over the global rule.

Understanding this order of evaluation is critical before you touch any configuration file.

Locating the Drop Configuration Files

Before editing anything, map out where the relevant files live on your server installation.

Typical directory layout:

GameServer/
  Data/
    Monster.txt         → Monster definitions and IDs
    Item.txt            → Item definitions and codes
    ItemDrop.txt        → Global drop table (monster → item mappings)
    MapDrop/
      00_Lorencia.txt   → Map 0 (Lorencia) drop overrides
      01_Dungeon.txt    → Map 1 (Dungeon) drop overrides
      32_Icarus.txt     → Map 32 (Icarus) drop overrides
      ...
  Config/
    droprate.ini        → Global drop rate multipliers

Not all emulators use the MapDrop/ subfolder convention. Some encode the map index directly inside the main drop file using an extra column. Open your ItemDrop.txt in a text editor and examine the column count — that will tell you which format your build uses.

> [!TIP] > Always work on a copy of the original files before making changes. Keep a Data/Backup/ folder and copy the unmodified files there with a date suffix (e.g., ItemDrop_20260501.txt). This lets you roll back instantly if a misconfiguration wipes out all drops.

Reading and Editing ItemDrop.txt

The standard column layout for ItemDrop.txt is:

// MonsterID  MapIndex  ItemType  ItemCode  MinLevel  MaxLevel  DropRate  MaxExc  MaxLuck  MaxSkill
//
// MonsterID  → numeric ID from Monster.txt (e.g., 6 = Bull Fighter)
// MapIndex   → -1 means all maps; 0 = Lorencia, 1 = Dungeon, 7 = Atlans, 32 = Icarus
// ItemType   → item category (0 = Sword, 4 = Armor, 14 = Gems, etc.)
// ItemCode   → item index within that category
// MinLevel   → minimum item level that can drop
// MaxLevel   → maximum item level that can drop
// DropRate   → probability out of 100000 (e.g., 100 = 0.1%, 1000 = 1%)
// MaxExc     → maximum number of excellent options (0 to 6)
// MaxLuck    → 0 = no luck, 1 = luck possible
// MaxSkill   → 0 = no skill, 1 = skill possible

6    -1    0    5    0    6    800    0    0    0    // Bull Fighter → Valiant Sword (all maps)
6     1    0    5    0    9   1200    2    1    1    // Bull Fighter → Valiant Sword +exc (Dungeon override)
15   -1    4    3    0    6    500    0    0    0    // Skeleton Warrior → Plate Armor (all maps)
15    7    4    3    4    9   2000    4    1    1    // Skeleton Warrior → Plate Armor +exc (Atlans override)

Key points:

• A MapIndex of -1 is a wildcard — the rule applies everywhere the monster spawns.
• A rule with a specific MapIndex overrides the -1 rule for that map only.
• DropRate is expressed per 100,000. A value of 500 means 0.5% chance. Avoid setting any single entry above 70000 unless you intentionally want near-guaranteed drops.
• MaxExc controls excellent options. Setting this to 0 means the item can never drop with excellent attributes, regardless of the player's luck or map tier.

Configuring Per-Map Drop Tables

Map-based overrides let you create progression zones where later maps reward better loot. The recommended workflow is:

1. Set conservative global rules in ItemDrop.txt (low levels, no excellent, modest rates).
2. Add MapDrop/ files for high-tier maps, raising levels, excellent caps, and rates.
3. Verify monster spawn assignments match the correct map index in your MonsterSetBase.txt or equivalent spawn file.

Example: Icarus (map 32) drop override file

// MapDrop/32_Icarus.txt
// Only entries listed here are active for map 32.
// Monsters not listed fall back to ItemDrop.txt global rules.

// MonsterID  MapIndex  ItemType  ItemCode  MinLevel  MaxLevel  DropRate  MaxExc  MaxLuck  MaxSkill

// Alquamos (ID 51) — boss-tier drops
51   32    0   22    8   15   2000    6    1    1    // Alquamos → Sword of Destruction exc
51   32    4   18    8   15   1500    6    1    1    // Alquamos → Dragon Armor exc
51   32   14    3    0    0   3000    0    0    0    // Alquamos → Jewel of Bless

// Thunder Bird (ID 49) — regular mobs
49   32    4   16    6   12    900    3    1    1    // Thunder Bird → Dark Phoenix Armor
49   32    5   14    6   12    700    2    1    0    // Thunder Bird → Dark Phoenix Gloves
49   32   14    4    0    0   2500    0    0    0    // Thunder Bird → Jewel of Soul

> [!WARNING] > If you list a monster in a MapDrop file but that monster does not actually spawn on that map (according to your spawn tables), the entries are loaded into memory but never triggered. This wastes no server resources but is a common source of confusion during testing. Always cross-check monster IDs against spawn files.

Adjusting Global Drop Rate Multipliers

Beyond individual entry rates, most emulators expose a global multiplier in droprate.ini or a similar configuration file. This lets you apply a server-wide rate boost without touching every single entry.

; droprate.ini
; All per-entry DropRate values are multiplied by this factor at runtime.
; 1.0 = normal rates (default)
; 2.0 = double drop event
; 0.5 = half rates (economy tightening)

GlobalDropMultiplier = 1.0

; Separate multiplier for excellent item drops only
ExcellentDropMultiplier = 1.0

; Separate multiplier for Jewels (ItemType 14)
JewelDropMultiplier = 1.2

Using multipliers for events (like a weekend double-drop) is far safer than editing the base drop table, since you only change one value and revert it after the event. Never raise GlobalDropMultiplier above 5.0 on a live server without testing in a local environment first — the item economy can collapse within hours.

Testing and Validating Your Configuration

After editing files, follow this validation checklist before restarting a live server:

1. Syntax check — Open the edited file in a text editor that shows line numbers. Confirm no line has extra or missing columns. A misaligned column silently corrupts every subsequent line in some parsers.
2. Item code verification — Cross-reference every ItemType/ItemCode pair against your Item.txt. Invalid codes produce no error message; the drop simply never appears.
3. Rate sanity check — Sum the DropRate values for each monster. If the total exceeds 100,000, the monster effectively guarantees a drop on every kill, which may not be intended.
4. Restart the GameServer process — Drop tables are loaded once at startup. A configuration reload command (if your emulator supports one) may work, but a full restart is the safest option.
5. Kill-test in game — Spawn a test character, equip it with max Magic Find if applicable, and kill 20 to 50 of the target monster. Track what drops and compare against expected rates.

> [!TIP] > Keep a simple kill-log spreadsheet during testing. Record the monster, the map, the number of kills, and every item that dropped. With 50 kills you get a rough sense of whether your 2% rate is behaving correctly (expect roughly 1 drop per 50 kills). With 200 kills your sample is reliable enough to catch significant misconfiguration.

Common Mistakes and How to Avoid Them

Wrong map index — Maps are indexed starting from 0. Lorencia is map 0, not map 1. Using the wrong index causes rules to apply to the wrong zone or not at all.

Confusing ItemType and ItemCode — ItemType is the category (Sword = 0, Shield = 6, Helm = 7, Armor = 8, Pants = 9, Gloves = 10, Boots = 11). ItemCode is the specific item within that category. A common error is treating the in-game item ID as an ItemCode directly.

Forgetting to account for monster variants — Many maps spawn multiple variants of the same base monster (normal, elite, dark). Each variant has a different monster ID. If you only configure drops for the base ID, elite variants inherit no special drops.

Overlapping map overrides — If both ItemDrop.txt and a MapDrop/ file define rules for the same monster on the same map, the behavior depends on the emulator. Some engines merge both rule sets; others use only the most specific match. Test explicitly rather than assuming.

With these fundamentals in place you have full control over every item that appears on your server — from the weakest goblin in Lorencia to the most powerful boss in Icarus.

Perguntas frequentes