Freeplay Replays cannot be parsed properly. about rrrocket HOT 17 CLOSED

Attach replay 🙏

from rrrocket.

freeplay100.txt

was originally freeplay100.replay, but github didn't like that file extension. It should have slightly over 100 replay ticks (~5 secs) inside of it.

Edit: This file does not launch in RL, but using the properly parsed info and rattletrap I was able to create a file that does launch in RL but has no frames.

from rrrocket.

Yeah the attached file has no frames.

from rrrocket.

Huh so this replay file is exported via bakkesmod ReplayWrapper, which does work for online games. Maybe this has to do with it being a locally hosted match?

Oddly enough this is the error for opening the replay in RL.

[12815.65] Warning: Warning, Failed to load 'Object Mutators.Mutators.Mutators.FreePlay.CarArchetype': Failed to find object 'Object Mutators.Mutators.Mutators.FreePlay.CarArchetype'

For the file that does launch in RL (hand translated json by me from rrrocket to rattletrap schema and then encoded into binary by rattletrap) it uses all the data that is parsed by rrrocket but does not crash.

Also the resulting encoded replay by rattletrap is smaller than the original (even though I actually added an attribute), so is there data that is not necessarily frames? Possibly relating to the car and the ball?

Edit: the working replay also contains the Object Mutators.Mutators.Mutators.FreePlay.CarArchetype.

from rrrocket.

I also was able to load a custom training replay directly in RL, but not parse it with rrrocket. probably unrelated though.

freeplay.txt

An error occurred: Unable to parse replay freeplay.replay: Error decoding frame: time is out of range: 0.000000000000000000000000000000000000070550647.  Context: on frame: 1, backtracking to frame 0, last new actor: (id: 0, nameId: 0, objId: 44, objName: GameInfo_TrainingEditor.GameInfo.GameInfo_TrainingEditor:GameReplicationInfoArchetype, initial trajectory: Trajectory { location: None, rotation: None })

from rrrocket.

Yeah probably unrelated. Training data is not widely supported.

from rrrocket.

Ok but is there a way to verify that all of the data was parsed into the json from the original replay file? Im not really that familiar with binary decoding or rust.

from rrrocket.

The number of frames that is parsed comes from the header property NumFrames. So if you believe that data is being left unparsed, start finding replays where NumFrames is an underestimate.

from rrrocket.

@nickbabcock this would be an impossible feat as all freeplay replays will have no network data. I plan on doing so investigation into finding out how to fake the network frames potentially. But I dont understand why/how rattletrap shrunk my replay then if I used all and extra info from rrrocket.

from rrrocket.

Ok I have found proof that not all the data is being parsed.
From the same freeplay instance, I saved a replay after 161 frames in-game and then again after 1269 frames in-game.
These files differ in size incredibly. 24,139 bytes and 44,155 bytes respectively.

If I then run these 2 files through rrrocket I get two json files that differ by only 4 lines.

"header_crc": 3417094112,
"header_crc": 2470397316,

"NumFrames": 161,
"NumFrames": 1269,

"content_size": 23233,
"content_size": 43249,

"content_crc": 789285730,
"content_crc": 187708403,

These 2 json files only differ by 914 bytes.

So unless I am misunderstanding. There must be more data not being parsed.

from rrrocket.

replays.zip

The two replay files ^

from rrrocket.

Are you able to attach replays that either Bakkes/CPPRP or rattletrap can parse?

EDIT: As the ones attach fail to parse in either

from rrrocket.

@nickbabcock unfortunately no tool I have found has been able to properly parse the file. Rattletrap checks object names, and freeplay contains unknown objects compared to normal matches, and CPPRP does not seem to have any docs on steps to install and run.

from rrrocket.

I looked into it a bit more and the reason why both replays have zero frames is that first frame encountered is an end frame as the time and delta are zero. An end frame causes the parser to disregard the rest (source code here). This is why you're not seeing a difference between the replays. The first frame being an end frame is odd, and parsing through this error yields a failure to parse due to a TeamWhite0 object, whether Bakkes and rattletrap errors stem from the same issue, I'm unsure. If this only effects training replays and other parsers can't handle them, I'm not in a huge rush to dive deeper at the moment.

from rrrocket.

That is fair. I appreciate the sleuthing. If I have the opportunity, I will try to modify boxcars or CPPRP to parse these.

from rrrocket.

@nickbabcock I was able to set up CPPRP, but it did not fail to parse in my case. Were you using CPPRPJSON in your tests? This may just be a serialization problem if so.

from rrrocket.

I'm going to close this, but if you see non-training replays that have this issue, let me know and I can re-investigate

from rrrocket.