Replay Mod (Fabric & Forge)

Replay Mod (Fabric & Forge)

787k Downloads

Incompatible with multiconnect

Justsnoopy30 opened this issue ยท 6 comments

commented

When joining a server on another version with multiconnect translating and ReplayMod recording, the log is spammed with UnsupportedOperationExceptions in the multiconnect protocol translation classes. Trying to open the replay once saved results in the game freezing.
latest.log

Edit: Replaymod doesn't even need to be recording, happens when ReplayMod is installed at all alongside multiconnect while protocol translating... now that's a bit of a problem, seems replaymod is still trying to get packet data without recording?

commented

seems replaymod is still trying to get packet data without recording?

You cannot just start a recording at any time, it always needs all preceding packets. So if there's the possibility for you to press the Start button, it has to be recording even if you haven't yet.
You can completely disable recording (which will then also remove the Start button) via the checkbox in the Singleplayer/Multiplayer screens (or the corresponding options in the settings).

commented

Oh I see, makes sense. Should I cross-post this issue on multiconnect's issue tracker?

commented

No, even though they could fix the errors in the log by implementing write for their packets, stuff will still break at a later point case the ReplayMod will assume that all the packets are for the current MC version and then subsequently fail to parse them during playback. So RM has to at the very least look at the actual handshake to determine the protocol version, rather than assuming that it can be derived from the MC version. And ideally it doesn't use ViaVersion to play back old replays (or replays recorded with multiconnect) but instead uses multiconnect for that as well (so you get stuff like sword blocking, etc.).

And the packet serialization should arguably be changed in RM as well. Currently it re-serializes the Packets to save them.
For singleplayer that's required because MC itself never serializes them, and just passes the actual Packet instances. For multiplayer however, it could instead also just save the bytes before they're de-serialized. And it probably should do that, cause there have even been some vanilla packets which don't properly re-serialize after being de-serialized, those have just been handled on a case-by-case basis till now.

Don't expect this to happen soon btw. While the changes themselves are rather simple, they are quite fundamental, so I'd like them to get tested a lot before making it into a release, i.e. at the earliest in version 2.7.

commented

Are there any plans to get this to work? It records fine for me, but fails to save instantly after leaving a server with:
20221029_11h57m22s_grim

I'd love to help but seems like due to #631 I am unable to compile RM.

commented

It looks like this incompatibility has been fixed from the MultiConnect side. At least I didn't notice any problems in ReplayMod when used together with the latest MultiConnect version.

commented

It looks like this incompatibility has been fixed from the MultiConnect side.

Yup, looks like the way MultiConnect works has been completely overhauled in Earthcomputer/multiconnect@8a8b128; it's now using ViaVersion under the hood and builds on top of it.
I have also landed the change I talked about in 2.6.6 (13ac8dc) because the issues of the old approach were getting extra annoying with Minecraft 1.19, may or may not have been sufficient too, I didn't test it at the time.