Johni0702
commented
5 years ago IIRC initially the file format version was intended to mark hard breaks in compatibility between the way the replay was encoded (e.g. in version 0 the recording player entity gets lots of special treatment during replay whereas in version 1 that has been changed to already happen during recording). Since a different protocol version was a hard break in compatibility as well (at least before support for ViaVersion was added), I just went with the easiest solution and incremented the file format version on every protocol version change.
I do agree that storing the protocol version itself would have been the sane solution and I'm totally in favor of changing the current scheme. Here's the plan:
- Starting with file format version 13, the
protocolkey is mandatory - The file format version shall only be changed if there's a backwards incompatible change in the mcpr format and not just the Minecraft protocol
- If there's a change in the Minecraft protocol which could result in incompatible ways of encoding replays for the same protocol version (examples from history: change in the packet header, adding per-packet compression, login phase changes, change in forge handshake, etc.), an issue shall be opened on this repo (if there are no objections or responses to such an issue within a week, the solution is deemed accepted and subsequently changing it will require a change in the file format version). One instance of where this is very like to come up is the 1.13 Forge handshake (if one is using Forge).
- Any version below 10 is treated as it currently is (i.e. mapping to protocol version as per this table) and newly generated replays (as long as they're compatible) should still use the old version to maintain compatibility.
- File format version 10, 11, and 12 are to be treated 13 (assuming you've included the
protocolkey for all of them, this will allow replays recorded with your plugin to work with future RM versions). If they are missing theprotocolkey, treat them as an unknown file format version (probably created by some other 3rd party and who knows what's in there) - RM will never produce replays with version 10, 11 or 12 but will still be able to play them (assuming ViaVersion supports it) and will use 13+
protocolfor new 1.13.2 replays.
Would this work for you?
Gerrygames
Using the Minecraft protocol version to identify which version a replay was recorded in, would be way more definite than using a "random" file format version. Why is the file format version random? The Replay Mod isn't the only software using the mcpr file format. So it's possible that some different software is recording replays in versions which the Replay Mod doesn't exist for (yet). For example my replay recording software for Spigot servers supports all versions from 1.8-1.13.2. The file format version I am writing to the mcpr files recorded in 1.13.x is just a guess. 1.13 uses the file format version 10, 1.13.1 uses 11 and 1.13.2 uses 12. But the Replay Mod will (most likely) not be released for 1.13 nor 1.13.1 and the file format version used in the Replay Mod 1.13.2 will (most likely) be 10. I think you get why this is random/not definite. Using the Minecraft protocol version on the other hand would be definite and much easier to handle. I am using the Minecraft protocol version in my replay recorder and server/player. The field in the json data is an int named
protocol. It would be nice if this could be named the same way if this request would be accepted. Reading replay files with the old specification wouldn't be an issue, just use the old file format version if the protocol field isn't present. I don't know how much would have to be changed for this, but I think this would improve the file format.