DOCS ACC Shared Memory Documentation

I derive the duration from graphics.sessionTimeLeft.

When I try your scenarios:

Case 1


Case 2

Case 3


Case 4


So, it looks like you are correct - it looks like the numbers in shared memory are incorrect

@Ensi Ferrum - can you confirm if the PitWindowxxxx are incorrect or if they take into account other times?

Thanks
Doug

 

@Ensi Ferrum ignores us saaad....

 

It looks like even this PDF thinks the Porsche 718 is a rear-engine car. The 911 is the rear-engine one, the 718 is their line of mid-engine vehicles.

 

@Kunos - another year, another try:

I am the author of a very sophisticated, AI-based simulator companion (see https://www.assettocorsa.net/forum/...for-acc-pitstop-mfd.68024/page-6#post-1207221), which is in widespread use in the community. Part of the software suite is "Race Center", a tool for endurance teams to handle all race duties incl. planning and remote control of a pitstop by team members not currently driving.

The implementation for pitstop control in ACC is somewhat cumbersome, at least in contrast to other simulations.

1. First, the information about the current state of the Pitstop MFD is incomplete (the repair settings are missing from the shared memory).
2. The state of currrently selected or available options (tyre change Yes/No, brake change Yes/No, Change Driver, etc.) is missing from shared memory. To overcome this, I use an image recognition algorithm, which is, at best, error-prone and not easy to configure.
3. Last, but not least, it is only possible to change the settings in the Pitstop MFD by placing keyboard commands into the command queue of ACC, which is also not the best of all methods. A real API would be much more safe to use.

It would be so great, if you support a mush more sophisticated pitstop API in one of the next releases. I can support the development by writing a specification and also running all necessary tests.

Just my dream for 2022!

 

Are there any shared memory datas usage limitations ?

 

there are no limitations on shared memory usage.

Regarding the pit window stuff, it's definitely wrong. It matches what you set in the session options only if you skip practice and qualifying. As far as I know there's no way to derive these values from the other data.

 

Do you know if those data are out of Eula conditions so free to be reused for any commercial/open source users purposes ?

Are those data somehow user property ? so users that generate them by playing the game are free to share and elaborate as they like untill Kunos openly keep sharing them ?

 

I've never sat down and thought about it. As far as I know, the data exposed by the game's own APIs can be used by 3rd party applications which may be commerical. But there may be limits on the sharing, persisting and distributing of those data which are imposed by individual states (like the GPDR laws here in the UK). I have no idea if any of the data exposed or the data structures themselves represent protected intellectual property. What are you planning do with it?

 

Shared Memory is a temporary memory into computer RAM, so technically can't be called API since you don't interrogate the game software to get them rather you are accessing your own computer memory where programs put data temporarily.

Since Shared Memory can be shared as readable only, crypted, readable and writable or none of both... those data seems there free to use.

So i guess game conveniently make them unencrypted readable-only to be read from others applications freely.


So the question is if those data can be freely saved/persisted and reelaborated to make 3rd party derivative services or there are rules/limitations about how those data can be manipulated or reused.

 

The legal department will be in touch shortly

 

The doubt is about if eventual 3rd party application will help/ask users to manipulate their data, like a reelaboration of a user's text document content generated by a software or if those data still be intellectual property of the software whose generated them ( the content of a text document still be property of the application whose generate them) .


Since among readable datas there are also global coordinates, i guess one is not allowed to use them for derivative works, since could infringe software intellectual property.

Whereas for example throttle inputs are data genereted by users' inputs on own peripherals.


The doubts about the possibility of limitations about the data usage, comes from readable global coordinates data presence among data.

Assuming that global coordinates can't be used for derivative work nor be persisted, are the others datas intended to be users' generated content as a user's game session conditions photograph free to be persisted and reelaborated ?


Anyone bumped in this doubt either ? Are there documents that clarify these aspects somewhere ?

 

Lots of people have been making (and in many cases charging for) applications that use this data for years without this being an issue, why are you so concerned about it?

 

Just doubts before starting any development

 

kinda something similar to this : https://www.beuc.eu/publications/data-act-important-competition-and-consumer-choice/html

 

Is it allowed by Kunos to save data read using ACC Shared Memory ?

 

Referring to the EULA, I understand that the data you record and read from the shared memory by yourself is yours and you can do with it whatever floats your boat. If you or someone else use it for commercial purposes, only your permission is necessary. Of course, what you're not allowed to do, is to use the data to reverse engineer ACC. The GPDR only applies when personal data is involved. I highly doubt that your throttle input or tire pressure constitute personal data.

Another question is, why should Kunos forbid commercial use of the data? After all, they have an interest in having their simulation supported by more 3rd party tools, I would say.

 

Any chance of an update on the pit window open / close time bug? The values for these fields are only correct if you skip practice and qualifying. I don't think there's a way to reliably work out what they should he based on other available data so they're a bit useless at the moment

 

Ahhhh, lightbulb moment with the pit window. When you set a pit window the value of (accStatic.PitWindowEnd - accStatic.PitWindowStart) is always correct. This is calculated for the first session in the weekend and remains fixed throughout the weekend. The issue here is that it's centred around the mid-point of the first session (even if it's not a race session).

So if you have a 10 minute practice and a 1 hour race with a 30 minute pit window, that 30 minute pit window will have it's middle in the middle of the first session (the mid-point of the pit window is aligned with the mid-point of the first session). So in this example window start will be - 10 minutes and the end will be 20 minutes. That gives a 30 minute window which is centered in the first session.

So to get the correct start and end of the pit window in the race you just need to do this:

calculatedWindowLength = gameProvidedWindowEnd - gameProvidedWindowStart
correctWindowStart = (sessionLength - calculatedWindowLength) / 2
correctWindowEnd = correctWindowStart + calculatedWindowLength

if calculatedWindowLength < 0 then there's no pit window. Note that gameProvidedWindowStart can be negative (or zero), gameProvidedWindowEnd can be greater than the session length.

Also, as far as I know there's no fixed field that contains the total session length (unless I'm missing it) so this calculation relies on you getting hold of the sessionLength somehow. I do this by saving the sessionTimeRemaining value at the start of a session. Of course, this means that my pit window hack will be tripped up if the player starts a race mid-session from the pit lane

 

Shared Memory Documentation is updated in first post.

 

Wasting your time, I and many other asked many times for more data / change.
The same thing as you pit stop mfd information for pyaccengineer and acc drive

Give up on kunos, you are just talking at a wall here