The only thing we care about is the framebuffer size, cause that will differ
between game and progress gui rendering. The window size will be the same (real)
size for both.
This makes it work more like regular 360 mode and is generally more compatible
because it doesn't require the frustum culling workarounds which the GPU
solution needs.
In particular, this fixes frustum culling with newer sodium versions (which no
longer use the vanilla intersection checking method) and fixes the clouds on
modern Iris (which seems to be using a different shader program for clouds).
9c5dec8 Fix writing of empty chunk load packet on 1.8.x (fixes#636)
3d8573f Fix writing of respawn packet on 1.8.x
39a85f7 Fix exception when cache file has invalid gzip header (fixes#535)
Fixes an issue where the world border would move at normal speed when speeding up or slowing down the replay, and also at an incorrect speed when rendering the replay, causing it to get out of sync with the rest of the world.
Co-authored-by: Jonas Herzig <me@johni0702.de>
Should be more compatible with mods which replace the entire renderHand
method (thereby making our mixin non-applicable), at least as long as these mods
check `renderHand` as well (Iris explicitly does).
This will become important once #638 is fixed.
This fixes the rotation of already existing entities that just got sent to the
client. Those get spawned with their rotation, which we didn't capture. This
commit fixes that by initializing our tracked rotation to NaN and returning the
original rotation until the tracked one is initialized (we do it this way rather
than initializing during the spawn packet handling because there are many spawn
packets, especially with modded, and we cannot possibly inject into all of
them).
This does not fix the rotation of newly placed entities (cause they seem to get
spawned with 0/0 and then get teleported to their correct rotation). The
previous commit fixed that case by capturing the rotation from the teleport
packet.
This fixes the rotation of newly placed entities (cause they seem to get spawned
with 0/0 and then get teleported to their correct rotation, which we didn't
capture).
This does not fix the rotation of already existing entities that just got sent
to the client, those already get spawned with their rotation, which we don't yet
capture. The following commit fixes that.
By updating the shadow plugin used in ReplayStudio.
java.lang.IncompatibleClassChangeError: Inconsistent constant pool data in classfile for class com/replaymod/replaystudio/lib/viaversion/libs/kyori/adventure/text/Component. Method 'boolean lambda$static$0(com.replaymod.replaystudio.lib.viaversion.libs.kyori.adventure.text.Component, com.replaymod.replaystudio.lib.viaversion.libs.kyori.adventure.text.Component)' at index 1064 is CONSTANT_MethodRef and should be CONSTANT_InterfaceMethodRef
This code supposedly meant for recording when a player was eating/blocking was
never needed to begin with cause the server echos all data in DataTracker
anyway, and now it broke the riptide animation because that's part of the
living flags as well but wasn't considered here, i.e. unconditionally
overwritten.
Forge naming strikes again, there's two different `updateCameraAndRender` in
1.14.4 forge, which lead us to use `updateCameraAndRender` for the older version
as well even though our desired method had a different name back then.
The `yaw` value of non-client-players is constraint to [0; 360), so when that
boundary is crossed, the `renderYaw` starts interpolating to its goal the
incorrect way round (instead of crossing the 360 boundary as well).
To fix that, we now add the difference between the current `renderYaw` and the
desired one, modulo 360 (but with range (-180; 180]), to the current
`renderYaw`. That way we always take the short way round.
Additionally, because for rendering MC looks at the difference without modulo,
afterwards (and when a new `yaw` is set) we wrap the result around such that the
actual difference is always less than 180 and therefore rendered as intended.
