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.
