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 fixes both, replay-exclusive keybindings blocking vanilla ones as well as
vanilla keybindings blocking replay-exclusive ones.
The magic happens in Mixin_ContextualKeyBindings.
Aside from being best practice, this is necessary for the recording CRC to be
written to the replay file (cause that only happens on close).
Also potentially fixes https://github.com/ReplayMod/ReplayMod/issues/144 though
that should already be covered by ZipReplayFile tracking and closing all of its
`OutputStream`s before saving.
We didn't used to do that because it would have required us to serialize and
then de-serialize as MCProtocolLib only to re-serialize each packet.
With ReplayStudio v2, we only have to convert to from MC's ByteBuf types to
ReplayStudio's ByteBuf (fairly trivial).
This also allows us to automatically make use of ReplayStudio's backwards
compatibility features: We didn't used to record the login phase pre-1.14 and we
still don't, so we now would have to inject a fake login packet (because we're
no longer generating legacy-version replay files) but ReplayOutputStream can
do that for us.
Without this commit, any pre-1.14 replays generated are unplayable due to the
missing LoginSuccess packet.
In the case of #118, this was resulting in the EntityTrackerUpdate packet (which
contains info on which skin layers should be visible) sometimes ending up before
the SpawnPlayer packet, hence the players outer skin layers being invisible at
the start of the recording.
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.
