1.37 Parsing Issues
Closed this issue · 2 comments
There are currently 2 issues with parsing on 1.37 replays.
TAGame.PRI_TA:ClientLoadoutsOnline
First, there is a change to an unknown of data in the very well named "ClientLoadoutOnlineThing". It is sometimes definitely a full Int32, and sometimes definitely a single bit.
For example, here is the full binary data for 2 TAGame.PRI_TA:ClientLoadoutsOnline properties from different replays:
1000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000101101001000000000000000000000000100010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000010110100100000000000000000000000
10001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000001011010010000000000000000000000 011000000000000000000000000000000 1000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000101101001000000000000000000000001100000000000000000000000000000
They are both exactly the same until the Int32/Bit data member, meaning the decision point must come from elsewhere. Here's an exploded version of the relevant data:
10001000 // "Thing" list count for first ClientLoadoutOnline
00000000 // "Thing" count #1
00000000 // "Thing" count #2
...
00000000 // "Thing" count #16
10000000 // "Thing" count #17
01011010010000000000000000000000 // 32 bits of who knows what
0 // This is simply "0" in this replay, but "01100000000000000000000000000000" in the other
0 // New trailing bit (Only seems to appears if there were any "Thing"s, but not fully nailed down yet)
10001000 // "Thing" list count for second ClientLoadoutOnline
... // Same data as first list
The " who knows what" data must be the key somehow, since that's the only real data in the whole thing.
ProjectX.GRI_X:Reservations / Engine.PlayerReplicationInfo:UniqueId
The UniqueId for PS4 players occasionally has an extra 8 bytes of data. The pseudocode format for a PS4 player now looks like:
Platform : byte
Username: String(16)
Unknown1: String(8) // possibly region info (???usps4)
Unknown2: Int64 // Always 1? (havent really checked)
Unknown3: Byte[8] // Doesnt always appear
PlayerNumber: Byte
Right now I have a hack that fairly reliably reads Unknown3 by peeking at the first byte. If It's a larger number, it cant be "PlayerNumber", so then Unknown3 is read. Otherwise it is skipped.
Others? Not sure yet since the above issues block full parsing.
In desperation I sent a PM to Psyonix_Cone. That's how stumped I am.
It's probably right in front of my face. :)
I got a reply! It makes sense! I wont be able to fully analyze and test until later. But for now:
this...
01011010010000000000000000000000 // 32 bits of who knows what
0 // This is simply "0" in this replay, but "01100000000000000000000000000000" in the other
0 // New trailing bit (Only seems to appears if there were any "Thing"s, but not fully nailed down yet)
... is really this:
0 ??
101101001000000000000000000000000 // attribute class index
// below changes and is conditional based on above
0/1 is color id >= 0
100000000000000000000000000000 // 31 bit color id if above was 1
The Ps4 id data is always there in new replays, just need to check version. I dunno, I was trying to figure it out at like 1am, cut me some slack. :) Apparently it uses the new version number added last patch.