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.
This used to be more of an issue in the past but `displaySizeChanged` has gotten
pretty cheap by now and not updating it will basically make the rendering GUI
useless once you resize even once.
This field is used to decide whether or not to render the inside-block overlay,
as such we want it to be set while we're in spectator mode).
This wasn't a problem before 1.15 because we also cancel the renderHand call
while we're in spectator mode and the same method which renders your hand also
renders the overlay, so we were inadvertently canceling that at the same time.
With 1.15, that's still the case except when using OF, which splits the method
apart by adding three boolean arguments indicating which part to execute.
We used to remap the old language key layout for inputs to the one used by
fabric but didn't consider that we might still be directly referencing the old
key somewhere else (e.g. for the Player Overview title).
With this commit, we retain the original and add the new mapping.
This intentionally breaks the mixin in a development environment but makes the
compiled jar work in a live environment (which is probably more useful given the
primary version is 1.15 now).
The task queue is executed by MC each frame, not just each tick, so we should do
so as well. Most async actions also rely on it to re-synchronize with the
rendering thread, e.g. skins won't load if we never poll the task queue.
