Architecture

WildM is split into six programs. Only two of them run inside or next to the game; the game itself is never modified.

#	From → to	What travels	Reference
1	Launcher → master	GET /version, /servers, /stats; account linking POST /auth/link/start, GET /auth/link/poll; GET /auth/me, POST /auth/logout	Master API
2	Browser → master / Portal	The /link?code=… sign-in page (approves the launcher's code); the /portal web app for server owners	Linking, Portal
3	Launcher → game server (HTTP)	GET /info, GET /resources/manifest, GET /resources/file/<path> — up to 4 parallel downloads, sha256-checked	Game server protocol
4	Launcher → injector	wildm_inject.exe --url <uplay:// or steam://> <client\dinput8.dll>; reads one OK … / ERR … line	Injector CLI
5	Injector → platform → game	The injector opens the platform URL; Ubisoft Connect / Steam checks the licence and starts GRW.exe	Principles
6	Injector → GRW.exe	LoadLibraryW(client\dinput8.dll) via a remote thread as soon as GRW.exe appears (handles a relaunch by Ubisoft Connect)	Injector CLI
7	Launcher ↔ client folder	Writes wildm_connect.json (new session per launch), deletes the old wildm_status.json, then polls the new one every 500 ms	Contract
8	Client ↔ client folder	wildm_net reads wildm_connect.json next to the framework DLL and writes wildm_status.json about once a second (atomic replace)	Contract
9	Client ↔ game server (TCP)	One JSON object per line: hello → welcome, pos at 10 Hz → players at 10 Hz	Game server protocol
10	Game server → master	POST /heartbeat every 30 s with the server's sv_key; the master drops a server after 90 s without a heartbeat	Heartbeat & listing

The components

Component	Source folder	Language	Role
Launcher	launcher/	Electron (Node.js)	Splash with boot checks, WFX.re account linking, server browser, connect sequence, installs the client into %USERPROFILE%\WildM\client\
Injector	injector/wildm_inject.c	C (Win32)	Loads the client DLL into GRW.exe without touching game files
Client framework	forks/gamexueren/ (advanced fork, being ported) and grw-scripthook/ (original, patched)	C / C++ (ImGui overlay)	dinput8.dll proxy: plugin loader, game API (SH_API exports), in-game menu
Client plugins	forks/gamexueren/plugins/wildm_net, skipintro, test_plugin	C	Network client + status file; intro video skip; local debug console
Game server	game-server/	Node.js, no dependencies	HTTP info/resources, TCP player sync, heartbeat
Master server + Portal	master-server/	Node.js, no dependencies	Server list, stats, WFX.re accounts, launcher linking, Portal and sv_keys, icons/banners, wfx.re landing page

The connect sequence, step by step

The launcher's connect screen shows five steps (ids in the code: server, resources, checks, launch, world). Each can be cancelled at any time. Details from a player's perspective are on The loading screen.

1. Connecting to the server — GET http://<host>:<port>/info (6 s timeout). The answer must contain an integer gamePort.
2. Downloading resources — fetch the manifest, check the cache (size + sha256), delete files no longer in the manifest, download the rest (4 in parallel, 20 s stall timeout, .wildm-part temp files renamed after verification). If the cache contains loadscreen/index.html, it is displayed behind the progress UI.
3. Checks — find the game, scan for anti-cheat, make sure GRW.exe is not already running, clean up any legacy files in the game folder, install or update the client if the build changed.
4. Launching the game — make sure Steam (Steam version) and Ubisoft Connect are running, write wildm_connect.json, run the injector (4 min timeout).
5. Loading the world — follow wildm_status.json until phase is ingame and server.connected is true. The launcher window then minimises itself.