Simulator Controller ships an .exe that your antivirus is expected to flag

The automation technique is the reason antivirus complains

The documentation addresses this before anything else, and the honesty is worth repeating. The programming language used to build Simulator Controller uses tricks to control Windows applications that malware also uses, so depending on your antivirus you may get warnings about the Simulator Controller applications. The author's answer is that there is nothing to it, and a pointer to the AutoHotkey forums where the same reports appear.

The advice that follows is practical. If your antivirus allows exception rules, define them for the Simulator Controller directories, meaning both the install directory and the one in your user Documents folder. If it does not, the documentation tells you to search for another tool.

That is the real adoption barrier. Not the feature list. A tool that requires you to disable or carve out protection on the machine you race on is a decision about your security posture before it is a decision about software.

Four assistants, and the first one avoids the pit box

The voice assistants are the part that distinguishes this from a button box configurator. Four are described.

The AI Race Engineer is the pit crew: it prepares a pitstop, watches the weather forecast, calculates damage impact on lap times, and handles the tedious work so your hands stay on the wheel. The AI Race Strategist watches overall race situation and develops or adapts strategy depending on race position, traffic and weather changes. The AI Race Spotter watches for critical situations with nearby cars. The AI Driving Coach covers car handling, answers questions about racing in the real world or in a simulation, and gives instructions while you are on the track.

Read together, that is a division of labour matching a real race team, and the intent is that only the coaching voice needs to interrupt you during a stint. Whether an assistant can decide a pit window without taking your attention off a corner is the question the documentation does not answer.

Automation underneath, controllers on top

The base layer is described as a plugin capable automation framework that can use almost any external controller hardware, such as button boxes, to control typical simulator components such as SimHub and SimFeedback and alike. Two separate layers, then: something that speaks to hardware, and something that speaks to your simulator software.

The repository layout matches that split. `Config/`, `Profiles/` and `Resources/` are the user-facing state, `Sources/` holds the code, and `Utilities/` and `Docs/` sit alongside a `VERSION` file and a `Documentation.url` pointer. The primary language is AutoHotkey, which is the reason for the antivirus behaviour in the previous section.

Profile-driven configuration is what makes the tool reusable across cars and sims, and it is also where the churn shows up in the release notes, which are full of car models, car databases and setup-rule fixes rather than new architecture.

Download choices multiply the install decision

There are separate download links for the current development build and at least the two latest stable releases, and each of those can be unzipped anywhere on your hard disks. Starting with Release 3.5.2 you then run the Simulator Tools application in the Binaries folder, which walks through the rest of installation.

The automated installer is a separate path. It downloads Simulator Controller.exe from an S3 bucket in eu-central-1, connects to the version repository, and downloads and installs the latest version, with a note that you may have to deactivate your antivirus or browser download protection to do it. Older builds are downloaded manually after consulting the documentation.

So a first-time user has three routes of increasing manualness and decreasing trust requirement, and the project recommends the automated one first while acknowledging the antivirus problem immediately. The manual route is the only one that does not ask you to run an unsigned binary before you have an exclusion rule for the program.

Changelog entries read as a maintenance log of small breakage

The change lists are the most informative part of the documentation, because they show what actually breaks. The 7.2.6.0 release fixes standings and gap calculation for iRacing, has a potential fix for team session handover for LMU, optimizes telemetry startup in Solo Center, adds caching for the track spline in ACC, and adds wildcard matching for setup settings in car rules.

The 7.2.5.0 list is almost entirely corrections: fixed Driving Coach reference lap saving, updated the R3E car database, fixed wrong car names for ACE, showed more undriven cars in Setup Workbench, fixed overlong car names for ACE, fixed RawHandler in Setup Workbench, fixed the telemetry list update for Setup Engineer, and added a max increment setting for setup changes.

The 7.2.4.0 list adds support for multiple unit sets and fixes premature end of LMU sessions, strategy for restricted tyres and retricted laps, spring rate for the ACE BMW M4, and several other ACE cars. A project that lists fixed spring rate for one car model and car names for another in consecutive releases is a project whose users track updates closely rather than setting and forgetting.

The beta build is hosted somewhere unusual

Stable downloads are behind shortened links, while the development build, 7.2.7.0-beta, sits on a file browser API at fileshare.impresion3d.pro, served as an inline download. That is a personal file host rather than a release asset, and it is where a test build lives while the stable builds use cutt.ly links.

The stated changes in the beta are improved memory cleanup for the Driving Coach, new car models for Setup Workbench, a fixed refuel calculation for LMP2 for Chinese LMU, and improved reliability of updated ACE setup files. Nothing about that list says unstable, which is a sign of how the project uses its beta channel: bug fixes against current sim content rather than experimental features.

A maintainer publishing a 3D printing company's file host is not automatically a risk, but it is a different durability and provenance story from a signed release asset, and it is the kind of detail worth checking before you run it.

Multiplayer endurance is the Patreon benefit

Funding is handled with a PayPal donation button and a Patreon page, and the stated use of donations is to support further development of the project. That framing is ordinary and unremarkable.

The Patreon benefit is not ordinary. As a benefit of supporting the project, you might get access to a public Team Server for multiplayer endurance races. In other words, the only feature described as gated behind payment is a shared server for team racing, and the word used for it is might.

If you race endurance online with friends, that server is arguably the most valuable thing in the project and the only one tied to paying. If you race alone, nothing described here is behind the donation.

Editorial conclusion

Simulator Controller earns its place for a sim racer who already owns button box hardware and wants a second screen's worth of tooling around it, and for anyone who can afford to configure antivirus exclusions on a gaming PC. It is the wrong choice on a locked-down corporate machine, where an unsigned automation binary that hooks other applications will never be permitted, and it is a poor fit for flight or game simulation, where the tool's feature list is all racing. First check: read the Update Notes for every version you skipped, since the project states those matter as much as the release notes and describes each build as fixed in one car and broken in another.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. SeriousOldMan/Simulator-Controller on GitHub