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.
This was caused by us setting `needsTerrainUpdate` to false during the shadow
pass in order to break out of the ForceChunkLoading loop (cause OF doesn't
update chunks during the shadow pass). However, this inadvertently caused the
chunk updates to be skipped during the normal pass as well if there didn't
happen to be another reasons for updating.
To fix this, we simply move the shadow pass check into the ForceChunkLoading
mixin and skip the entire loop during the shadow pass.
