DOCS ACC Shared Memory Documentation

Someone already asked this but I didn't see any response to it. What is the unit for wheel slip?

 

Hi everyone, is anyone having issues reading the values : TC ; TCCut ; Abs from graphics ?
Mines are showing 0.

 

Is there a way to get notified when the data in the shared memory changes???

 

Typically no, applications just poll the Shared-Memory, and check if it has been updated since last poll.

For example, SPageFileGraphic->packet_id represents the "version" of the data in the graphic mapping.
In the polling thread, sleep for (1000/400) milli-seconds to get ~400 Hz (fastest update rate from ACC).
Check the packet_id field, and if it has changed use the updated graphics values.
If the packet_id is the same as last time, sleep a while again (potentially shorter, to avoid missing a frame..?).

Depending on your use-case, perhaps ~100Hz polling is enough? Or 10Hz?

Hope that helps! Regards, -Harry

 

Read the PDF accompanying the code.

TC is reported in multiple places, as noted by the ** in the PDF (where * means reported in multiple places).
Also see the color coding (green == ACC reports here. Red == Not used by ACC).

In graphics, the TC indicates the *amount* of TC used (integer values, 0..8 or so typically)

In Physics, the TC indicates *active* right now or not (so some filtering/edge-detecting might help, as it "bounces" around a lot).
Also in Physics, the "tcinAction" field is *not* used, nor is "absInAction".

Hope that helps, -Harry

 

I'm afraid I also don't know. From testing a few "TC=0" and "ABS=0" scenarios, it seems like a value usually around 0.0 -> 0.3 range, and
during extreme slipping (burnout, or brakes-locked) the value is *absolute* (always positive) and ranges up to ~60? (60 is a strange value here, so perhaps 100? Sideways burnouts seem to give highest values...) Data during locked brakes (ABS off):

Fast -> slow, with the last value almost at standstill:
wheel slip: [12.379552, 12.179218, 0.5051858, 0.47648746]
wheel slip: [11.004572, 10.819942, 0.94976604, 0.89266765]
wheel slip: [1.745168, 1.720583, 0.45911026, 0.44503132]

That said, I think you're likely trying to understand tyre slip, so I'll answer that question instead:
Physics has slipRatio and slipAngle as per https://en.wikipedia.org/wiki/Slip_(vehicle_dynamics)

Given "wheelSlip" doesn't have direction (absolute value doesn't say if burnout/locked-brakes) its kind-of-a-useless-value.
Slip ratio tells which is which, as well as magnitude so is almost always a better indicator/value to use.

If you describe the problem you're trying to solve, perhaps we can help better? -Harry

 

@twitch.tv/helloimhana I guess wheelSlip[4] is "longitudinal" slip ratio only then, which is unitless, but it should then -> infinity when locked up. have to investigate... how could they have ratio and angle in one number... hmmm

thx Harry, I already use the packetId and polling, I just wondered if one could do better. Probably a technical impossibility ;-)
Windows also has its problems with polling faster than 64Hz (16ms), but I got it up to 400Hz

 

Note that SPageFileGraphic is only updated with ~50 Hz, so it might be enough for your purposes. I also ran into the polling issue on Windows. I solved it without sleeping by using a while loop and storing each frame when packetId is incremented.

 

Document has incorrect brake bias offset for Honda NSX GT3 Evo 2019
Documented: -14
Actual: -20

 

Hey guys! Is this the right place for change requests regarding the Shared Memory?
It seems like right now the Shared Memory in ACC is implemented with "INVALID_HANDLE_VALUE" as its file handle. This means that the Shared Memory lives solely in the memory of the machine.
This works perfectly fine for applications running in windows, but an increasing amount of drivers are checking out linux and running the Sim under wine.

To make the Shared Memory easily accessible when running the application under wine it would need a valid file as its file handle.

This would only require a line of CreateFileA() to get a valid File handle that lives somewhere the user specifies.

If this path gets implemented as a command line argument you are able to create this file on the linux shared memory /dev/shm and then interface this data from linux directly.
Obviously this file should only get created when the parameter is specified to avoid excessive reads and writes on the users disk.

I would love to hear your arguments for or against this.

Edit: Pressed send accidentally with the space bar.

 

Nvm., after some reading and understanding I realised that ACC never actually Creates any Memory Mapping itself. The tools just map a section of the ACC memory to themselves and use the data this way. So the only way to access the data from a linux application seems to be a relay that takes the ACC memory and writes it to a file for other processes to read.

 

Hi, i have observed that the field `isValidLap` seems to be nearly always true in races. I have observed multiple times that the field stayed `true` after obviously cutting the track. In practice or qualy it seems to behave as expected.

Is track cutting handled differently in races?

 

It is, but you can get the value from the UDP interface.

 

As you mentioned the UDP Interface, where are the docs for that please?
I've already implemented an interface to the shared memory (based on code from Mathias Djarv 2017)

thanks in advance,
Sam.

 

This is good to know, thanks!

I know the Static info isn't really updated at all, do you know how often SPageFilePhysics is updated. I think I read somewhere that it was similar ~50/60 Hz. Is that true?

thanks,
Sam.

 

I don't know of any docs, but the Kunos Broadcasting API is part of the Dedicated Server, which can be downloaded from Steam. The API is C# based...

 

Thanks! I'm working on a Wifi interface using an ESP32 controller so I can get rid of some cables. I can tolerate a 150ms lag for my use-case, so I should be ok on Wifi, more testing needed.
From reading through the last year's worth of posts here, It looks like I need to aggregate info from both SM and UDP to get as accurate picture. Then again, does it really matter if my speed readout is late by a few hundred ms? no it doesn't.
My comms protocol is lightweight with a small data packet < 200 bytes.

Sam.

 

Problem might be then, that the UDP interface is asynchronous by nature. It is not guaranteed to meet your 150 ms requirement, which might not be of a problem for the invalid lap flag, for example. All time critical stuff is available in the shared memory API anyway.

 

@pankykapus As the 1.9 is just around the corner, will the UDP feed game version be updated?

The game still reports 1.7 as version, but the game is already at 1.8. Getting the version info updated in the UDP feed would make it easier to detect laps/laptimes from a newer version, when doing e.g. comparison.

Cheers.

 

Any changes in 1.9? /wisheshopeful