mirror of
https://github.com/ddeverill/SteamlessController.git
synced 2026-10-21 06:09:45 -05:00
Dylan DeverillandClaude Opus 5
c7866ecfa7
With another program's rebranded ViGEm already on the machine, setup's driver install silently does nothing and reports success. The user finds out when they click Enable Steamless Mode and no controller reaches the game. Reported in #68, where the only ViGEm driver package left afterwards was the Oculus fork's; running the ViGEmBus installer by hand then offered Modify/Repair/ Remove rather than a fresh install, so the bundle had registered itself without a working driver ever landing. Everything downstream of that — the connect failures, the retry storm, and on 1.13 the device cycling that stranded a reporter's HID collections — starts here. The preceding commits make that state survivable and diagnosable; this one keeps it from being reached. Setup now asks the same question the app asks at runtime: is a device publishing the ViGEm bus interface present? Every cheaper check was measured and found to lie. The bundle exits 0 when it detects a related product and declines to act, so the exit code says nothing. The registry records the product whether or not a driver landed. And the driver's version is no guide either, since 1.22.0 ships a binary still stamped 1.21.442.0 — which cost an afternoon before it was pinned down. ViGEmBusProbe carries the check, and is installed rather than left a build artefact: its other job is being the thing to ask a user to run when a controller never reaches a game. Exit code 0 means at least one usable bus, 1 means none. Verified both directions against a real bus and a disabled one. A failed check does not fail the install. The app is fine, and it now picks the driver up on its own once it appears, so the message says what to install and that no reinstall is needed afterwards. Silent installs log the finding instead of stopping on a dialog nobody is present to close. It informs rather than repairs. Running msiexec /fa or the bundle's own repair would be acting on shared-identity MSIs on the one kind of machine known to have other products' drivers registered against them, which is not a risk worth taking to save a download. The installer code itself is unverified: there is no Inno Setup on the machine this was written on, so the Pascal has not been compiled and no install has been run. It also assumes ssPostInstall follows the non-postinstall [Run] entries. That assumption fails loudly if wrong — every healthy install would warn — which is why the check sits there rather than behind a wrapper built to guarantee the ordering. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>