How this was built

Who made it

RigReady is a side project by Mark Cheli, a software engineer by profession for more than ten years, built for his own flight and racing rig and shared because other people have the same problem.

The code, the tests, the manual and this website were written by AI coding agents (Anthropic's Claude, in Claude Code), working from his direction. Mark decided what the product is and what it must and must not do (written down in docs/PRODUCT.md), set the safety rules, reviewed the results and the screenshots, tested it on his own PC, and decides what is released. He did not write the code by hand, and not every line has been read by a person.

How the work was checked

Care went into how the work was checked, because a computer full of games, settings and hardware is not a place to be careless. The methods:

• Every feature is a written requirement with its acceptance criteria, in the requirements ledger. It counts as done only with a test of the real code and, for anything on screen, a screenshot from a test run. 394 of 412 are done today.
• About 1,800 unit tests, and about 240 scenario tests that start the real app on a recorded copy of a rig with something changed ("pedals unplugged", "a screen rotated") and use it as a person would. Both run on a clean Windows machine in GitHub Actions for every change.
• Safety rules the tests enforce across the whole code: any file outside RigReady's own folder is backed up before it is changed and the change can be undone; programs are never started from a command line built out of text; no message may claim success for something that did not happen.
• A security review of the whole app, with what was found fixed and tested, and a security page that says what it touches.

None of this makes it free of mistakes. It is how they are kept small and found early.

What it was tested on

One rig: a Samsung 49-inch ultrawide, three small USB screens used for aircraft displays, a Dell desk monitor, WinWing devices (joystick, throttle, three display frames, UFC, ICP and cockpit panels), Thrustmaster TPR pedals, a Virpil control panel, a Stream Deck, TrackIR 5 and a Fanatec Podium DD2 wheel base, with DCS World, iRacing, Le Mans Ultimate, BeamNG.drive, Microsoft Flight Simulator 2024 and the Assetto Corsa games installed.

On that PC, tests read the real devices, monitors, audio and controllers, and changed and restored the real monitor layout and audio devices. Changes to game files (bindings, the DCS screen setup, backups and restores, the iRacing repair) were tested on copies of that rig's files, not the live ones.

It has been used on one rig, so reports from other hardware help most, through the hardware report form.

Not verified yet

These requirements are still open:

• A monitor switched on with no refresh rate asked is left at the rate Windows chooses (DISP-019, in progress)
• The user chooses where DCS shows the kneeboard (DCS-MON-010, to do)
• Write .diff.lua files DCS accepts (BIND-DCS-008, in progress)
• The overlay window is over the game and out of its way (OVERLAY-002, in progress)
• Placing the overlay: which screen, and where on it (OVERLAY-005, in progress)
• The overlay takes more widgets, each with its own place and options (OVERLAY-006, in progress)
• The overlay inside a VR headset (OVERLAY-007, to do)
• iRacing device-ID repair where the format allows (RACE-IRACING-005, to do)
• Bindings of a car with custom controls, and what the car changes (BIND-IRACING-003, in progress)
• Change an iRacing binding from RigReady (BIND-IRACING-007, in progress)
• Bind an axis or a hat switch for iRacing from RigReady (BIND-IRACING-008, to do)
• Each brand verified on a real wheel (RACE-WHEEL-004, to do)
• Assetto Corsa controller repair (controllers in another order, or with a new Windows id) (RACE-AC-001, to do)
• The virtual controller on the real driver and in a real game (VPAD-005, in progress)
• Configure MFD screens without SimAppPro (SAP-001, to do)
• Research driving WinWing displays and backlights directly (SAP-005, in progress)
• Signed releases through Azure Artifact Signing (PLAT-017, in progress)
• With one game on the list, the Bindings picker still names it (NAV-GAMES-005, in progress)

The binding guides were written from general knowledge of the aircraft and have not been reviewed by a pilot. The changelog lists the known limitations of the current version.

Contributing

Pull requests go through the same tests, and Mark reads each one before it is merged. Contributions written with an AI tool are welcome if they say so. The contributing guide has the details.