How to configure the LogServer and auditing in MU Online

A MU Online server without auditing is a blind server. Sooner or later someone will duplicate an Excellent, steal a veteran player's account or abuse a GM command, and you will need to answer a simple question that, without data, becomes impossible: what exactly happened, when and by whom? The LogServer is the component responsible for turning every relevant game event into a permanent, chronological trail. This tutorial shows, from scratch, how to plan what to record, configure the LogServer, define retention policies, protect record integrity and run real fraud investigations from the logs. The focus is conceptual and practical at the same time: the MU concepts are real and universal, while the file names and configuration keys appear only as examples and vary by emulator.

Prerequisites

Before touching any file, have the basic environment working. If you have not yet set up the full structure, start with the guide on how to create a MU Online server and come back here once the GameServer boots normally.

• GameServer, ConnectServer and database (MSSQL on most emulators) already operational.
• Administrative access to the Windows server (or host) where the services run.
• A dedicated database user, with write permission only on the log tables.
• Planned disk space: logs grow fast on populated servers.
• System time synchronized via NTP across all machines involved.
• A working backup already configured, so the logs themselves join the copy routine.

Also make one architecture decision before you begin: do the logs go to text files, to a separate database, or to both? The recommendation for serious servers is a separate database as the primary source (fast queries) and rotated files as a raw contingency copy.

What the LogServer is and where it fits

In a typical MU Online stack you have the ConnectServer routing players to the GameServers, the DataServer (or JoinServer) mediating database access, and the GameServer running the world logic. The LogServer is a separate service that receives events sent by the GameServer over a dedicated TCP port and persists them. It does not interfere with gameplay: if it goes down, the game keeps running, but you stop collecting the trail. That is why it must be resilient, yet must never be a blocking point for the GameServer.

The crucial understanding is the difference between state and history. The production database shows the current state: the character's inventory now, the zen on the account now. It does not tell how that item got there. The LogServer fills that gap by recording the sequence of events that led to the current state. Without history, you see the result of a fraud, but never the method.

Which events to record

Recording everything is tempting and wrong: it generates unpayable volume and noise that hinders the investigation. The right approach is to record the high forensic-value events, the ones that underpin most disputes and fraud.

Beyond the event itself, each record must carry minimum metadata: a timestamp with second-level precision or better, account ID, character name, source IP, and a session identifier when the emulator provides one. Poor metadata is the number one cause of investigations that stall.

Configuring the LogServer: step by step

The names below are examples and vary by emulator; the logic is the same in all of them.

1. Locate the LogServer executable and configuration file. It usually sits in its own folder inside the server directory, with a file like LogServer.ini or equivalent.
2. Set the listening port. Pick an internal port that only the GameServer can reach, for example 55906. Never expose this port to the internet.
3. Point to the write destination. If it is a database, provide the connection string for the separate log database; if it is files, define the output folder and the name pattern with the date.
4. Enable asynchronous writing. This ensures the GameServer delivers the event and moves on without waiting for the disk.
5. Configure the GameServer to send to the LogServer. In the GameServer configuration file, point to the LogServer IP and port and turn on the desired log categories.
6. Set the level of detail per category. Trade and GM commands at maximum detail; very high-volume events can go at a summarized level.
7. Bring the LogServer up before the GameServer. The correct startup order avoids losing events at boot.
8. Validate with a controlled event. Run a test trade between two of your accounts and confirm it appears in the trail with all the metadata.

An illustrative configuration snippet (format varies by emulator):

[LogServer]
BindPort=55906
Mode=Database        ; or File
AsyncWrite=1
QueueMax=100000

[Categories]
Trade=Full
Drop=Full
GmCommand=Full
Login=Full
ItemHighValue=Full
Chat=Off

And on the GameServer side, the corresponding pointer:

[Logging]
LogServerIP=127.0.0.1
LogServerPort=55906
EnableTradeLog=1
EnableGmCommandLog=1
EnableDropLog=1

Log table structure

If you go with a database, a well-designed table speeds up any investigation. An example schema:

CREATE TABLE GameLog (
    LogId       BIGINT IDENTITY PRIMARY KEY,
    EventTime   DATETIME2   NOT NULL,
    Category    VARCHAR(32) NOT NULL,
    AccountId   VARCHAR(32) NULL,
    CharName    VARCHAR(32) NULL,
    SourceIp    VARCHAR(45) NULL,
    TargetName  VARCHAR(32) NULL,
    ItemCode    VARCHAR(64) NULL,
    Amount      BIGINT      NULL,
    RawDetail   NVARCHAR(MAX) NULL
);
CREATE INDEX IX_GameLog_Time ON GameLog (EventTime);
CREATE INDEX IX_GameLog_Char ON GameLog (CharName, EventTime);
CREATE INDEX IX_GameLog_Cat  ON GameLog (Category, EventTime);

The indexes by time, by character and by category cover almost all forensic queries. The RawDetail field stores the event's full payload as text, ensuring nothing is lost even if the schema evolves.

Retention and rotation

Useful logs are logs you still have when the problem appears. And problems appear late: a player reports a theft weeks after it happened. At the same time, keeping everything forever is expensive and degrades query performance. The answer is a layered retention policy.

Automate the transition between layers. A nightly job can export records older than 90 days to daily .csv.gz files and remove them from the hot table. Size-based rotation also applies to file logs: close and compress the current file when it reaches, say, 200 MB, avoiding monstrous files that are impossible to open.

Integrity: logs you can trust

A log that can be tampered with is no good for banning anyone. Treat the trail as evidence and protect its integrity.

• A database account with only insert and select permissions, never update/delete for the log service. The LogServer should never need to erase a record.
• A log server isolated from the production database, preferably on another machine or instance, so that a breach of the game does not compromise the trail.
• Time synchronized by NTP on all nodes. Without it, correlating events across GameServers becomes guesswork.
• Optional chained hashing for high-assurance cases: each record stores the hash of the previous one, making any removal detectable.
• Backups of the trail included in the general routine and tested by restoration.

Investigating fraud in practice

Here the logs stop being a file and become a tool. Consider a classic case: a player reports losing a rare Excellent after a trade. The investigation script:

1. Fix the target and the window. The victim's character name and the approximate time of the trade.
2. Pull the character's timeline. Query every event for that character in that interval, ordered by time.
3. Isolate the trade. Find the trade event, look at both sides, the items and the confirmation. Confirm whether the item left the victim's inventory.
4. Follow the item. Use the item code to track where it ended up: who received it, and what that account did next.
5. Correlate accounts and IPs. If the receiving account and a second account share an IP or HWID, you have probably found a multi-account scheme.
6. Close the chain. Combine login, trade, drop and later movement into a single narrative before deciding on the sanction.

An example timeline query:

SELECT EventTime, Category, CharName, TargetName, ItemCode, Amount
FROM GameLog
WHERE (CharName = 'VictimHere' OR TargetName = 'VictimHere')
  AND EventTime BETWEEN '2026-03-10 20:00' AND '2026-03-10 22:00'
ORDER BY EventTime;

To detect item duplication (the same unique item appearing in two places), look for the same ItemCode of a serialized item being created or received by different accounts without a legitimate transfer event between them. Items that appear with no traceable origin are the signature of an exploit.

Proactive detection

Investigating after the damage is good; preventing the damage is better. The same trail feeds automatic alerts. Run periodic queries looking for anomalous patterns: zen gain above a threshold per hour, a number of trades per minute far above average, the same serialized item touching many accounts in a short time, or a GM command executed by an account that should not have that power. A simple alert that fires a warning in the staff Discord turns the LogServer from a passive file into an active sensor.

Common errors and fixes

Launch checklist

• LogServer comes up before the GameServer in the boot sequence
• LogServer port is internal and not exposed to the internet
• Asynchronous writing enabled and tested under load
• Log database separate from the production database
• Indexes by time, character and category created
• Critical categories (trade, drop, GM command) at maximum detail
• Minimum metadata present: time, account, character, IP
• NTP synchronized across all server nodes
• Layered retention policy defined and automated
• Size-based rotation configured for file logs
• Log account without update or delete permission
• Logs included in the backup routine and restoration tested
• Timeline query validated with a test trade
• Automatic anomaly alert pointed at the staff channel
• Investigation procedure documented for the GM team

With the LogServer well configured, you stop operating in the dark. Every dispute becomes a query, every fraud leaves a trace and every ban decision starts to rest on evidence, not suspicion. That is the foundation of a server players respect because they know the rules are enforced based on facts.

Frequently asked questions