No clue why `getResourceLocationForPlayerUUID` was implemented the way it was,
that commit dates back to 2015 (332c36a), but if the skin isn't loaded yet, it
won't load it, so sometimes it just won't show properly in first person and in
the Player Overview.
This commit just calls `AbstractClientPlayer.getSkinTexture` instead.
Unclear which MC versions are affected. At some point before 1.16.4 something
else was introduced which loads the skin for us, hence why modern versions were
not affected.
On my system, a single scroll tick results in 120 calls, which is fine for the
vanilla camera controller because it has a range of 2000, but the classic
controller only has a range of 36, making it impossible to select anything but
the extremes.
This commit changes the size of the range to match that of the vanilla controller.
That way we can simply use whatever version we want and aren't tied to the
version of lwjgl which MC provides.
This fixes the OpenEXR export on 1.19 crashing either due to the windows
workaround or due to differing lwjgl versions (depending on OS).
And also enables OpenEXR export on MC versions using lwjgl2 (1.12.2 and below).
Until now, recording worked by injecting right before the vanilla packet
handler. At that point it was receiving packet classes and had to re-encode them
to store them in the replay file. However, not all decoded packets can
necessarily be re-encoded without errors, requiring us to have a bunch of
workarounds.
This commit changes the way recording works by injecting right before the
decoder. It therefore receives the raw bytebufs and no longer has to deal with
the re-encode issue.
Terrain culling is only updated when the camera position or rotation changes.
For omnidirectional rendering, we don't change the camera directly though, we
rotate way earlier so we can consistently get before any other effects. As a
result, the terrain frustum culling wasn't updated between render passes
resulting in missing terrain.
This was largely masked by the fact that we used to call GameRenderer.onResize
every pass (even when the size hadn't changed) but fixing that made this issue
become apparent.
Instead of setting the the values via accessor and calling the handler directly.
This allows mods like ResolutionControl+ to properly resize its internal
framebuffers as well.
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)
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.
This reverts commit 411eaa4ca8.
The given solution does not work in old versions because those did not use
`getYaw` for hand rendering. Even worse, their headYaw does wrap around and it
does it in a different way than their yaw value, giving a worse result than
without this commit.
MC uses the client-side position of an entity to determine whether it is inside
the simulation range and therefore whether it will get ticked. For some (most)
entities it interpolates the client-side position to match the server-side one
inside of the tick method... no prices for guessing where this goes wrong.
Somewhat similar to the issue we have with chunk unloads which we work around in
FullReplaySender but worse cause they'll get stuck if they ever leave the sim
range even for a single tick, rather then just when their chunk is unloaded.
Previously we injected it as a regular builtin resource pack (like the
Programmer Art pack) and hid it on the resource pack screen but this is bad for
several reasons. The most significant one being that it can be re-ordered and
makes the resource pack list ordering weird if you don't know that there is an
invisible pack there.
It also unnecessarily messes with other mods which make certain assumptions
about configurable resource packs (e.g. EBE, though in that case, it merely
triggers an existing bug in EBE).
We now instead inject it into the final resource pack list which gets
constructed from the configured packs, but never as a configurable pack itself.
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).
Instead we now use the `headYaw` value, which does not wrap around and as such
does not have this issue.
Jonas Herzig