How to configure anti-speed hack in MU Online

Speed hack is one of the most destructive cheats in MU Online servers because it attacks the heart of gameplay: speed. A player with a speed hack attacks two or three times faster than they should, moves as if teleporting across the map, and clears XP spots at a pace impossible for anyone playing clean. In PvP they are practically unbeatable; in farming, they break the economy. What makes it worse is that many administrators rely only on client-side protection — and that protection is exactly the part the cheater controls and modifies. The defense that really works lives on the server: measuring the interval between the actions the client sends and refusing anything that comes in above what is physically possible. This guide shows how to configure and calibrate that protection. All speed values, parameter names, and paths are examples that vary by season/emulator — you will measure your own limits.

Prerequisites

• Administrative access to the GameServer directory (e.g., C:\MuServer\GameServer\).
• Knowledge of which emulator/season the server runs (IGCN, MuEMU, X-Files, etc.).
• A well-equipped test character per class to measure real speeds.
• Access to the GameServer logs to observe violations.
• SSMS connected to the MuOnline database, in case you want to record violations and automate punishments.
• A full backup of the configuration files before editing.
• Ideally, a second administrator with high ping to test for false positives.

> Never enable automatic speed hack punishment without first running in log mode. Players with high ping, latency spikes, and packet re-delivery can trigger occasional violations. Calibrating before punishing is what keeps the protection from becoming a complaint generator.

How speed hack works (and how the defense works)

In MU Online, every player action — a strike, a step, the use of a skill — is sent from the client to the server as a packet. Between one action and the next there is a natural minimum interval, determined by the attack speed and move speed of that character. The speed hack artificially shortens that interval, making the client fire packets at a higher frequency than the game allows.

The server-side defense is conceptually simple: for each type of action, the server records the timestamp of the last packet and calculates the interval until the next one. If the interval is shorter than the minimum allowed for that class and equipment, it is a violation. An isolated violation may be lag; repeated violations in a short window are cheating. The table below summarizes the common vectors.

Step 1 — Locate the speed parameters in the GameServer

Most emulators expose speed limits in a GameServer configuration file, commonly in GameServer\Data\ or in an .ini at the GameServer root. The names vary a lot between builds, but the block usually looks like this:

[SpeedHack]
Enable                = 1
AttackSpeedCheck      = 1
MoveSpeedCheck        = 1
Tolerance             = 15      ; percentage margin to absorb lag
ViolationLimit        = 5       ; violations in the window before acting
ViolationWindowSec    = 10      ; counting window (seconds)
Punishment            = 0       ; 0=log, 1=kick, 2=temporary ban
LogEnable             = 1
LogPath               = Logs\SpeedHack\

> If your build does not have a dedicated section, look for parameters with names like CheckSpeedHack, AttackSpeedLimit, MoveSpeedLimit, or MaxAttackSpeed scattered across the configuration. The naming varies by season/emulator — consult your build's documentation or the emulator's forum.

Always start with Punishment = 0 (log only). You will enable punishment only after calibration.

Step 2 — Measure the real speeds per class

Here is the step most administrators skip and that causes most of the false positives: you need the real numbers from your server. Attack speed and move speed depend on the class, level, equipment, and season. Copying values from another server is a recipe for disaster.

For each class (DK, DW, Elf, MG, DL, etc.), do the following:

1. Create or use a test character of the class, well equipped, at the typical endgame level.
2. Note the displayed attack speed (many builds show it on the status screen or via a GM command).
3. Record in the log, with the hack turned off, the real minimum interval between strikes during intense combat.
4. Repeat with maximum attack-speed equipment (Excellent items with a speed option, swell/greater buffs).
5. Note the move speed during continuous running on the map.

Build a per-class reference table. An illustrative example (the numbers vary by season/emulator and only serve as a format):

Keep this reference. It is the basis for everything that follows.

Step 3 — Set the ceiling with a tolerance margin

With the real numbers in hand, set the server limit above the legitimate maximum, adding a margin to absorb lag and network spikes. If a class's real minimum strike interval is X ms, the server should refuse only intervals well below X — never equal to or just below it, or you will catch the legitimate player during a latency spike.

The margin applies in two combined ways:

• Percentage tolerance (Tolerance): how far below the minimum the server ignores before counting it as a violation. A generous initial margin avoids false positives while you calibrate.
• Violation count over a window (ViolationLimit / ViolationWindowSec): instead of punishing on the first anomaly, it only acts when several violations accumulate in a short period. This is what distinguishes occasional lag from a sustained hack.

[SpeedHack]
Enable             = 1
Tolerance          = 20     ; start generous, tighten after calibrating
ViolationLimit     = 6      ; 6 violations...
ViolationWindowSec = 8      ; ...in 8 seconds = sustained pattern
Punishment         = 0      ; still logging

The logic is clear: a speed hacker generates dozens of violations per second continuously. A player with bad ping generates one or two sporadically. The counting window separates the two.

Step 4 — Record violations in the database for analysis

File logs are useful, but centralizing the violations in the database makes calibration and auditing easier. Create a table and, if the emulator offers a hook, route the violations to it; otherwise, import periodically from the log.

USE MuOnline;
GO

CREATE TABLE dbo.SpeedHack_Log (
    LogID        INT IDENTITY(1,1) PRIMARY KEY,
    AccountID    VARCHAR(10)  NULL,
    CharName     VARCHAR(10)  NOT NULL,
    ViolationType VARCHAR(20) NOT NULL,   -- ATTACK, MOVE, SKILL
    MeasuredMs   INT          NULL,       -- measured interval
    AllowedMs    INT          NULL,       -- minimum allowed
    ViolCount    INT          NULL,       -- violations in the window
    ClientIP     VARCHAR(45)  NULL,
    DetectedAt   DATETIME     DEFAULT GETDATE()
);
GO

After a few days in log mode, this query reveals who the real suspects are and helps you tighten the thresholds:

SELECT CharName, ViolationType,
       COUNT(*)          AS TotalViolacoes,
       AVG(MeasuredMs)   AS MediaIntervalo,
       MIN(MeasuredMs)   AS MenorIntervalo,
       MAX(ViolCount)    AS PicoNaJanela
FROM dbo.SpeedHack_Log
WHERE DetectedAt >= DATEADD(DAY, -3, GETDATE())
GROUP BY CharName, ViolationType
HAVING COUNT(*) > 50
ORDER BY TotalViolacoes DESC;

Accounts with hundreds of violations and absurdly low intervals are hackers. Accounts with few violations and intervals close to the limit are players with a bad connection — do not punish these.

Step 5 — Enable gradual punishment

After calibration (a minimum of 48 to 72 hours in log mode), enable punishment in a staged way. Start with kick, which is reversible and educational, before moving to ban.

[SpeedHack]
Enable             = 1
Tolerance          = 12     ; tightened after calibrating
ViolationLimit     = 5
ViolationWindowSec = 8
Punishment         = 1      ; kick on violation
LogEnable          = 1

Watch for a few more days. If the kicks are catching only real hackers and there are no complaints from legitimate players, you can move up to a temporary ban for repeat offenders. Reacting to a speed hack ban is part of the same moderation discipline as any punishment — always record the reason and the evidence. If you don't have the moderation foundation set up yet, it is worth starting with the essentials in how to create a MU Online server before hardening the anti-cheat.

Step 6 — Automate bans for repeat offenders

To turn serious, repeated violations into automatic temporary bans, schedule a procedure that acts on whoever crosses a high threshold of confirmed violations:

USE MuOnline;
GO

CREATE PROCEDURE dbo.SP_SpeedHack_Enforce
AS
BEGIN
    SET NOCOUNT ON;

    -- Ban accounts with a sustained speed hack pattern in the last 2h
    UPDATE m
    SET m.bloc_code = 1
    FROM MEMB_INFO m
    INNER JOIN (
        SELECT AccountID
        FROM dbo.SpeedHack_Log
        WHERE DetectedAt >= DATEADD(HOUR, -2, GETDATE())
          AND MeasuredMs < AllowedMs * 0.5   -- half the minimum = unequivocal
        GROUP BY AccountID
        HAVING COUNT(*) > 200
    ) s ON m.memb___id = s.AccountID
    WHERE m.bloc_code = 0;

    PRINT 'SpeedHack enforce completed: ' + CAST(GETDATE() AS VARCHAR);
END;
GO

The MeasuredMs < AllowedMs * 0.5 criterion is deliberately severe: only ban automatically when the speed is clearly impossible (half the minimum interval). Borderline cases are left for human review. Schedule it in SQL Server Agent at a 30-minute interval.

Step 7 — Combine with client-side protection

The server's anti-speed hack is the final authority, but making cheating harder on the client reduces the volume of attempts. If your build supports GameGuard, HackShield, or an equivalent anti-cheat module, keep it active in parallel. It tries to block the injection and memory modification that originate the speed hack, while server-side validation ensures that whatever gets through anyway is refused. The two layers together cover both prevention and detection.

Common errors and fixes

Launch checklist

• Anti-speed hack section located in the GameServer
• Real speeds measured per class with a test character
• Attack/move speed reference table documented
• Ceiling set above the legitimate maximum, with a margin
• Tolerance and violation window configured
• Punishment = 0 (log) active for 48-72h of calibration
• SpeedHack_Log table receiving violations
• Analysis query reviewed; thresholds tightened based on the data
• Tested with a high-ping account to rule out false positives
• Staged punishment: kick before ban
• SP_SpeedHack_Enforce with a severe criterion and queue review
• Client-side protection (GameGuard/anti-cheat) active in parallel
• Backup of the config files made before editing

Well-done anti-speed hack is not about finding the magic number — it is about measuring, calibrating, and scaling carefully. By validating speed on the server, measuring your build's real limits, absorbing lag with tolerance and a window, and only hardening the punishment after seeing the data, you eliminate the cheaters who break PvP and the economy without turning every high-ping player into a suspect. That discipline is what keeps the competition fair and the server trustworthy.

Frequently asked questions