Discussion in 'Automobilista - Links & Resources' started by gongo, May 9, 2016.
I actually started doing something like this as well, but unfortunately this kind of things have very low priority in my life, that's why I have something that working but crashing AMS from time to time (I assume).
One question, why are you assigning variables manually but instead copy the complete data segements with a memcpy (or the related save variant) into the shared memory segment?
Probably a better question for @Marcel Offermans
We are getting more requests for information about some of the extensions that we've made and we will make those available when AMS is fully released, because right now we are still tweaking some of the elements in that structure. So be patient, it will happen, and probably those properties will indeed be there.
Hi Gongo, we have to install it for crewchief or similar software?
Ready for testing!
What a nice dev, I suppose like for telemetry+dash, rFactorSharedMemoryMaps can also be used with rFactor dedicated servers to get drivers time laps in order to do a liveview+hotlaps app (like pySRD9c). It is great as there is no need to take care about rf plugin part (I don't want to do C++dev, only python or php). Maybe just the RF_SHARED_MEMORY_NAME must be specified in external ini file to authorize several rFactorSharedMemoryMaps instances in case of several rFactor dedicated servers.
No config file for the plugin=>best choice !
My devs to read shared memory file will be with python too, maybe with django or web2py (as django runs with python3, I think it will be my choice).
The case of multiple instances will be launched from the same install folder is interesting because it is more tricky to work with but can result in a more efficient solution.
So the python app can first scans rfactor.exe processes to get running servers and their processid and then will get shared memory file to get server infos. So no configuration will be required to add a rfactor server on the python app (liveview/livetiming) as all runnning servers will be shown in the admin panel. The process id changing at each restart of a rfactor instance, each instance must be identified in the python app with the lobby name, or maybe used ports. I think it is a common sense to get every running rfactor servers by default and afterwards, ignore one or more instances if needed with the help of the admin panel. I have now a good starting point for the python app with your dll design!
I will be on holidays for the next 2 weeks, so I will test the new dll at my return !
Separate names with a comma.