rFactor 2 configuration

rFactor 2 ships with two separate Steam apps that PitwallOS uses in tandem: the rFactor 2 client (App ID 365960) and the rFactor 2 Dedicated Server (App ID 400300). Both must be installed on every rig because PitwallOS solo launches use a localhost dedicated server to bypass rF2’s lobby UI. As of agent v3.3.0 only the client is installed by the operator — the agent installs the dedicated server for you.

Required Steam apps

• rFactor 2— the client. Install through the regular Steam client; lands under steamapps/common/rFactor 2. This is the only rF2 install the operator does by hand.
• rFactor 2 Dedicated Server— installed automatically by the PitwallOS agent (v3.3.0+) into %LOCALAPPDATA%\PitwallOS\agent\rf2_dedicated\ using a self-managed copy of SteamCMD. No operator action is required; you do not need to know or use SteamCMD.

Automatic dedi install

On the first heartbeat after rF2 is enabled for a venue, the agent will:

1. Download SteamCMD from media.steampowered.com into %LOCALAPPDATA%\PitwallOS\agent\tools\steamcmd\.
2. Run steamcmd.exe +login anonymous +force_install_dir ... +app_update 400300 validate +quit to fetch the rF2 Dedicated Server (~2 GB, typically 3-10 minutes on a reasonable connection).
3. Seed UserData/Multiplayer.jsonwith a unique random admin password (stored under the agent’s config store), the WebUI port (5397), and a server name of PitwallOS-<rig name>.
4. Flip health_detail.dedi_install.phase to installed in the heartbeat. The setup GUI and the super-admin dashboard show the same state.

If the install fails (no internet, Valve rate-limited the anonymous login, antivirus quarantined steamcmd.exe, disk full, …) the agent retries automatically with exponential backoff (5 min, 30 min, 2 hr) and surfaces the SteamCMD error verbatim in the dashboard so ops can intervene. Super-admins can also force a retry from the agent-compliance dashboard.

The agent reserves %LOCALAPPDATA%\PitwallOS\agent\ rf2_dedicated\ for its own use. Other dedicated-server installs (e.g. a Studio-397 install you did by hand under C:\Racing\rFactor2-Dedicated) are still recognised — the agent prefers its own managed install if both exist.

rF2 shared-memory plugin

The agent reads telemetry from rF2’s shared-memory map, which is exposed by a 64-bit plugin DLL. PitwallOS vendors the upstream rF2 Shared Memory Map Plugin (v3.7.15.1, GPL-3.0) verbatim. On every heartbeat the agent deploys rFactor2SharedMemoryMapPlugin64.dll into <rF2 install>/Bin64/Plugins/if it’s missing or older than the bundled version — no manual copy step is needed.

If a rig already has the same DLL from CrewChief, SimHub, or similar tools, the heartbeat copy is a no-op — everyone in the ecosystem coordinates on this exact filename.

rF2 requires every plugin be opted-in via UserData/player/CustomPluginVariables.json. The agent edits this file atomically on every session start to set Enabled=1 for rFactor2SharedMemoryMapPlugin64. Hand-edits will be overwritten on the next launch.

Content layout

rF2 keeps cars and tracks under Installed/Vehicles/<car>/<version>/ and Installed/Locations/<track>/<version>/. The agent scans both directories on every content-sync and normalises the latest version per folder. Folder names are the canonical engine identifiers — they map directly to engine_folder_name in the PitwallOS database.

The .rfmod cache

rF2 hosts multiplayer races against an .rfmod package that bundles a car whitelist + track whitelist + a manifest. PitwallOS does not require operators to manage .rfmods by hand; the agent generates them on demand via the bundled ModMgr.exe and caches them by a content fingerprint computed from (sorted car folder names, track folder name, content versions). Cache rows live in rf2_rfmods; each row references a .rfmodfile under the dedicated server’s Packages/ directory.

When an operator changes the cars or track for a booking, the fingerprint changes and the next launch builds a fresh .rfmod. The operator never has to think about this. The build takes ~5 to ~30 seconds depending on car count and is run on the host rig before the session starts.

Track limits (cut-points)

rF2 uses a cut-points-based track-limits system instead of AC’s “tyres outside” rule. Each cut accumulates a point count; thresholds trigger a warning, then a drive- through penalty, then a disqualification. Defaults are set on the preset and can be overridden per booking:

• max_cut_points— ceiling on accumulated points (default 10).
• cut_warning_threshold— chat-warning fires (default 3).
• cut_drive_through_threshold— drive-through penalty (default 7).
• cut_dsq_threshold— disqualification (default 10).

Weather files

Unlike AC’s global weather enum, rF2 stores weather as per-track .WET files alongside the track’s .gdb. The agent surfaces each track’s available weather basenames in the database column circuits.weather_options, and the preset form renders them as a dropdown when an rF2 circuit is selected.

Graceful shutdown

rF2’s dedicated server exposes a small HTTP “WebUI” on the configured HTTPPort (default 5397 in our config). The agent issues a POST /navigation/action/NAV_EXIT for graceful shutdown, then falls back to SIGTERMafter a 5s grace window. Server’s results XML is flushed on the graceful path; the fallback path may produce an incomplete results file.