Client files
The client carries the visible world: UI, maps, models, tables, language files, local resources, and the actual game executable.
Client and server research
How The Gate of the World fits together.
AegisRO2 Remake is not being rebuilt from vibes alone. The current research combines public Saga and Saga Revised source, public tooling repositories, archived setup notes, local static inspection, and the map editor workbench into one practical model of the old client/server stack.
Research boundary
Public evidence, preservation notes, and careful inference.
This page documents what the public material supports. It does not publish leaked official server archives, private forum attachments, bypass steps, account systems, or runnable private-service instructions. When a detail is inferred from multiple sources, it is labeled as a working model rather than an official Gravity specification.
Gateway protocol
The first network gate handles key exchange, packet framing, version proof, authentication handoff, and map session handoff.
Server data
Saga-style emulators need matching accounts, world proof, scripts, maps, NPC data, mob data, items, skills, and database rows.
Client side
The old client is two major programs plus a large local data world.
The most important client-side split is simple: `Ragnarok2.exe` behaves like the launcher and patcher layer, while `System\RagII.exe` is the actual game executable used by public Saga-style launch instructions and old private-server launchers.
`Ragnarok2.exe` prepares the installation.
Static inspection of preserved kRO2 material found patch/version strings, `PATCHW32.dll`, official launch URL text, and a `Rag2Patch` debug path. Public patcher notes describe update metadata, server/version fields, patch file lists, and helper DLLs.
- Reads or presents patch/update state.
- Works with `patchw.dll` and `patchw32.dll` style helper files.
- Can show notices and prepare the game folder before launch.
- Private-server guides often replaced or renamed patcher binaries to redirect this layer.
`System\RagII.exe` is the executable that enters the game.
Public Saga Revised documentation and archived setup posts agree on the same direct-launch pattern: start `RagII.exe` with a target gateway IP or hostname and a port. The common Saga Revised example uses port `64000`, while older Saga and private-server examples vary.
"System\RagII.exe" ServerIP=127.0.0.1 ServerPort=64000
That command is a compatibility clue, not a guarantee. The server branch, client build, local data, version proof, and database must still match.
| Client artifact | Why it matters | Preservation note |
|---|---|---|
| `System\RagII.exe` | Game executable and protocol participant. | Hash first, do not run directly from the archive. |
| `Ragnarok2.exe` | Patcher/launcher layer. | Compare patch strings and helper DLL expectations. |
| `patchw.dll` / `patchw32.dll` | Patch helper files referenced by public setup notes. | Keep with the matching launcher. |
| `RagII.cni` / `User.cni` | Configuration-like client files worth comparing between builds. | Record before editing. |
| VDK archives | Container format for game data in later RO2 tool research. | Use extractor/tooling on copies. |
| CT tables | Binary game-data tables convertible to CSV/XLSX by public tooling. | Useful for item, NPC, map, and table comparisons. |
| NIF models | Gamebryo model files with NiMesh/NiDataStream geometry. | Useful for map editor rendering and mesh repair. |
Client data layer
The visible game mostly lives in local client data.
The server sends state and game events, but the local client determines the visual era: login screen, UI skin, language, maps, models, textures, tables, music, and resource layout. This is why an older client hunt matters. A different client can mean different maps, UI, dialogue text, models, and atmosphere even before the server sends much data.
Archive containers
Public RO2 Toolkit notes describe VDK archives as VDISK 1.0/1.1 containers with hierarchical storage, zlib/Deflate compression, and EUC-KR filename encoding.
Binary tables
Public tooling describes CT as RO2 table data with multiple scalar types, UTF-16LE strings, and CRC-16 XMODEM checks. Converting these to CSV/XLSX makes data comparisons practical.
Model data
The engine-file research identifies RO2 model files as Gamebryo/NIF version 20.6.0.0 with NiMesh, NiDataStream, and index streams.
Client-facing language
Language, dialogue, labels, and table text must be compared by client build. An English patch can make the same executable/data era behave differently on the surface.
Protocol model
The gateway is where compatibility usually succeeds or fails first.
Public Saga and Python experiment sources are not a complete official protocol specification, but they agree on the shape of the early session: connect, exchange keys, frame packets, identify the client/session, authenticate, then hand the player toward the map service.
- 01Direct launch
`RagII.exe` starts with a gateway target supplied by arguments or a launcher.
- 02Initial connection
The client reaches the gateway/listening service on the configured port.
- 03Static-to-negotiated key state
Public Saga code initializes keys from a static state, then sends a generated server key and stores the client key.
- 04Packet framing
Public Saga code reads the first two bytes as packet size. Non-gateway dispatch derives message ID from later header bytes.
- 05Version proof
Older SagaRO2 gateway code asks for GUID/CRC-like proof and compares it against allowed client keys.
- 06Authentication
The authentication side validates the account/session. Account creation and password handling vary by branch.
- 07Map handoff
The gateway identifies the session to the map service. The map service creates or loads the player actor and sends start/map-position data.
Known public Saga client-version keys
These values appear in public Saga/SagaRO2 configuration and forum material as gateway compatibility keys. They are not SHA-1 hashes of the full executable.
| Client label | Gateway key |
|---|---|
| kRO2 v66 | BE6ED3C5F923072EA91C43EB2F02B2BEE16D3BF1 |
| kRO2 v68 | FA0AE6C542F8A30311B2860CEC255B2B99D2CB53 |
| kRO2 v73 | 2B9F3A4C0A2537DDAC200624A9EDE50C12B75F17 |
| kRO2 v77 | 84AC9C76A35EA122640021260EA7B9D4F392D190 |
| kRO2 v81 | EDD187AE35CD507C041323B0397F1F22C4F3F640 |
| kRO2 v101 | D718E51F41AB15491D63C5688B5B07EBDBE93371 |
Server side
The best public model is a service stack, not one server binary.
The public Saga/Saga Revised family splits the server into specialized services. A playable world depends on those services plus matching database rows, script files, map data, client-version handling, and client-side resources.
Saga.Authentication
Account creation, login identity, password handling, and account/session state.
Saga.Gateway
Client-facing entry point, key exchange, version proof, session routing, and world handoff.
Saga.Map
World simulation, actor creation, movement, map entry, NPC visibility, mobs, skills, and gameplay state.
Saga.Scripting
Lua/script integration for NPCs, quests, scenario logic, and content behavior.
Database + XML
MySQL world/account data, XML game data, item tables, skill data, mob data, portals, and spawn templates.
Definitions/network core
Packet definitions, shared types, encryption helpers, and common runtime infrastructure.
| Server artifact | Observed role in public Saga-style trees | Restoration value |
|---|---|---|
| `MapInfo.xml` | Map identifiers and map metadata. | Connects client-visible maps to server-side map IDs. |
| `MobDB.xml` | Mob definitions and server-side monster data. | Lets the editor compare visible mob placements with expected server actors. |
| `spawntemplates.xml` | Spawn templates and population data. | Helps reconstruct where mobs appear and how repeated spawns are grouped. |
| `portalDB.xml` | Portal and transition data. | Useful for rebuilding island, harbor, and route connectivity. |
| `itemDB.xml` / `weaponInfo.xml` | Item and weapon definitions. | Needed for inventory, equipment, rewards, drops, and visible gear behavior. |
| `skillDB.xml` | Skill definitions. | Needed before combat, class behavior, or NPC/quest skill checks can be trusted. |
| `exp.xml` | Experience/progression data. | Preserves early balance assumptions, even when formulas remain incomplete. |
| `SagaScripts` / `scripts` | NPC, quest, scenario, and Lua/script content. | Often the missing piece when the world loads but feels empty. |
`list_worlds` must match `Saga.Map.config`.
Saga Revised setup notes use a generated `proof` value from `Saga.Map.config`. That proof is inserted into the MySQL `list_worlds` table beside the world name and ID. If the map service is running but this row is missing or wrong, world selection or handoff can fail.
list_worlds: Id, Name, Proof
Starting services is only the first gate.
Public setup notes repeatedly show that a stack can compile and listen while gameplay still breaks. Missing scripts can produce missing NPCs. Wrong account creation can look like a login failure. Wrong proof can break world listing. Wrong client version can fail before character selection.
- MySQL schema and world rows.
- Map, gateway, and authentication configs.
- Lua/NPC/scenario script folders.
- XML game data such as mobs, items, skills, portals, spawns, maps, and EXP.
Compatibility diagnosis
A client can fail at many different layers.
The restoration workflow treats each failure as a clue. "It does not work" is not one problem; it can mean patcher failure, file layout mismatch, gateway rejection, account format mismatch, map handoff failure, missing scripts, or client data from the wrong era.
| Symptom | Most likely layer | What it tells the remake |
|---|---|---|
| Patcher cannot update | Launcher/patch metadata | Preserve the archive and inspect the game binary directly on a copy. |
| Game cannot find files | Client folder layout | Expected `System` and data paths differ from the installed archive. |
| Gateway disconnects early | Version proof or key exchange | The client build may not match the server branch's allowed keys. |
| Login rejects account | Authentication database | Wrong account creation method, password hash, or auth service config. |
| World list missing | `list_worlds` / proof | Gateway/auth and map service do not agree on the registered world. |
| Character enters but map breaks | Gateway-to-map handoff | Session IDs, map IDs, or starting coordinates need tracing. |
| NPCs/mobs missing | Scripts and world data | Server DB/scripts may not match the client-visible map. |
| UI/maps look wrong | Client data era | The client archive may be newer, older, translated, or private-server modified. |
AegisRO2 Remake workflow
The editor turns research into a rebuildable world.
The practical path is not to guess. Each recovered client or server note gets reduced into evidence: hashes, version clues, resource formats, maps, actor data, scripts, NPCs, mobs, portals, and observed failure points. The editor then makes those invisible relationships visible.
Preserve
Keep original archives untouched, record source pages, hash files, and work only on copies.
Extract
Use VDK/CT/NIF tooling to list archives, convert tables, inspect models, and compare client eras.
Map
Render terrain, water, meshes, labels, placement boxes, and server-like actor data in the OpenGL preview.
Pair
Match a client build to a Saga/Saga Revised branch, allowed gateway key, database, scripts, and map content.
Restore
Start with a small route: login, character load, one map, visible NPCs, basic mobs, and stable movement.
Public sources used
Open-source and archived evidence, not private dumps.
This page is based on the local research dossier built from public repositories, archived public pages, and static inspection notes. The source list below gives the public anchors without linking to private or restricted files.