Closed bbb0x closed 4 years ago
I haven't looked at this myself, but are you sure the strings aren't null terminated? In languages like c++ it is not necessary to clear the entire 64 byte array as long as there is a null terminator at the end of the current text. Check the raw byte array and see if it looks like this (using your example)
DMD P20
This is how the byte array looks (in C#) the very first time my program is receiving it (after I've swapped from the Honda to the DMD P20 in the game before). Index 15 and above are 0. I'm creating an instance of the Shared class in the same way the example does it.
Hi ! Make sure to only read the characters coming before the 0x0 in c++ or other low levels language that marks the end of the string and in this case it's the same. You will find similar behaviour in other games sharememory. Better always do it when you read strings in such conditions, it will keep you away from many issues.
You are right, I was able to fix it. My old C# function simply removed all "\0"s in the string. With my new one it is working now:
string str = Encoding.UTF8.GetString(bytes); str = str.Remove(str.IndexOf("\0")); return str;
Thanks for your help! :)
Hello,
all the names in the data stream can get corrupted if they change. For example the 64 byte array "Name" at the "DriverInfo" class (the name of the car).
In the last session I drove a "Honda Civic TCR". In the next session I changed to a "DMD P20" Suddenly, the Name array reads: "DMD P20vic TCR"
This behavior was still in place after multiple restarts of my program, leaving the only possible cause to Raceroom. The arrays fail to reset all indexes after the new car names' length to blank.
I also had numerous of other issues with the strings, I was not able to reproduce yet. One time half of the track name was missing and layoutID even returned -1.
I recommend using the indexes for now and obtaining the corresponding names from the r3e-data.json file.