Shared Memory API

Remember, we are driver, engineer and team-leader ourselfes. we do not need anything that demands a click or a wipe here and there during race. XD-Tool is a great enrichment of the racing experience for example when it becomes necessary to save fuel and tires, things a race engineer would tell you.
If I may, I would suggest to find a way to make shared data available to xdtool

 

Hi guys,

We are updating our shared memory api and it will break all the implementations done using the current version.

We were going to add local and angular velocity. While we could add it without breaking it, it meant maintaining the messy structure, so we decided that it's time we tidy up our shared memory api overall by grouping them better. And we are renaming it as well so it's no longer called $Race$. We are also adding versioning for you guys to check against.

So we are moving things around a bit and it means that developers using our api will have to revise things after the update.

We'll try to provide more details but this is just a very early heads up. Please spread the word if you are part of a community of a certain application or if you know a developer using our api.

While we're looking into this area; let us know what you feel is missing from the shared memory and we'll see what we can do (No promises that they'll be in this update though).

 

That is great news! Looking forward to the updates

Thanks!

 

Just passed it on to the RS dash developer.

 

Nice! I'm really looking forward to this.
What I am missing is a flag whether a car is equipped with a DRS. Afaik there are only the flags drs_available and drs_engaged. Please correct me if I am wrong, but that is what i would like to see.

 

Great news indeed, gongo, thanks for tagging

Structure wise, I'd hope player/session data is kept separate from the entire field data. So one can fetch minimal amount of data.

 

@Sonat Ozturk would it be okay to share details in advance to patch?
Gives us more time to prepare as well as feedback on whether to make changes to the structures

 

Yes, early access to the changes would be really helpful

 

Silly question coming up: Does this mean that SimVibe probably won't work after the patch, until they update their stuff?

 

Indeed.

SimXperience is aware of the changes to come they are on touch with sector 3.

Update will be quick but of course not immediate

 

Take care with the charset for driver names guys. I think the actual encoding for Strings in the Raceroom shared memory is *always* UTF-8 (that is, the driver names and other Strings are written to shared memory as a sequence of bytes, and these bytes are the UTF-8 encoded representation of the String). The C# sample uses CharSet.Ansi for the struct, which is (I think) "platform default". For English versions of Windows this is generally Cp1252. All this means that you'll see weird characters in your driver names for drivers with some accented or other non-English letters in their names. Some will work but not all depending on whether that character is on the Cp1252 codepage (so it can be hard to debug it).

For my stuff I don't allow the struct to contain any Strings at all - I just leave the driver names, track names, etc as raw fixed-length byte arrays (this means i don't specify any CharSet on the struct at all). I then decode the byte array to a String at the point when I want to use it in my C# application code:

String decoded = Encoding.UTF8.GetString(someRawByteArray).TrimEnd('\0').Trim();

The TrimEnd('\0') at the end removes nulls (the string is a fixed length array, null terminated). The additional .Trim() call is there because of a reason that has long-since been overwritten in my brain

 

Thanks Viktor

 

Will there be an API on serverside aswell?

 

thanks for the data, though someone better check their "spaces" settings (tabs vs spaces + indentation width) as some files look rather messy

not sure how you intend to preserve backwards compatibility in future, but let's say you always insert new player/session... related things before "num_cars", or you grow the r3e_driver_data at the "end".

You could then encode the byte offset at which num_cars starts, and the "size" of the struct "r3e_driver_data". That way even someone running code with an "older" version, can still figure out where to find the data he "knows" to interpret.

r3e_int32 version_major;
r3e_int32 version_minor;
r3e_int32 all_player_offset; // offsetof(r3e_shared, num_cars)
r3e_int32 driver_data_size; // sizeof(r3e_driver_data)

minor upgrade means I can still find the data using the offset + stride, major version upgrade means you changed things in a non backwards compatible way, so people need to change their code fundamentally.

Maybe I am overthinking this, but given the number of external tools, and the long time of stability we enjoyed, it would make sense to account for this imo. And the fact that the "all player data" can be kept at the end of the section, means I can only grab a small copy of the memory if I care about the player foremost.

Appending to the very end for backwards compatibility is an option of course, but makes it "uglier" to deal with.

 

Actually, the idea with a "header" struct, that contains various version info plus some offsets might actually help increase readability.
If you define some logical sections, and have offsets to those in that header, you can add info to those sections as you see fit...
It might look easier to just define a bunch of structs that a being placed one after another, because their sizes will give away their offset, but that requires people to update every time you add stuff. Having offsets available in a header will make all 3rd party apps work in 2 years, even if they haven't updated them and you have added a million stuff in the mmf (provided you only add sections to the end of the header's list of sections, and only add data to the end of each section)
You could also go all-in and take a look at iRacings method (discard the yaml-stuff)... and I believe Bernie from SimXperience have made an adaptation of that, called OpenApi or something...