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.
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).
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.
That was never actually finished and we do not need to keep it around anymore.
Whether we add its successor once that is ready for production use remains to be
seen.
In particular, Iris updates its frame counter and timer in the outer method, so
if we only call the inner one, then its shadows and sky will not update
properly.
Since the render method also renders the GUI, we set the current screen to null
and cancel the HUD during rendering. MC also clears the depth before rendering
the HUD, which we don't want because it breaks the depth map export, so we
cancel that as well.
This also allows Vanilla post-processing (aka Super Secret Settings, aka Vanilla
Shaders) as well as entity outlines to function properly cause those are applied
in that method as well.
Should have done this a long time ago but better late than never.
Closes#321
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).
