Developers

How a game client talks to Voidwatch, and how to build your own module or support a new server.

The parts

Part	Runs where	What it does
module	inside the game client	writes the character state to files, runs commands
upload script	next to the client	sends the files to the API, writes the replies back
feed API	on our servers	stores the state, answers with the capture rate and waiting commands

The client makes no web requests itself. Many clients leak memory on every request, so the script does the network part.

One loop

The module writes outbox/status.json: every 2 seconds while someone watches the character, every 30 seconds otherwise.
The script sends it to POST /api/v1/status and writes the reply to inbox/reply.json.
The reply says how often to send a screenshot. Every 1–2 seconds while someone watches the character, once a minute otherwise.
If commands wait, the script fetches them into inbox/commands.json. The module runs them and writes outbox/results.json.
Between two statuses the script keeps one request open to GET /api/v1/wait. It returns the moment someone opens the character, an alert fires or a command is sent, so the client speeds up within a second.
Once a minute the script looks at the client's minimap<version>.otmm and sends it when it changed. The player's own map on the website then updates by itself. Players can turn this off in the module settings.

Pairing

A new client has no token. The module writes outbox/pair-request.json, and the script calls POST /api/v1/pair. The reply holds a code and a link for the player, and the token the script keeps.

Build your own

Everything is open: the feed API, the status payload and the reference module, MIT-licensed. Keep the file layout and a module works with our upload scripts, or write your own sender in any language.

A server can also ship the module in its own client. Contact us and we list the server as a partner.