Is my claude hallucinating? It doesn't get it to run and tells me this:
Subject: AC/ACC — SLIP/LOCK/ABS haptic effects never trigger due to unpopulated tyreRadius in static page from simshmbridge
Setup: monocoque (built from source, pinned simapi commit 50fd181) + simshmbridge’s acbridge.exe/acshm as the Windows→Linux shared memory bridge for Assetto Corsa Competizione running under Proton on Linux (Bazzite).
Symptom: With SLIP/LOCK/ABS/Engine configured as Sound devices, only the Gearshift effect produces reliable, correct output. Engine (RPM-based) never scaled meaningfully with actual RPM/load regardless of modulation setting (frequency or amplify), and SLIP/LOCK/ABS never trigger at all — even though the telemetry pipeline itself is confirmed live (RPM/speed/gear values update correctly in verbose logs).
Root cause found for SLIP/LOCK/ABS (verified by compiling against the actual pinned header, not just reading it):
1. simmapper.c sets SimCalculatesTyreDiameter = true for SIMULATORAPI_ASSETTO_CORSA. Per gameloop.c, this means the background tyre-diameter calibration thread (the fallback used by other sims, e.g. rFactor2) is never started for AC/ACC — monocoque relies exclusively on simdata->tyrediameter[] being populated directly by the mapper.
2. acmapper.c reads tyreRadius from SPageFileStatic at offsetof() = 436 (confirmed by compiling include/acdata.h directly, not hand-calculated).
3. Inspecting the live shared memory file (/dev/shm/acpmf_static) at that exact offset while ACC is running shows all zeros. Earlier fields in the same struct (car name, near the start) contain valid data, confirming the struct itself is real/live — acbridge.exe simply never writes the car-static fields (tyreRadius, maxRpm, maxTorque, etc.), likely because its original use case (dashboards/SimHub-style display) never needed them.
4. Result: hasTyreDiameter() always returns false → wheelslip[] is never computed → SLIP/LOCK never fire, and ABS is gated behind the same code path even though simdata->abs itself is correctly mapped and available.
Possible fix we’re considering on our end: acmapper.c never populates simdata->tyreslipratio[] at all, even though ACC’s SPageFilePhysics (which is relayed correctly — RPM/speed/gear all come through fine) already contains a ready-made wheelSlip[4] field. Mapping that directly (or deriving slip from wheelAngularSpeed[4] + speedKmh with an assumed tyre radius) would bypass the broken static-page dependency entirely.
Separate, unresolved issue — Engine effect: Even independent of the above, the Engine haptic effect never produced a convincingly RPM-scaled sensation for us on AC/ACC, under either modulation mode. We haven’t root-caused this one yet, so any pointers here would help too.
Questions for you:
• Is the static-page limitation a known gap in simshmbridge‘s AC/ACC support specifically? Would a PR mapping wheelSlip/wheelAngularSpeed into tyreslipratio in acmapper.c be welcome, or is there a reason it was left out (e.g. a units/sign-convention issue with ACC’s wheelSlip)?
• Any idea why Engine doesn’t feel RPM-proportional in practice, even with amplify modulation?
Is my claude hallucinating? It doesn't get it to run and tells me this:
Subject: AC/ACC — SLIP/LOCK/ABS haptic effects never trigger due to unpopulated tyreRadius in static page from simshmbridge
Setup: monocoque (built from source, pinned simapi commit 50fd181) + simshmbridge’s acbridge.exe/acshm as the Windows→Linux shared memory bridge for Assetto Corsa Competizione running under Proton on Linux (Bazzite).
Symptom: With SLIP/LOCK/ABS/Engine configured as Sound devices, only the Gearshift effect produces reliable, correct output. Engine (RPM-based) never scaled meaningfully with actual RPM/load regardless of modulation setting (frequency or amplify), and SLIP/LOCK/ABS never trigger at all — even though the telemetry pipeline itself is confirmed live (RPM/speed/gear values update correctly in verbose logs).
Root cause found for SLIP/LOCK/ABS (verified by compiling against the actual pinned header, not just reading it):
Possible fix we’re considering on our end: acmapper.c never populates simdata->tyreslipratio[] at all, even though ACC’s SPageFilePhysics (which is relayed correctly — RPM/speed/gear all come through fine) already contains a ready-made wheelSlip[4] field. Mapping that directly (or deriving slip from wheelAngularSpeed[4] + speedKmh with an assumed tyre radius) would bypass the broken static-page dependency entirely.
Separate, unresolved issue — Engine effect: Even independent of the above, the Engine haptic effect never produced a convincingly RPM-scaled sensation for us on AC/ACC, under either modulation mode. We haven’t root-caused this one yet, so any pointers here would help too.
Questions for you: