Settings
Settings is the app-wide preferences page (sidebar → Settings, beneath APP). It has two tabs: Behavior — the General, Session, and Local data cards covering close-button behavior, theme, visual contrast, startup-UI resets, hands-off auto-arm / auto-disarm automation, and the local config and diagnostics folders the app reads and writes — and Hardware — the force-feedback device picker, effect rendering, the Windows device backend, an experimental unlisted-device opt-in, and a live axis test. Every preference here is per-install, persisted to a JSON file under your user config folder.
Behavior tab
The Behavior tab holds three cards: General, Session, and Local data. These are the app-wide knobs that aren't tied to a specific force-feedback device.
General
Close button
Pick what the window's close button does when a system tray is available. Three options: Ask every time (default — prompts with a one-line dialog), Minimize to tray (hide the window, keep the bridge running and the stick armed), or Quit app (full shutdown).
On desktops without a usable tray (stock GNOME Wayland is the common case), close always quits and this setting is effectively ignored.
Theme
Pick the app palette, or follow the operating system. System (default) follows your OS light / dark preference; Light and Dark override it. The bridge re-themes immediately on change — no restart needed.
Visual contrast
Pick how strongly the whole app renders: Standard (default) keeps the normal palette, and High contrast strengthens readability across the entire app — stronger text and muted labels, clearer card and panel borders, more visible focus rings, stronger button and status-pill outlines, clearer idle / active states, and higher-contrast Dashboard effect-group swatches. It applies immediately and works with any theme choice (System, Light, or Dark).
This is deliberately called Visual contrast, not a "color-blind mode." It does help color-vision differences, but it's aimed more broadly — at aging eyes, cataracts, glare, dim rooms, and older or lower-quality displays. It is purely a visual preference: it does not change force output, profile values, tuning, or device behavior.
Startup UI
Two buttons for resetting first-launch UI state:
- Reset window — clears the saved window position and size, so the next launch opens with the default window placement.
- Show welcome — arms the first-launch welcome dialog to appear again on the next launch. Useful if you want to walk a tester through the orientation flow without reinstalling the app.
Neither button changes anything immediately; both take effect the next time the bridge starts.
Session
Hands-off startup and shutdown behavior for live sim sessions. Both checkboxes apply only when the input source is Live (the bridge is talking to a real simulator) — they're no-ops in Mock or Idle modes.
Auto-arm when ready
When checked, the bridge arms force output automatically as soon as every prerequisite is in place: a supported device is open, the simulator is reachable, no startup modal is blocking, and you haven't just manually disarmed during this sim session.
The last part is worth knowing — if you manually disarm mid-flight (the "I want hands-off until I land" case), the bridge respects it and won't re-arm itself until the next time the sim disconnects and reconnects. Quit the sim and re-launch it, or close the bridge and re-open it, and the auto-arm starts firing again.
Default off — the bridge defaults to manual-only arming so a first launch never surprises you with motors moving.
Disarm when sim exits
When checked, the bridge drops force output the moment your simulator stops reporting telemetry — quit MSFS or X-Plane and the stick stops moving, even if the bridge stays open.
Default off. With it off, the bridge holds whatever spring state it had at the last received tick (the stale-telemetry watchdog still fades dynamic forces, but the spring stays). With it on, the stick goes fully inert until the sim comes back and auto-arm re-arms it (if Auto-arm is also on).
The two checkboxes pair naturally: turn on both for a fully hands-off "stick wakes when sim wakes, sleeps when sim sleeps" session, or leave both off for the original manual-only arming behavior.
Local data
Local files used for preferences, diagnostics, and support bundles. Two sections side by side.
Folders
Two paths and two open-in-file-manager buttons:
- Config folder — holds your preference JSON files (this page's settings, session automation, hardware compatibility, SimConnect host / port, saved aircraft profile bindings). Open config jumps there in your file manager.
- Diagnostics folder — holds the rolling session log and any pending crash log. Open diagnostics jumps there. This is what gets bundled if you export a support bundle.
Both folders stay on this computer; nothing is uploaded unless you choose to attach a support bundle to feedback.
Local diagnostic data
Two buttons for clearing local diagnostic state:
- Clear crash report — removes any pending crash report on disk. Useful after you've sent a crash bundle and want to start clean, or if a stale crash marker is making the bridge keep showing the crash-recovery dialog on launch.
- Clear logs — deletes the session log files in the diagnostics folder. The in-memory log shown on the Diagnostics tab is unaffected and continues to capture new lines.
Crash and session logs stay on this computer unless you attach them to support via a support bundle.
Hardware tab
The Hardware tab owns the per-install device and driver knobs. Most of these are read once when the bridge starts the force runtime, so changing them prompts a small restart dialog (Restart now / I'll restart later / Cancel); Cancel reverts the change.
Force-feedback device
When more than one supported stick is attached, this row lets you pick which one the bridge drives. Change device… opens a picker with one row per attached supported instance, plus an Auto row and dimmed rows for supported sticks that aren't currently plugged in. The picker also auto-opens on first launch when two or more supported sticks are present and you haven't chosen one yet. A pin survives reboots; if you move the stick to a different USB port it falls back to automatic for that session and restores the pin when you move it back.
Effect rendering
A radio choice for how periodic and one-shot cues (rumble, buffets, shudders) reach the stick. Hardware effects — the default — drives them through the device's native force-feedback path. Software compatibility mode keeps only the continuous force / centering hardware path and synthesises the periodic and one-shot cues in software, folding them into the constant-force outputs. Software mode is the fallback for driver stacks that crash in hardware mode; both modes use the same effects and the same tuning sliders. There's a Test hardware effects button on this tab that runs an out-of-process probe — if the driver stack crashes, only the probe dies and the bridge stays open.
Windows Device backend
On Windows, the bridge talks to a validated SideWinder FFB2 over a raw HID/PID path by default, with DirectInput kept as an automatic fallback. This row lets you start directly on DirectInput if a particular install needs it.
Allow unlisted devices (experimental)
By default the bridge only drives sticks it has validated. Turn this on to experimentally drive a force-feedback joystick that isn't in the supported list. Wheels, gamepads, and single-axis devices are not eligible and are routed to the standalone FFB Probe instead. Use the axis test below to correct direction by feel after enabling it.
Axis test (invert + pitch/roll swap)
A live test for getting stick direction right. Drag the puck on a small X-Y pad and the stick follows in real time (the bridge auto-arms in Mock mode for the duration). If the stick moves the wrong way, flip Invert axis polarity; if pitch and roll are exchanged, flip Swap pitch/roll axes. Both apply live — no restart — and both apply to the axes as a pair at the device-output edge. They're especially useful for an unlisted stick whose wiring convention you don't yet know.