ACC Blog ACE Shared Memory API Documentation

This file mentions an "example solution", is it available somewhere ? Thanks.

 

Looks good, really appreciate the fact that the page names have been renamed compared to previous Assetto Corsa games!

 

Just a small observation that in the example code file SharedFileOut.h SPageFilePhysics does not follow the pattern of the other structures in now being renamed SPageFilePhysicsEvo.
This is handy for those of us with a project that supports AC so we don't get an error for redefining an existing struct.
Obviously I renamed it myself but would nice nice when copying future revisions.

 

Is it possible to add a section with a definitive list of cars and tracks (ie map of shared memory carModel/trackId to the display name used in the results files) like you did in the document for ACC? Also, is there a numeric carModelId like there was with ACC or is that gone now?

Thanks

 

Very much appreciated, and the solution seems to confirm something which I thought bizarre and had assumed was incorrect in the documentation - is there really no sector time reporting available via the API?

I'd love the answer to be "oops - forgot to add that", or at least "that's planned" - because I'd hate to go back to parsing the logs to extract sectors :-/

 

OOPS! And I can't even resort to parsing the logs for sector times because it appears that in 0.6 the whole log is now buffered until EVO exits?

 

Also a note that the program did nothing, I had to read the code to find out it prints one of the three structs when you press 1,2 or 3.

 

I think all of this is aimed at the kind of people who are comfortable looking at code...

 

Maybe, but I don't usually have to read code to use it.

 

It's not a robust, finish application for telemetry.

It's a small example so people who are implementing the above get the details they need.

There's not really a lot of point running it at all, it's more or less entirely made to look at.

If you want telemetry app, simhub et al are your friends.

 

I am one of the people who are implementing it, I'm working on adding ACE to Crew Chief...

 

Hi, as a heads up. The value of is_timed_race is flipped (1 for lap based races and 0 for timed races).

 

It looks like the SPageFileGraphicEvo.car_model isn't populated correctly for all cars. So far I've found the Lancia Delta and Toyota AE86 just report "0" - ie x48 followed by 32 nulls

 

Hi, in ACC times, the data of all other participants on the tracks (standings, timings, ...) have been made available using the UDP interface. What are the plans for AC Evo? Will the UDP interface be available here as well or will this information be integrated into shared memory (which is preferred for me, to be honest).

 

Testing the values I get some differences from the docs and other some differences by some cars (noted on two GT3 cars):

1. SPageFilePhysics.tyreWear[4] — documented but unpopulated

▎ PDF: "Tyre wear level (0.0 = new, 1.0 = fully worn) [FL, FR, RL, RR]"

Stays at 0.0 for every corner the entire session, on every car tested.

2. SPageFilePhysics.rideHeight[2] — unit not uniform across chassis

▎ PDF: "Ride height at front and rear axle in metres [front, rear]"

Most chassis publish metres correctly (≈0.05 race, ≈0.15 road). Some chassis possibly publish raw millimetres in the same slot — verified with a car whose rideHeight[0] and rideHeight[1] both read 60.04 (impossible as 60 m; consistent as 60 mm maybe?).

3. SPageFilePhysics.suspensionTravel[4] — sign convention not uniform

▎ PDF: "Suspension compression travel in metres" (implies non-negative)

Most cars publish positive compression from full extension. Some chassis possibly publish a signed displacement around a static reference instead — at rest the values come back negative (around −0.03 m), swinging both directions on kerb hits.

4. SPageFilePhysics.camberRAD[4] — right-side sign convention undocumented

▎ PDF: "Wheel camber angle in radians per corner [FL, FR, RL, RR]" — no sign convention specified.

Right-side wheels (FR, RR) report opposite sign from the setup tool. Setup of −4° front / −3.5° rear lands as:

┌────────┬───────┬───────────┐
│ Corner │ Setup │ SHM value │
├────────┼───────┼───────────┤
│ FL │ −4.0° │ −3.955° │
├────────┼───────┼───────────┤
│ FR │ −4.0° │ +4.038° │
├────────┼───────┼───────────┤
│ RL │ −3.5° │ −3.502° │
├────────┼───────┼───────────┤
│ RR │ −3.5° │ +3.496° │
└────────┴───────┴───────────┘

Magnitudes match the setup tool; only the right-side sign flips. Consumers wanting a uniform "negative = top-in" semantic must negate FR/RR.

5. SMEvoTyreState.tyre_temperature_left/right — labels are car-relative, not patch-relative

▎ PDF:
▎ "tyre_temperature_left: Inner-edge tyre temperature in °C"
▎ "tyre_temperature_right: Outer-edge tyre temperature in °C"

The labels are car-relative (the side of the contact patch facing the car's left), not patch-relative:

┌────────┬──────────────────────────────┬──────────────────────────────┐
│ Wheel │ ..._left slot │ ..._right slot │
├────────┼──────────────────────────────┼──────────────────────────────┤
│ FR, RR │ inner edge ✓ matches PDF │ outer edge ✓ matches PDF │
├────────┼──────────────────────────────┼──────────────────────────────┤
│ FL, RL │ outer edge (opposite of PDF) │ inner edge (opposite of PDF) │
└────────┴──────────────────────────────┴──────────────────────────────┘

Verified with a uniform −4° camber setup: the inner edge is hotter on every wheel only after swapping the L/R values for the FL/RL slots.

6. SPageFilePhysics.accG[2] (vertical) — gravity-subtracted, not documented

▎ PDF: "Acceleration in G [lateral X, longitudinal Y, vertical Z]"

accG[2] is gravity-subtracted — reads ≈0 g at rest and only swings under chassis pitch / kerb hits, rather than the ≈+1 g a consumer would expect at rest from a raw vertical accelerometer.

Has anyone confirm it? Or are my tests wrong?

 

Can a differentiation be made between different versions of cars in shared memory/results files? For instance with the Mini, the B16 vs A series is almost double the power so laptimes and fuel consumption will be dramatically different. It would be good to be able to identify these in order to categorise times and predict fuel usage