0/10, would not recommend. Though increasingly feeling that about
modding as a whole — really not feeling as emotionally rewarding as it
once did.
Server-side changes are well, not simple, but relatively straightforward:
- Block removal code is now called before the BE is removed, not after.
- Monitors now need to track if they've being removed or not again.
- Turtle drop consuming code no longer tries to insert items into
the turtle immediately, instead waiting 'til the action is
complete. Otherwise if the turtle gets destroyed mid-action
(e.g. the block explodes), then it tries to insert its drops into
itself!
We previously guarded against this by checking if the turtle BE had
been removed, but obviously this no longer works, so just easier to
shift the insertion.
- The interface for reading/writing NBT has been overhauled. It has
native "getOr" and codec support (nice!) but also has been changed
again in the latest snapshot (less nice!).
- The dye item component no longer has a "hide tooltip" flag. We now
hide the tooltip with a default component instead.
- Related to the above, we can now do all the tooltip-related things we
needed to do with vanilla's TooltipProvider. This did require
splitting NonNegativeId into subclasses for disk/computer, but
otherwise is quite nice.
- Some changes to model datagen. Annoying, but boring.
- Game tests got a complete overhaul. I'm keeping the interface the
same for now (@GameTest), because I'm blowed if I'm datagenning test
instances :p. If it's any consolation, both NF and Fabric are doing
this too.
Client changes are a bit more involved though:
- VertexBuffer has been entirely removed. We now construct the
GpuBuffer directly.
- BakedModel is gone! Oh this caused so much suffering for turtle
models. I ended up rewriting the whole system in processes (which
then involved PRs to NF and Fabric). Rather than returning a
TransformedModel, turtle models are now responsible for rendering the
model.
This may see another rewrite in the future. I'd like to switch to
JSON-based turtle models (like item models), but that's blocked on
some changes to NF right now.
Sorry to all add-on devs, I know this is a big change.
Please don't talk to me about this. The first couple of hours of this
update were quite enjoyable, and then the rest was one of the most
miserable times I've had modding.
This has been a real slog, partly due to some large MC changes (item
models are a great change, but a pain to adapt to), and partly due to
mental health reasons — honestly, I've opened up my IDE so many times,
and then just closed it because I've hated the thought of even working
on this.
I will publish this to my maven, so mod authors can depend on it, but I
have no plans to publish a 1.21.4 version. 1.21.5 is right around the
corner (again, with some cool, but no-doubt painful changes), and I
need some time to focus on some breaking changes.
This commit actually includes the 1.21.3 update — the git history got so
messy here, so I just clobbered the whole thing. Sorry.
== Rendering ==
- Remove TBO monitor renderer: There was a big overhaul to how shaders
are defined and loaded in 1.21.2. It might have been possible to
update the monitor shader code to this version, it doesn't see much
use nowadays, so let's just delete it.
This is a real shame — the TBO renderer was one of my favourite
projects I've worked on. Unfortunately, it just doesn't seem worth
the ongoing maintenance burden. It lives on in the standalone
emulator :D.
- Similarly, the VBO rendering code got a bit of an overhaul. We no
longer use a custom VBO subclass, and instead just hack vanilla's to
support changing the number of vertices rendered.
This does mean we need to construct a MeshData, rather than a raw
ByteBuffer. This isn't too hard, but not sure how it'll play with
Iris. Given recent vanilla performance improvements, maybe we can
remove our Unsafe code and use a normal BufferBuilder now.
- Remove our custom emissive model code, now that vanilla supports
it. We should add emissive textures to some other models at some
point.
- Remove mod-loader specific model code, and replace it with vanilla's
ItemModel. This does constrain the design of turtle upgrade modellers
quite a bit — we now only accept an untransformed BakedModel or a
transformed ItemStack model. We may relax this in the future,
unclear.
This change does mean that updsidedown turtles are broken. RIP :(.
- Entity rendering now separates reading state from the entity from
actual rendering. This means we need to pass some extra state around
for item frames. Easy on Forge, but requires a mixin on Fabric.
== Recipes ==
There were several major changes to ingredients this update. The code
here hasn't been very well tested right now — might be nice to add some
game tests for this.
- Ingredients can no longer be constructed directly from a tag key (it
needs to be fetched from the current registries), so the recipe
generation code needs a bit of a reshuffle.
- DiskRecipe now accepts a custom list of ingredients, rather than
being hard-coded (fixes#1755). Recipes can now return custom
`RecipeDisplay`s used to show a recipe in the crafting book. We use
this to replace the impostor recipes.
I'm not entirely sure how well this'll play with other recipe
mods. Here's hoping.
- Similarly, our recipe mod integration has been updated to use
RecipeDisplay. We had to do this as ingredients no longer accept
arbitrary ItemStacks (only a specific item).
== Misc ==
- Blocks/items now need to know their ID ahead of time (so they can
compute their description). This requires some reshuffling to the
registration code, but it's pretty minor.
- updateShape and neighborChanged no longer take a direction (the
Orientation is mostly null) and so invalidates all redstone and
peripherals.
- All the positions were lowered by one in game tests. It's a good
change (they now match the positions in structures), but annoying to
update for!
Ever since 1.17, turtle and pocket upgrades have been loaded from
datpacks, rather than being hard-coded in Java. However, upgrades have
always been stored in our own registry-like structure, rather than using
vanilla's registries.
This has become a bit of a problem with the introduction of components.
The upgrade components now hold the upgrade object (rather than just its
id), which means we need the upgrades to be available much earlier (e.g.
when reading recipes).
The easiest fix here is to store upgrades in proper registries instead.
This means that upgrades can no longer be reloaded (it requires a world
restart), but otherwise is much nicer:
- UpgradeData now stores a Holder<T> rather than a T.
- UpgradeSerialiser has been renamed to UpgradeType. This now just
provides a Codec<T>, rather than JSON and network reading/writing
functions.
- Upgrade classes no longer implement getUpgradeID(), but instead have
a getType() function, which returns the associated UpgradeType.
- Upgrades are now stored in turtle_upgrade (or pocket_upgrade) rather
than turtle_upgrades (or pocket_upgrades). This will break existing
datapacks, sorry!
Originally we exposed a single registerTurtleUpgradeModellermethod which
could be called from both Fabric (during a mod's client init) and Forge
(during FMLClientSetupEvent).
This was fine until we allowed upgrades to specify model dependencies,
which would then automatically loaded, as this means model loading now
depends on upgrade modellers being loaded. Unknown to me, this is not
guaranteed to be the case on Forge - mod setup happens at the same time
as resource reloading!
Unfortunately there's not really a salvageable way of fixing this with
the current API. Forge now uses a registration event-based system,
meaning we can guarantee all modellers are loaded before models are
baked.
Jonathan Coates