One signal that everybody knows
The brief for STINTDECK names six people who look at a screen: the driver in the rig, the visitor with a phone, the visitor at a kiosk, the crowd in front of a television, the staff member next to the simulator and the organiser at a desk. Each of them needs one thing at a glance.
The product answers with a single signal, the row of five start lights. Lights building up mean that something is being prepared. All five mean ready, wait. Lights out mean go. The driver sees it on the simulator, the visitor on the ticket, where the lights fill up as the queue shrinks. Nobody has to learn it.
Around that signal sit a few fixed rules. A colour has exactly one meaning everywhere. Numbers that run are set in fixed slots so that they do not jitter. The organiser’s accent colour is identity and never carries a state. The same design is drawn three times with the same measures: in CSS for the web app, in Lua inside the game and in WPF for the desktop window of the simulator PC.
The game is controlled, not operated
A program on the simulator PC, the station agent, carries out each session. It writes the configuration for car, track and driving aids, starts the game without anyone touching its launcher and waits until the game confirms that the right content is loaded. The car is held at a gate until staff release the driver, and the start is confirmed by the game itself.
The game is reached from the inside. A small Lua app runs in Assetto Corsa through Custom Shaders Patch and handles release, start, recovery and the facts of each lap. Injecting keystrokes or moving the mouse was ruled out as a matter of principle, and so was a demo mode that produces sessions without a real simulator.
The session clock is a fixed deadline on the PC’s monotonic clock. Resetting a stuck car does not touch it, and neither does a change of the wall clock. In real runs, sessions of 120 and 110 seconds ended within a tenth of a second of their deadline. The next driver was ready 0.4 seconds after being called, because the game keeps running between drivers.
A lap has to earn its place
The fastest time a game reports is not a result. STINTDECK reads laps through two sources and gives each one of three verdicts: valid, invalid or unverified. An invalid lap carries its reason, for example track limits, a car reset, a lap driven by the game’s AI, a pause or a lap that began before the release. A lap whose validity cannot be established stays unverified and is never ranked.
The same thinking decides what a leaderboard is. It belongs to a competition, which is defined by what makes times comparable: car, track, driving aids and conditions. Stations with the same configuration share a board. Change the configuration and a new board begins.
This rule was observed with the real game in one direction only. Laps driven by the game’s AI were rejected as invalid with their reasons. A clean lap by a person could not be driven on the development PC, which had no wheel.
The simulator PC decides, the server remembers
One architecture decision carries the rest. The agent is the authority for what happens on the simulator, and the backend is the authority for people and order. A session therefore survives a lost connection. The agent keeps its state in a local database and sends results from an outbox until the server has confirmed them, and the server accepts each message only once.
Agents connect outwards, so a simulator PC needs no open inbound port. A simulator PC is paired with a one-time code and creates its own secret, which can be revoked from the web app. Commands are typed and bound to a station, a run and an expiry, so a second tap on start or a command meant for the previous driver has no effect.
These paths are covered by tests with a scripted simulator. A real network failure during a real session has not been staged yet.
Data that belongs to someone
Several organisations use the same platform. Their separation is enforced by the database with row level security, so a missing filter in application code cannot expose another organisation’s rows. Kiosk tablets and leaderboard displays do not get accounts. They get links that open exactly one screen and can be revoked.
For participants the platform stores what was agreed to with its exact wording, keeps marketing consent separate and optional, deletes personal data after a period the organiser sets and records exports and deletions in a log that can only be appended to. The texts themselves have to come from the organiser and a lawyer.
What is verified, and what is not
The project keeps a feature matrix with one honest column: the highest level of verification each feature has reached. This page follows it.
Observed with the real game on the development PC were pairing, configuration from the PC’s own list of 220 cars and 65 track layouts, start without the launcher, the release gate, the start sequence, the session timer, car recovery, results and the next driver. The platform has been running on its server since 13 October 2026.
Not observed yet are a valid lap by a person at a wheel, the display in full screen on a rig, triple screens and virtual reality. The platform has not been used at an event. Using the game at public or commercial events also needs the permission of its rights holders, which the project’s notes list as open.
What this demonstrates for client work
STINTDECK shows CIDIX building a product across three very different environments at once: a multi-tenant web platform with realtime, a Windows desktop program that installs and updates itself, and code that runs inside someone else’s software. The parts share one set of rules and one wire format, with test fixtures that both the C# and the TypeScript side have to pass.
The approach transfers to any system where devices in the field do the work and a platform coordinates people around them, for example machines on a shop floor, terminals at a venue or test benches in a lab. The questions are the same. Who is the authority when the connection drops, what counts as a valid result, and what has really been verified?