Difficulty mapping AC1 shared memory across proton prefixes

[giantorth]

I have put together a launcher script to bundle simhub and your simshmbridge automatically with a game launch. It's working fine for ACE and ACR but for some reason I cannot get shared memory to connect to simhub across prefixes for AC1. Simhub works correctly when run inside the same prefix, but only works across prefixes to ACE/ACR.

Curious if you had any pointers on why telemetry isn't mapping for AC1. I do have content manager enabled and the simhub python plugin installed.

[Spacefreak18]

if you have the wine prefix, then inside the wine prefix it should just be a matter of starting the acbridge.exe file. (I have a zip with all the different bridge files in the releases page, it's highly experimental, I haven't gotten any feedback on how those work on different peoples machines)

I do this for CrewChief.

The only gotcha, and I don't know what SimHub is doing, but for CrewChief, I rename that file to acs.exe so that it fools CrewChief into thinking Assetto Corsa is running. (Crewchief can only see other processes and shared memory inside the same prefix.) Renaming the exe kills two birds with one stone. Just make sure you don't start this wine prefix until you see your native linux /dev/shm/acpmf* files have data in them, that's a big tip.

There are a couple places to find the exe name for each game...
https://steamdb.info/app/244210/config/
https://gitlab.com/mr_belowski/CrewChiefV4/-/blob/main/CrewChiefV4/AllGames/GameDefinition.csv?ref_type=heads
(or you can just brute force, start the game, start driving, and use ps ax

[giantorth]

Ahh the delay is probably my issue, when using content manager the real game doesn't actually start right away. I think this results in the bridge starting in the simhub prefix before the game actually launches.

[Spacefreak18]

Ahh the delay is probably my issue, when using content manager the real game doesn't actually start right away. I think this results in the bridge starting in the simhub prefix before the game actually launches.

actually, i think i mispoke, they probably don't need to have data in them, but they definitely need to atleast exist before you start the process in the simhub prefix

edit: that's why in the docs I talk about a specific order of operations

[giantorth]

Okay did some further testing and I think it's actually something specific to Simhub, they have a python plugin now for AC related to shared memory and I suspect they've modified the layout in some way that doesn't work with simshmbridge.

To clarify: monocoque works correctly, I just can't get simhub to read SHM correctly across prefixes, Understand if you wish to close as not fixed.

[Spacefreak18]

that doesn't make much sense, if you can get crewchief to work, simhub should work. I've seen a python plugin for shared memory floating around, that basically just sets a few limited fields.

unless they've added something to detect that I've artificially increased the size of the shared memory.

or it has to be they're looking for a specific exe name before they even try to map the shared memory in

none of this they'll tell you

i wish there was a small exe i can run in wine that would just dump out the shared memory info, you can do this with simshmbridge if you compile it in debug mode, but it IS cumbersome.

[giantorth]

I've got my wrapper script setup to where it performs the following steps (with appropriate launch parameters set):

1. Launches acshm in Linux
2. Modifies game launch parameters to include acbridge.exe to run inside game prefix
3. Launches the game+bridge
4. Hardlinks acbridge.exe to the name of the game exe
5. Launches the hardlinked game exe bridge in the simhub prefix
6. Launches simhub
7. Waits for game exit and cleans up all launched processes

Simhub is correctly detecting the game based on this launch behavior (and everything works as expected when running ACE/ACR) but doesn't actually establish a data link.

Tonight I plan on pulling apart the python plugin simhub wants installed in AC to figure out exactly what they're modifying, I suspect the plugin is adding a new value to help their own detection process that's outside the standard AC shared memory layout.

[Spacefreak18]

I've got my wrapper script setup to where it performs the following steps (with appropriate launch parameters set):

1. Launches acshm in Linux
2. Modifies game launch parameters to include acbridge.exe to run inside game prefix
3. Launches the game+bridge
4. Hardlinks acbridge.exe to the name of the game exe
5. Launches the hardlinked game exe bridge in the simhub prefix
6. Launches simhub
7. Waits for game exit and cleans up all launched processes

Simhub is correctly detecting the game based on this launch behavior (and everything works as expected when running ACE/ACR) but doesn't actually establish a data link.

Tonight I plan on pulling apart the python plugin simhub wants installed in AC to figure out exactly what they're modifying, I suspect the plugin is adding a new value to help their own detection process that's outside the standard AC shared memory layout.

keep me posted, what you're saying in the last paragraph, could be possible... I'd be curious to know for my own projects.

edit: and yes, that order of operations looks good to me. Double check that you have data in /dev/shm/acpmf_physics, and if you really want to go down the rabbit hole, there is a debug mode in simshmbridge, which enables a hexdump function, so when you run it in the simhub prefix, you should see if you're actually getting anything other than zeros into that prefix. if that makes sense.

[giantorth]

Looking at the simhub plugin it looks pretty simple (only 2 python files), including because they say no license at the top already. It looks like it's creating a new shared memory object acpmf_simhub_v2 with additional data not found in the main area. The other file just updates the values in these structures:

"""
SimHub SharedMemory
Based on CrewChief work (Sparten)
No licence apply.
"""
import mmap
import os
import struct
import functools
import ctypes
from ctypes import c_float, c_char, c_int32

class vec3(ctypes.Structure):
    _pack_ = 4
    _fields_ = [
        ('x', c_float),
        ('y', c_float),
        ('z', c_float),
        ]

class acsVehicleInfo(ctypes.Structure):
    _pack_ = 4
    _fields_ = [
        ('carId', c_int32),
        ('driverName', c_char * 64),
        ('carModel', c_char * 64),
        ('speedMS', c_float),
        ('bestLapMS', c_int32),
        ('lapCount', c_int32),
        ('currentLapInvalid', c_int32),
        ('currentLapTimeMS', c_int32),
        ('lastLapTimeMS', c_int32),
        ('worldPosition', vec3),
        ('isCarInPitline', c_int32),
        ('isCarInPit', c_int32  ),
        ('carLeaderboardPosition', c_int32),
        ('carRealTimeLeaderboardPosition', c_int32),
        ('spLineLength', c_float),
        ('isConnected', c_int32),
        ('suspensionDamage', c_float * 4),
        ('engineLifeLeft', c_float),
        ('tyreInflation', c_float * 4),
    ]
      
class SPageFileSimHub(ctypes.Structure):
    _pack_ = 4
    _fields_ = [
        ('numVehicles', c_int32),
        ('focusVehicle', c_int32),
        ('serverName', c_char * 512),
        ('vehicleInfo', acsVehicleInfo * 128),
        ('acInstallPath', c_char * 512),
        ('isInternalMemoryModuleLoaded', c_int32),
        ('pluginVersion', c_char * 32)		
    ]

class SimHubShared:
    def __init__(self):
        self._acpmf_simhub = mmap.mmap(0, ctypes.sizeof(SPageFileSimHub),"acpmf_simhub_v2")
        self.simhub = SPageFileSimHub.from_buffer(self._acpmf_simhub)
              
    def close(self):
        self._acpmf_simhub.close()

    def __del__(self):
        self.close()
            
    def getsharedmem(self):
        return self.simhub
        

[Spacefreak18]

Looking at the simhub plugin it looks pretty simple (only 2 python files), including because they say no license at the top already. It looks like it's creating a new shared memory object acpmf_simhub_v2 with additional data not found in the main area. The other file just updates the values in these structures:

"""
SimHub SharedMemory
Based on CrewChief work (Sparten)
No licence apply.
"""
import mmap
import os
import struct
import functools
import ctypes
from ctypes import c_float, c_char, c_int32

class vec3(ctypes.Structure):
    _pack_ = 4
    _fields_ = [
        ('x', c_float),
        ('y', c_float),
        ('z', c_float),
        ]

class acsVehicleInfo(ctypes.Structure):
    _pack_ = 4
    _fields_ = [
        ('carId', c_int32),
        ('driverName', c_char * 64),
        ('carModel', c_char * 64),
        ('speedMS', c_float),
        ('bestLapMS', c_int32),
        ('lapCount', c_int32),
        ('currentLapInvalid', c_int32),
        ('currentLapTimeMS', c_int32),
        ('lastLapTimeMS', c_int32),
        ('worldPosition', vec3),
        ('isCarInPitline', c_int32),
        ('isCarInPit', c_int32  ),
        ('carLeaderboardPosition', c_int32),
        ('carRealTimeLeaderboardPosition', c_int32),
        ('spLineLength', c_float),
        ('isConnected', c_int32),
        ('suspensionDamage', c_float * 4),
        ('engineLifeLeft', c_float),
        ('tyreInflation', c_float * 4),
    ]
      
class SPageFileSimHub(ctypes.Structure):
    _pack_ = 4
    _fields_ = [
        ('numVehicles', c_int32),
        ('focusVehicle', c_int32),
        ('serverName', c_char * 512),
        ('vehicleInfo', acsVehicleInfo * 128),
        ('acInstallPath', c_char * 512),
        ('isInternalMemoryModuleLoaded', c_int32),
        ('pluginVersion', c_char * 32)		
    ]

class SimHubShared:
    def __init__(self):
        self._acpmf_simhub = mmap.mmap(0, ctypes.sizeof(SPageFileSimHub),"acpmf_simhub_v2")
        self.simhub = SPageFileSimHub.from_buffer(self._acpmf_simhub)
              
    def close(self):
        self._acpmf_simhub.close()

    def __del__(self):
        self.close()
            
    def getsharedmem(self):
        return self.simhub
        

this is just the CrewChief plugin.

So the AC Shared Memory by default is actually lacking in many areas. Most of this extra plugin sets laptimes, positions, etc for the other cars competing.

simshmbridge sets this up, except I call it acpmf_crewchief.

If you look in the code, I think I even have some comments left over from when I was using SecondMonitor, where I create two copies of this data ( one called acpmf_secondmonitor ).

This sucks, because it means because it means anyone who wants to use CrewChief and SimHub simultaneously ( and any other app that renames this same identical plugin ), will have a separate copy of the same data for each app running a copy of this plugin.

Not the end of the world, we're talking kilobytes, just annoying for people like us.

I think if you edit the code in createsimshm.c and simshmbridge.c, and replace whereever I have acpmf_secondmonitor with acpmf_simhub, or whatever it's called, that should be what you need. Or atleast close to it.

if you look in the simapi project here you'll see essentially the identical struct.

edit: another method which might work... if you create a simlink in /dev/shm to /dev/shm/acpmf_crewchief, called whatever it needs to be called, I think simshmbridge will pick that up when you run acbridge.exe in your target wine prefix.