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.
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.
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.
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).
Removes the need for //#if statements on each and every event handler.
Instead we now always use the equivalent Callback and have one central 1.12.2
class which forwards Forge events to the callbacks.
This bug was introduced when we started to record the login phase because it
contains the UUID of the local player. In the replay case this will be the UUID
of the camera entity but also the one of the recording player, so if the
recording player despawns while it is being spectated (e.g. because of a
backwards jump), then the camera snaps onto itself and gets stuck in place until
one presses Shift.
Basically the result of the Delombok function, except we use IntelliJ's equals,
hashCode and toString and don't re-organize imports (cause that breaks the
preprocessor) and a bunch of manual cleanup was necessary (and half the classes
weren't even converted).
This field is used to decide whether or not to render the inside-block overlay,
as such we want it to be set while we're in spectator mode).
This wasn't a problem before 1.15 because we also cancel the renderHand call
while we're in spectator mode and the same method which renders your hand also
renders the overlay, so we were inadvertently canceling that at the same time.
With 1.15, that's still the case except when using OF, which splits the method
apart by adding three boolean arguments indicating which part to execute.
The new preprocessor version brings first-party support for fabric, in
particular for automatically fetching mappings loom and for
automatically remapping between MC versions via intermediary mappings.
This will come in handy when updating to 1.15.
It also supports automatic remapping between fabric and forge on the
same MC version (by going mcp<->srg<->mojang<->intermediary<->yarn).
Therefore this commit replaces the previous 1.13.2 (forge) subproject
with a 1.14.4-forge one. Instead of manually providing full mappings for
1.14.4-fabric to 1.13.2-forge and partial (classes) for 1.13.2-forge to
1.12.2-forge, we now only need partial (classes) for 1.12.2-forge to
1.14.4-forge and preprocessor will take care of the forge to fabric
step (in fact, our mapping file for that is currently completely empty).
In an attempt to write an IDE (IntelliJ) plugin for quicker and easier
working with the preprocessor (e.g. immediately mapping single files
from within the IDE, jumping between different versions for the same
file), the preprocessor gradle plugin declaration now requires you to
explicitly specify variables in the common.gradle and the overall
relationship between projects in the build.gradle (latter is required
anyway, so the plugin can know where it should map between forge and
fabric and which subprojects are which versions).
Since that necessitated some changes to the build.gradle file, I took
the opportunity to convert it to Kotlin. As such we now also use
Gradle's newer plugin-block with the pluginManagement-block instead of
manually declaring buildScript (not for the common.gradle though), which
imo is nicer anyway and comes with various advantages (see gradle docs).
There were also some remapping bugs fixed and some new ones
introduced (e.g. manually declared inner class mappings seem to no
longer function properly under certain conditions).
There's also support for remapping Kotlin now. Just saying.
