Rocket League Replays has one, it uses the work of ZorMonkey as the base, then I built on top of it. If I'm honest, I doubt there's a huge amount of motivation to work on a replay merger, the people who are interested in replay data are still trying to get more information about single replays, so there's unlikely to be much interest in something which is a fairly niche interest.

Yeah, there are only two that I know of: my janky one, and the one at rocketleaguereplays.com. They look like garbage because we cant just use the Rocket League assets, and even if we could rewriting their renderer from scratch isn't so fun. (Edit: I mean, they don't exactly look like garbage, but lets be honest, they're a long way from the real renderer )

I'm also thinking that a merged replay would just look like a hot mess. Unlike Trackmania where each car is working towards the same goal (the finish line), in Rocket League each car has a different focus - especially after the first kickoff. Watching the first kickoff might be interesting, but after that it'd just be a stadium full of cars

Psyonix-Cone wrote:Hi, cool project, hope I can be of help. The layout of the network data is designed for minimal data, not for user-friendly parsing so I don't envy you trying to get useful data out of it.

The first part of the file is MetaData, which includes a CRC check, some version information, and information about the replay that we use to show in the list of replays. You seem to have that part all figured out so I'll move on to the fun stuff.

The remainder of the file is stuff serialized in this order:- Array of strings for all of the levels that need to be loaded (array length followed by each string)- Array of Keyframe information used for timeline scrubbing (array length followed by each keyframe struct) (Time, Frame, File Position)- Array of bytes that is the bulk of the data. This is the raw network stream. (array length followed by a bunch of bytes)- Array of debugging logs (strings). This reminds me that I should probably turn these off to make the replays smaller. (array length followed by each string)- Array of information used to display the Tick marks in the replay (goal scores). (array length followed by each tick struct) (Type, Frame)- Array of strings of replicated Packages- Array of strings for the Object table. Whenever a persistent object gets referenced for the network stream its path gets added to this array. Then its index in this array is used in the network stream.- Array of strings for the Name table. "Names" are commonly used strings that get assigned an integer for use in the network stream.- Map of string, integer pairs for the Class Index Map. Whenever a class is used in the network stream it is given an integer id by this map.- "Class Net Cache Map" maps each replicated property in a class to an integer id used in the network stream.

The network stream is pretty much just the same data that the server sends to the client, so it does have some compression going on. This is not an overall compression, it is a per-property compression (such as vector compression for velocity, location)

The network data stream is a stream of network frames. Each frame is composed like this:- Current Time- Delta Time (since last frame)

- Data for actors that have stopped replicating (were destroyed), which is composed like this: - 1 bit to signal we are replicating another actor - compressed integer for the actor's network channel ID (max value is MaxChannels) - 1 bit to signal the channel is closing (actor was destroyed)

- Data for actors that have started replicating this frame (newly spawned), which is composed like this: - 1 bit to signal we are replicating another actor - compressed integer for the actor's network channel ID (max value is MaxChannels) - 1 bit to signal the channel is open - 1 bit to signal it is a new actor - Some data for how to reference the actor. If it's a static actor (placed in level), then this puts his integer ID from the object table. If it's a dynamic actor, it puts the integer id for his "archetype", along with optional initial location (vector) and rotation (3 bytes for pitch, yaw, roll). Not all actors need this initial location and rotation so not all actors serialize it.

- Finally property values for each replicating actor. We only serialize property values that have changed since the last frame, unless this is a keyframe in which we serialize all replicated properties. Composed like this: - 1 bit to signal we are replicating another actor - compressed integer for the actor's network channel ID (max value is MaxChannels) - 1 bit to signal the channel is open - 1 bit to signal it is not a new actor - A stream of properties and their values, composed like this: - 1 bit to signal we have another property - compressed property id (max value pulled from the Class Net Cache) - if the property is a static array, serialize the index we are replicated in the static array - The property's data. Whatever gets serialized here depends on the type of property. Ints, bytes, and strings are obvious. The less-obvious ones are structs, and particularly the rigid body state for each car and the ball, which is comprised of several compressed vectors and rotators. - 1 bit to signal we are done replicating properties

- Finally 1 bit to signal we are done replicating actors

I am Currently looking to find how long someone held the the jump button and what controls were pressed in the air... What is the best way to get this information when breaking down the replay file?

I am working with some people that currently want to break down replays and use them as training data for a neural network bot. Could you possibly point me in the right direction?