DOCS ACC Shared Memory Documentation

Ok, i assume this is a misunderstanding because my initial explanation was poor.

When you drive a normal lap without any teleporting, you get the following behavior:

• lap is started, currentSectorIndex = 0
• you cross the first sector border and then observe that currentSectorIndex = 1
• you cross the next one, then observe currentSectorIndex = 2
• you cross the finish line and begin the next lap, and get currentSectorIndex = 0 again.

The variable always displays the sector's index that you are currently in at any time, hence its name currentSectorIndex. Not lastSectorIndex, not lastSectorEnteredByCrossingSectorBorders, but currentSectorIndex.

Now this is where it gets strange:

• you start a lap, are at currentSectorIndex = 0, cross the border to the next sector, and get currentSectorIndex = 1
• then you teleport into the pit, and still have currentSectorIndex = 1, although the pit is in sector 0. (i assume you see the menu where you can go into the car settings or click "drive")
• you click "drive" and start rolling out of the pit lane: even on the first meters out of the pit, it still displays currentSectorIndex = 1 although it should be 0.
• when you cross the border to the next sector, it simply stays at currentSectorIndex = 1 as it now becomes the correct value, but before it was not.

It seems to me like this variable is only set when crossing actual sector borders, so it can only ever become 0 when you cross the finish line. This is of course the "natural" way to traverse sectors.
The bypass by teleporting could also be handled by resetting the currentSectorIndex field as soon as the car position teleports.
Otherwise, what can you use a variable for if it is sometimes wrong?

 

That is not the only thing that only gets updated on entering the next sector, for example the current driver index has the same issue. If you driver swap it is not visible until entering the next sector :\.

 

yeah u only see swapped driver when u exit the pits... can't quite remember if it's updated after the first sector...

 

It's not only after exiting the pits but only when entering the next (first) sector.

 

Does anyone know if there is any reference for track coordinates in terms of the coordinates given in shared memory - eg the start line at brands hatch is given as -136, -8, -384 ...I assume that it X, Z, Y. I'm looking for mapped coordinates of the track limits of each track.

Also, does anyone have a more detailed explanation of the difference between wheelSlip and slipRatio (or are they just the same thing in different units)?

Thanks

 

Can we expect still to see the PacketStatic's acVersion string to still be updated to reflect the real version number and hopefully keep updating as new versions are being released? The smVersion got updated, but the acVersion hasn't been updated for a while.

Cheers.

 

Is anyone else experiencing any weird behaviour with the sector timing? I'm running ACC 1.8.17, and I'm finding that the SPageFileGraphic lastSectorTime value is correct for the first sector (i.e. when currentSectorIndex changes from 0 to 1, the reported Sector 0 time is correct), but then the reported value is cumulative for Sector 2? The value immediately resets to 0 when crossing the start/finish line, rather than showing the sector time for the last sector on the previous lap.

For example, say I'm completing an out lap at the start of a session which contains 3 sectors:

currentSectorIndex: 0 - lastSectorTime: 0 - This is what I'd expect, as we haven't yet completed the first sector on the out lap.
currentSectorIndex: 1 - lastSectorTime: 40256 - First sector complete, the reported lastSectorTime of 40.256 seconds is correct.
currentSectorIndex: 2 - lastSectorTime: 71388 - Second sector complete, the actual sector time was 31.132, but the lastSectorTime value is a cumulative of Sector 1 and Sector 2 for some reason?
currentSectorIndex: 0 - lastSectorTime: 0 - Final sector complete, the lap is now complete. The sector index has reset to 0 as expected, but so has the lastSectorTime? We can calculate the final sector time by deducting the first two sector times from the lap time, but this seems like an unnecessary work around.

Is anyone else seeing this? I wonder if something has changed from when the ACC Shared Memory interface document was last updated (v1.8.12) and now (v1.8.17)?

 

I think it has always been like that....I seem to remember always having to calculate sector 2 from the lap time and the other 2 sectors

 

Thanks for confirming! If it's always been like that then I'm happy, I can work around it as you've said. I don't recall the AC Shared Memory implementation behaving like that which is why I was getting somewhat confused.

 

@pankykapus Do you think we might get still the game to report the right version via SHMEM?

 

My workaround for this was to use isInPit from the SPageFileGraphic subset as a flag to reset the currentSectorIndex back to zero when isInPit = true.

 

I discovered that ACC outputs 0 in a track length field in a static shared memory structure. Is there any other way to determine a track length? I can even consider a config file with a map from track name to track length but I couldn't find one.

 

I haven't checked if it's also 0 for me, but when I needed it a while ago I was using the Broadcast API instead and that worked fine.

 

@AvedisZildjian - The document does say Static.trackSplineLength is not used by ACC, if that is the field you are talking about.

As @expor says, it is present in the broadcast API

 

I'm not sure it's a good idea to rewrite the whole system (which works for both AC and ACC) for just one value

 

So it seems there's a descrepency between shared memory and what is being displayed in game when it comes to weather (`rainIntensity` values). Any idea what is causing this?

 

Yeah I have observed the same issue in my app. Sometimes it says DRIZZLE in SM but it's dry ingame, or stuff like you showed where it mismatches the intensity :/

 

The times you've seen it fail, have they been in singleplayer or multiplayer? I don't recall ever seeing this issue in multiplayer, but whenever I'm testing things in singleplayer this seems to happen fairly quickly... Need to setup a server to test it I suppose.

 

When the SM was first changed to add support for these values it was 100% correct, both SP and MP. At some point in time (wouldn't know which patch) the values started to differ however. I have only tested in MP lately as my app is used on for that context. I think it depends on the weather variation setting because if it's a session with fixed weather (e.g. Qualifying setting) then the issue never happens. In a race where weather randomness is present (even if it remains dry!) I see the issue happening. However I mainly observed it in transitioning periods. E.g. when it's going from medium to light/drizzle, then the values in SM start to become seemingly 'random'.

 

Have a look at the information of each track inside the game, the track length is specified there.