DOCS ACC Shared Memory Documentation

I think it's better to reverse this, and use the udp data's session status info as it has much more status detail. Think this came up in the thread somewhere before. But as you know it only loads at the same time as the shared page files.

I've not looked at multiplayer, does the shared page files not contain normal data once the server hands control of the car to the game client?

 

@TheBigO / @expor / @AL612
Thanks for your responses. As the whole architecture of my app is driven by shared memory changes, I think I'm going to have to at least try to carry on in the same vein. In think what I'll do is if I see any change in SHM (static) an the status is ACC_OFF, I'll treat it as a possible spectator/non-driver stint and attempt a UDPconnection and see how that goes.

If that doesn't work, I'll have to turn it all upside down.

A few comments that it is better to use the UDP status info. I was under the impression (at least when I started playing with the UDP interface a long time ago), that a UDP session was tied to an ACC session (live race, spectator or replay). Once the ACC session ended, the broadcast session was stale. If a new ACC session started, you'd have to request a new UDP session. Is this not the case any more?

 

If a session ends (leave server, pause in single-player for example) indeed the UDP connection is closed, or rather no more data is sent. I added a heartbeat on the real time update and if I didn't get it for a certain amount of time I send a disconnect message (to clean up acc registration) to be sure, and request a new connection. This is repeated until the game accepts my registration, allowing the user to keep the app opened at all times.

 

Recently I've also been looking a bit at the UDP interface. Is there a way to synchronize the data from the broadcast API with that of the shared memory? For example, are the carIds from the shared memory the same as those in the entry list of the broadcast API?

 

I haven't checked that but the UDP interface is interval based, whereas you can read the shared memory whenever you want. Synchronizing it (i.e. exactly at the same interval) will be difficult if we don't know how the UDP interface works in detail. But running similar intervals on both UDP and shared memory should give you quite synchronized data, depending on your usecase. Personally I use the shared memory on top of the UDP interface. The UDP interface runs only at 2 seconds interval for me, just like the shared memory, so it doesn't come too narrow on timing .

 

Yes, the carIds match. As @expor says, you can harvest information from both but bear in mind shared memory is real time (more or less) but UDP would appear to be (at least for some things) asynchronous. IIRC some information is interval based (eg car info at a point in time) and other information is event based (entry list updates, accidents etc). I've never tried seeing if the interval based information is in sync between SHM and UDP or if there is a lag - I guess it would be easy to reconcile (compare car positions at a point in time)

 

Has anyone looked at the FinalFFB value and what it should be and what the value really means. Is it nm or some other value?

I started playing around with the wheel settings and thought this can be a nice way to detect possible clipping in the FFB. With quick testing, I get values ranging from -1.6 to 2.8 (in Monza, using TS-PC Racer), so my initial assumption of max % of possible forces was thrown out immediately.

Has anyone any insight on the FinalFFB value from physics packet?

Cheers.

 

Hey guys Can you help me a bit? I wonder how to detect if player is "in garage \ in options \ somewhere else behind Esc-menu" now? Not only in pause or in setup window but "not in action" at all ? I'm developing an overlays-app and I'd like to hide overlays while player pushed "Esc" and until he pushed "Continue". Thank you all btw you can check out armamentario_com - that's my app!!

 

Unfortunately never, as far as I know. At the beginning of the session you can detect via the SessionPhase variable from the broadcasting API whether session has started or not. But when the player resets the car to garage via menu, the session will still continue. Another idea would be the EnginRunning flag, but this fails if the player uses auto-start engine. I've solved this issue by combining the variables SessionPhase and InPitlane so that I can tell when the player is "on track". If someone finds a better solution, let me know.

 

Why penalty enum is wrong ?
If I get dsq for driving in the wrong way I get 22 instead of the 18 in the doc and the code example

 

Is there any way to parse a replay file (.rpy) ?
Sadly, I have not found any information at all about it online.

What is the file structure of these files? Or are we not allowed to parse those files?

 

Does anyone know if shock velocity (damper velocity) is available in the ACC shared memory? It doesn't appear to be, but some people claim to have that data in Motec for histograms.

 

Looks like MoTeC is a different thing, since these files are written seperately.

 

Damper Speed is not, but Damper Position is, if you take the derivative of your Damper Position values you'll end up with Damper Speeds.

 

OK - so they are calculating it, and not getting it directly from the API. Thanks.

 

No idea, but I intend to play around with it sometime soon. Anybody else on the thread here know what to expect from it? A bit of settings-changing should show approx what range to expect, and that should be enough to find some kind of usable/known data values from it.

The shared-memory has a "packet-id" field, which indicates the revision of the SHM data that has been pushed. There's a user-defined setting for FFB Hz, I wouldn't be surprised if the SHM updates are at FFB rate. (Makes sense from a code POV, a high-prio thread is running/calculating these things to provide feedback to user - copying a ~800 byte physics update message to SHM won't take long. At that point, the packet-id is also updated.

My point is, reading the SHM data "whenever you want" won't give accurate/good results; interpreting it via the packet-id count (and perhaps offsetting it in time based on the packet-id rate) will give much more accurate results.

 

Following up to previous message - had a look here just now, it seems pretty clearly to be -1.0 to +1.0, with - being "turning left" force feedback, and + values being turning right (so steering pushing to left). I'm pretty sure the value here is being plotted in the HUD's "FF" slider-gauge value.
To be clear, the value I've investigated here is the "SHM.physics.finalFF" value. Its range is -1.0 to +1.0 float32.

I'm reading it from a ACC SHM wrapper in the Rust language (my own bindings). I'm not sure how you're accesssing values, but if there's values wildly astray, then its likely a bug in how the SHM is being read. If you have *loads* of clipping, and the values range from -1.6 to +2.8, then that kinda maps OK too, but you'll want to reduce the gain in the FFB section *a lot* (~2x?) to get those FFB values in check.

Or setup the car with less caster, because caster causes FFB.

 

Apologies if this has been asked before. Had a quick look through and couldnt see anything besides what is in the shared mem PDF. Further apologies for what might be a n00b question.

For the forecast info, there are 6 levels of 'rain' (0-5), which is fine.

But my question is, how would you display the below increasing and decreasing values, as they all just show as heavy rain and no way to distinguish.
Is there a sum of 2 forecast values to show if it will increase or decrease or are these displays something that we cannot currently get from the shared memory yet?

 

Unsure if you're aware, but Cylance via Virus Total are flagging SharedMemoryACCS.zip as malicious.

SharedMemoryExample.exe is flagged by both SecureAge APEX and MaxSecure as malicious (MaxSecure shows it as a Trojan)

 

If I recall correctly, the way the example reads input keys (using GetAsyncKeyState?) is often tagged as a virus/trojan by those less commonly used AV tools. For my SHMEM-to-UDP relay for my Telemetry Tool I rewrote the key reading part, and the virus warnings went away.

Cheers.