Game Data Sync

The GameServer ships most gameplay-critical config to the client at login instead of relying on client-side data files. This is why editing a single XML or .txt on the server changes behavior for every player without patching the client.

Understanding what gets synced, when it syncs, and what does not sync is essential for predicting whether your edit takes effect immediately, on next login, after a GameServer restart, or after a full patch.

What Gets Synced#

At login, the server sends the following data blocks to the client. All blocks travel over opcode 0xEC and each block's payload is zlib-compressed and then split into fixed-size chunks for delivery:

The data sync protocol is currently version 47 (block types 0 to 41). The GameServer and client must be built for the same version, so always update both together.

A separate timing-configuration packet is pushed alongside these blocks: attack-speed formula parameters, MuHelper minimum level, the CS-skills-in-all-maps flag, and KeepSkillBelowLearnReq (whether the client greys out learned skills whose stat requirements are no longer met) - all from Common.dat.

Blocks are delivered over the normal game connection immediately after login. The client caches them for the session.

Transport#

Each block moves in three phases:

1. Header announces the block type, uncompressed size, compressed size, record count, and a protocol version byte.
2. Chunks carry the compressed payload. Each chunk carries an index and total-chunk count so the client can reassemble in order. A chunk holds under 8 KB of payload.
3. Completion notifies the client the block finished, with a success flag and the total record count for validation.

The server caches both the raw-serialized and compressed form of each block at startup, so every player's login shares the same pre-built buffers. An empty block (0 records) is still announced so the client knows the data type was processed.

What Does Not Get Synced#

Anything that is server-authoritative combat or logic does not sync - the server handles it internally and the client only receives the outcomes.

Examples:

• All damage math (Character.dat, Skill.dat, SkillDamage.txt)
• Monster stats and AI (Monster.xml, MonsterAI* files). Only the MoveSpeed column of Monster.xml is synced (see the table above); HP, damage, defense and the rest stay on the server
• Drop rates, event schedules, map properties (MapManager.xml, Event.dat, Event/*). MapManager.xml map display names are the one synced part
• Account and character persistence (handled by DataServer)
• Chat, trade, PK rules

Changing any of these files takes effect for all players once the GameServer reloads it (the matching /reload command, see below) or restarts. No client action needed.

Effect Timing for Admin Edits#

When you edit a server config, the time-to-effect depends on which bucket the file falls into:

The "synced file" row is the one that surprises admins. Edit Skill.txt, restart the GameServer, and existing players keep the old skill data until they reconnect. New players get the new data immediately.

Reloading synced data without a restart#

The GameServer builds the sync blocks once at startup. A normal /reload updates what the server uses, but most /reload commands do not rebuild the sync blocks, so players logging in afterwards still get the old client data. These reloads do rebuild their own block:

So for any other synced file: run its own /reload first (for example /reload skill), then /reload plugins to rebuild the sync blocks. In every case, players already online keep the old data until they relog.

Diagnosing Sync Issues#

GameDataSync runs transparently over the normal game connection. Admins do not configure it. When a sync misbehaves, check the GameServer log for [GameDataSync] entries - the loader emits per-block success/failure lines there.

Common Issues#

• Edit to Skill.txt works for new logins but not existing players - expected. Synced files require relog for already-connected clients
• Client says "item not found" for a newly added entry - the sync block for that category failed to load before the player entered the world. Check GameServer log
• Custom visual shows for one player but not another - one logged in before the sync block was ready; they need to relog
• Edit to server-authoritative file (e.g. Monster.xml HP or damage) not visible to players - these values never sync to the client; the change does apply server-side (damage, HP, behavior). The client renders based on its local assets, so visible differences need a client patch. Monster.xml MoveSpeed is the exception: it is synced, so after /reload monster players see the new walk speed once they relog

Cross-File Dependencies#

Every page documenting a synced config file links back here to explain the relog semantic. If a page mentions "sync at login", this is the mechanism.

Related:

• ServerList.xml and ConnectServer.ini handle the pre-login routing that delivers the player to the GameServer that then runs this sync.
• Common.dat holds server-authoritative gameplay globals that are applied server-side instead of shipped in this sync.
• MonsterSetBase drives monster spawn positions that feed the minimap-NPC block.