This bug was introduced when we started to record the login phase because it
contains the UUID of the local player. In the replay case this will be the UUID
of the camera entity but also the one of the recording player, so if the
recording player despawns while it is being spectated (e.g. because of a
backwards jump), then the camera snaps onto itself and gets stuck in place until
one presses Shift.
In particular, we now position it relative to the realms (fallback to
multiplayer) button.
This removes the need for special-casing ModMenu and fixes compatibility with
Better Mod Button.
The texture of this button is based on the settings button of the ModMenu mod
and was originally under the MIT license "Copyright (c) 2018-2020 Prospector".
The derived version is licensed as any other file in this repository.
Previously pressing F1 while the replay gui is focused (i.e. while the mouse is
visible) would toggle the global hudHidden state.
Now it only toggles the hidden state for the replay itself, allowing the
remainder to still be recorded with e.g. OBS where a full render isn't needed.
Basically the result of the Delombok function, except we use IntelliJ's equals,
hashCode and toString and don't re-organize imports (cause that breaks the
preprocessor) and a bunch of manual cleanup was necessary (and half the classes
weren't even converted).
This fixes both, replay-exclusive keybindings blocking vanilla ones as well as
vanilla keybindings blocking replay-exclusive ones.
The magic happens in Mixin_ContextualKeyBindings.
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.
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.
