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 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.
Since MC provides no reliable way to get the connection while still in the login
phase, Fabric API tries to determine it either from MinecraftClient's connection
field (for the integrated server) or from the ConnectScreen (for multiplayer).
However, neither is present during a replay, leading to the aforementioned
error.
To fix this, we store our ClientConnection in MinecraftClient's connection
field. This should have no significant effect on vanilla behavior.
Also remove the dead Forge 1.14 code which was in the same place.
That is, most of the business code should not be aware that it is being compiled
to multiple versions even when it heavily interacts with MC, preprocessor
statements should be an escape hatch, not the norm.
Similarly, code should not be forced to do `MCVer.getWindow(mc)` instead of the
much more intuitive `mc.getWindow()`, and a new preprocessor (technically remap)
feature makes this possible by defining "search and replace"-like patterns (but
smarter in that they are type-aware) in one or more central places (the
"Patterns.java" files) which then are applied all over the code base.
In a way, this is another step in the automatic back-porting process where
preprocessor statements are used when we cannot yet do something automatically.
Previously we "merely" automatically converted between different mapping, this
new feature now also allows us to automatically perform simple refactoring
tasks like changing field access to a getter+setter (e.g. `mc.getWindow()`), or
changing how a method is called (e.g. `BufferBuilder.begin`), or changing a
method call chain (e.g. `dispatcher.camera.getYaw()`), or most other
search-and-replace-like changes and any combination of those.
The only major limitation is that the replacement itself is not smart, so
arguments must be kept in same order (or be temporarily assigned to local
variables which then can be used in any order).
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 clears it scheduled tasks on disconnect. If we don't wait for
that to have happened on the async sender, then we might loose
some of the initial handshake packets (resulting in a dead lock in
fabric's registry syncing code).
The preprocessor should have complained about these but it didn't for
some reason. This commit isn't fixing any imminent bug, it's just
precautionary (and required to compile once the preprocessor is fixed).
While this commit also considerably simplifies/cleans the setup
method, the actual fix is that the networkManager is now added
to the channel pipeline with under the "packet_handler" key,
whereas before it was unnamed causing issues when transitioning
to the play state.