Because JitPack breaks Gradle variants so we get the Java 17 jar even
when we use the Java 8 variant.
This works for building via Gradle. However it does not work for usage
from IntelliJ, where you must currently publishToMavenLocal ReplayStudio
and then depend on that version. Still looking for a better solution
there.
This because with 1.20.6, MC will require outbound messages to reach its
handlers to switch between protocol versions. So we need our drop
handler two be at the very end of the write processing chain.
We've done this ourselves only because it was easier at the beginning.
However with 1.20.5, Minecraft's packet decoding became substantially
more sophisticated, to the point that it's probably a bad idea to try
to do it ourselves.
Additionally, getting the packet ids, which we require for identifying
the packets which we want to decode, has becomes significantly more
difficult too, and this way it's a simple instanceof check.
We've done this ourselves only because it was easier at the beginning.
However by now (and especially with 1.20.5), Minecraft's packet decoding
has become substantially more sophisticated, to the point that it's
probably a bad idea to try to do it ourselves.
This commit gives back that responsibility to Minecraft by adding the
standard decoder (and encoder because it's required for proper
connection state management on modern versions) to our channel pipeline,
changes the full and the quick replay sender to send raw `ByteBuf`s into
the front of the channel, and moves the posititon of the full replay
sender in the channel pipeline such that it can see and modify packets
after Minecraft has decoded them.
- Upgrade Gradle to 8.7
- Increase build daemon max memory to 8GB because archloom can compile a lot
more projects at the same time.
- Disable Minecraft 1.8 (not 1.8.9) because archloom fails to set up for that
95a7c07 Process PlayerPositionRotation packet in SquashFilter
603bdce Create dedicated class for PacketPlayerPositionRotation
88343aa Fix incorrect order of ViaVersion-emitted packets
9ebaa97 Fix 1.20 to 1.20.2 ViaVersion conversion
c490e9f Update ViaVersion
bcccb2c Fix Reconfigure packets not being filtered out
a0df6c9 Fix ConfigFinish being emitted before other config packets
a672023 Separate pre-join-game packets from login-phase packets
a70161c Emit Reconfigure packet when required
074d78d Separate "emit first" list from "login phase" list
20a3bf9 Reorder loginPhase and configurationPhase code
We recently bumped the fabric-api version there, and newer versions of the v0
api just delegate to the v1 one now, so we need to include that there as well.
We'll use it in 1.20 mixins.
Unclear what minimal fabric-loader version it requires, so in the interest of
keeping older versions compatible with OptiFabric (old versions of which aren't
compatible with the latest fabric-loader), we'll add it to 1.16.4+ only.
The `Timeline` type is mutable, so we need to create a copy before we pass it to
GuiKeyframeRepository because we don't want anything stored in there (or more
specifically in render queue which can also be added to from that gui) to be
affected by subsequent changes.
It's only required for legacy Optifine doesn't even apply any more as of 1.18,
so we can just disable it on modern versions so it doesn't spam the log.
The respawn packet re-creates the player entity, so we need to re-send its
armor (and technically also the riding and sleeping state, though that probably
wouldn't ever have caused issues in practice because a respawn will implicitly
reset those, unlike your inventory which is preserved).
Because on 1.11+ a `null` item stack is not something that should exist.
This then also allows us to compare item stacks by value rather than only by
reference, potentially saving a few redundant entity equipment update
packets (but more importantly, also allows us to store a copy instead of the
original, which will be important for the next commit).
We cannot filter this packet purely on the netty thread because our filter
depends on the current camera position (if it's too far, we do want to teleport
it closer) and accessing the camera is only safe from the main thread.
Previously the second part had not been considered which could lead to race
conditions where the camera may not yet exist on the netty thread at time of
handling. These appear to have gotten the wholly inappropriate "just put a null
check around it" treatment, but that means that the filter sometimes doesn't
work (hence the bug report).
This commit changes handling such that all access to `allowMovement` is always
done on the main thread and then moves the filtering there as well. And
therefore filtering should now work properly.
Sharing the temporary `row` and `rowSwap` buffers between different calls to the
processor is not safe because it will be used by multiple threads.
As a result some of the rows in the image could randomly get corrupted.
This commit gets rid of the cached buffers (the value of which questionable
anyway) and simply re-uses the same code which other processors use.
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.
Jonas Herzig