For one, the forge handshake takes place *after* login phase (but before the
JoinGame packet), so we must ensure that the SquashFilter does not reorder
those.
Secondly, we were ignoring the initial packet (timestamp = 0) in marker
processor when it should have been passed to the SquashFilter. This was not an
issue before cause the SquashFilter did not rely on it. Now however the
SquashFilter needs to be able to see a login phase packet, so it knows that the
following packets till the JoinGame packet are part of the forge handshake.
In ReplayStudio:
20b5183 Fix forge handshake being reordered to after the JoinGame packet
Also need to update ModMenu because the version we depended on still bundled the
snapshot FAPI and that was only fine because we overwrote it with our version.
MC stores server light data and only applies it during the next frame.
Therefore, if there is no frame between receiving the chunk and block changes in
it (like when jumping in replays), then the light update from the block change
gets lost.
This wasn't much of on issue because no tick events are fired normally while
paused. When seeking we do however manually run a tick for better result, and
this manual tick would cause this async sending code to run and seek wildly into
the future.
Aside from being best practice, this is necessary for the recording CRC to be
written to the replay file (cause that only happens on close).
Also potentially fixes https://github.com/ReplayMod/ReplayMod/issues/144 though
that should already be covered by ZipReplayFile tracking and closing all of its
`OutputStream`s before saving.
In particular:
- No longer generate any replays when auto-recording is off and recording is
never enabled from the ingame menu (fixes#138)
- Do not generate an additional empty replay file when recording was stopped in
ingame menu (fixes#147)
- only do squash if there are further output replays (fixes#142)
- Use the input file name as output file name even if there was a split (as long
as it's the only output file, e.g. because recording was never un-paused after
the split)
Similar to 3fedc22 in effect and cause. However tasks are executed, they just
cannot be submitted pre-1.14 because MC would continuously hold the lock on the
scheduledTasks queue for the entire renderVideo call.
We didn't used to do that because it would have required us to serialize and
then de-serialize as MCProtocolLib only to re-serialize each packet.
With ReplayStudio v2, we only have to convert to from MC's ByteBuf types to
ReplayStudio's ByteBuf (fairly trivial).
This also allows us to automatically make use of ReplayStudio's backwards
compatibility features: We didn't used to record the login phase pre-1.14 and we
still don't, so we now would have to inject a fake login packet (because we're
no longer generating legacy-version replay files) but ReplayOutputStream can
do that for us.
Without this commit, any pre-1.14 replays generated are unplayable due to the
missing LoginSuccess packet.
