I'm sure this was required at one point, but it seems to work now, and I
haven't spotted any obvious changes in NF's code, so not sure what is
going on. I have no complaints though!
- Move block and item ids into separate API-accessible classes, to
match vanilla.
- Switch to Fabric's built-in permission API. We no longer need to
optionally support fabric-permission-api, which makes things a bit
simpler.
- Lots of rendering changes. Crucially, switch monitor rendering back
to using VBOs, using the new FeatureRenderer system. This currently
requires mixins on Fabric, but there's a PR open to add an API for
it in the future.
- Replace vanilla-extract with Fabric Loom for common mod. Now that we
no longer have to worry about remapping, this probably makes more
sense.
- Switch turtle upgrades to use ItemStackTemplate. Yay, immutability! I
think I might change up the upgrade API here a bit, but not a blocker
for release.
- Lots of small things. I'm very glad for our game tests — these caught
a fair few bugs.
- Bump CC:T Javadoc version, to fix issues with dropping newlines when
converting to Markdown. I'd originally planned to switch to
Markdown-style Javadocs, but tooling is stil a bit lacking
(Intelli's formatting of @params is entirely broken for instance).
- Force more recent ASM version, to allow Forge to run.
If a fluid uses NBT tags, then when we construct our NBT-less
FluidStack, then the fluid does not match and will not be transferred.
Instead, we search the source tank for a matching FluidStack, and use
that directly.
This is a bit limiting if a tank contains multiple versions of the fluid
with different NBT, but hopefully that's not too common.
Fixes#2355
Post 1.21.1, MoreRed switched to using ExMachina[^1] for handling
bundled redstone connections, meaning our existing integration code
crashed. While the changes seem really cool, the documentation is
lacking, and I just haven't got the spoons to puzzle through it all. For
now, let's just remove support — PRs very much welcome to add it back!
Closes#2309
[^1]: https://github.com/Commoble/exmachina
90% just ResourceLocation → Identifier. Also:
- StandaloneModel now needs to detect which atlas to use, as the block
and item atlases are different.
- MultiLineLabel now always draws in white with a drop shadow, so we go
back to manual word-wrapping for now.
In 634cd52b60 we found out that NBT
hashing requires access to the current registries. However, passing that
around would have required an API change, so we just probed the current
server globally.
On 1.21.10 we can break the API, so let's do this properly:
- DetailRegistry/DetailProvider now take a HolderLookup.Provider as an
argument. I did debate whether non-basic details should use a
MinecraftServer for now, but that makes the API less uniform.
- This means our generic peripherals need access to the current server.
We also update the API to support registering
MinecraftServer->GenericSource factories
The server side changes are pretty straightforward:
- Level.isClientSide is now a method.
- NeoForge has switched to a Fabric-style item/fluid storage API. This
is a fairly simple migration, as we've got support for this already!
This does mean that we need a wrapper type here too. We really should
support generics in the generic method system :/.
Unfortunately, this is another rough update on the rendering front. The
main change here is that BE renderers now a) have separate extract/render
phases and b) "draw" to a scene graph (SubmitNodeCollector) rather than
directly.
- Update lectern models to use the model/layer system, rather than
constructing model parts directly. We don't *need* to do this, but
makes this a bit more consistent with vanilla.
- Remove TurtleUpgradeModel.renderForLevel. I could not figure out a way
to make this look nice with the separate extract/render phases. This
is made worse by the fact that CC:T doesn't actually use this
anywhere, so not sure what we actually need! Something to bring back
in the future, if other people need it.
- The turtle/monitor F3 info now uses vanilla's debug renderer system.
We could maybe make the monitor one use a gizmo in future updates, so
it renders coordinates in-world instead. Not sure.
Unfortunately, some bits are entirely broken right now:
- Breaking progress for turtles. There's no way to do custom breaking
progress, so we just render this as normal custom geometry, which has
all sorts of depth-buffer issues.
- Monitors do not use a VBO (again, no way to do this), and render every
frame. This means monitors are pretty slow to render right now (one or
two is fine, but monitor arrays are unusable). Will need to submit PRs
to the various mod loaders for this.
- Update to Loom 1.12. This requires Java 21, so we now build with Java
21, but targetting 17. The new "-release" flag does make this much
easier, so hopefully shouldn't cause too many issues.
- Bump versions of a lot of other things.
- Fix various errorprone/checkstyle grumbles.
Still one TODO left, but around data fixers, so fairly small.
- GUI rendering got a big overhaul. I avoided the worst of it with
9272e2efcd, but things like terminals
and printouts still require some custom rendering.
- Item models are now de-duplicated when rendering in the UI, so we
need to keep track of their identity with
(appendModelidentityElement). I'm not sure I've got this entirely
right — whole thing feels unfortunately error-prone.
- BE serialisation now goes through a Value{Input,Output} class, rather
than using NBT directly. Fairly simple change, but has changed the
format of the GameProfile used in turtle's owners. Need a DFU patch
for this.
- Move remaining sprites to the vanilla GUI atlas.
- Convert our computer border/sidebar sprites to use vanilla's
nine-sliced mcmeta files. I thought I'd have to do something custom
here for the sidebar, as that has no right border, but vanilla
supports that natively!
- Use the normal GuiGraphics.blitSprite for rendering computer
border/sidebar.
- Obey nine-slice scaling within the pocket computer renderer.
Back in f10e401aea, we changed turtle
overlays to be loaded as a dynamic registry. This solved some of the
problems we had with upgrades (elf-compatibility), and seemed like a
good idea at the time.
However, because overlays are part of datapacks (not resource packs), we
also needed support for loading overlay models, which we did via an
"extra_models.json" file.
With the ItemModel changes, we can go for a different approach:
- Turtle overlays are now stored on the item/BE as a simple
ResourceLocation again.
- The TurtleOverlay class is moved to the client, and loaded from
resource packs, during model loading. They're now split into a baked
form (holding a StandaloneModel) and an unbaked one (holding the
ResourceLocation).
- extra_model.json is no longer supported.
- Use new tooltip component registry. This means we can move the
tooltip appending magic to Neo only.
- Use new chunk level change event. I'm not actually sure if we need
this on recent versions (I can't reproduce the monitor update bug
that we introduced this to fix), but I've no clue what's changed here.
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.
Fixes#2141. Hah, I wrote some tests for this in
b03546a158, but they pass because hoppers
still support vanilla inventories, but turtles don't.
Wish NeoForge registered a fallback for any inventory, like Fabric does,
but there we go.
We have several items (e.g. ComputerItem), which only exist for their
custom tooltip implementation. We remove these, and replace them
vanilla-style component-based tooltips (TooltipProvider).
The implementation here is a little janky — as the vanilla list of
components is hard-coded, and neither mod loader offers a way to extend
it. For now we just use the generic mod-loader tooltip hook — this
probably would be easier with a mixin, but let's do things Properly.
It would be nice to fully remove DiskItem (we only keep this around for
doesSneakBypassUse), but that can be a future task.
- Remove the /computercraft-computer-folder client command, and replace
it with OPEN_FILE on NeoForge, or a /computercraft-open-folder
command on Fabric (which now accepts a path, rather than an id).
- Store command computer files in "computercraft/command_computer/<id>".
Fixes#1581.
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!
We now register these separately, rather than relying on the implicit
IMedia. This allows us to share a bit more logic between
PocketComputerItem and AbstractComputerItem. This doesn't make much
difference on 1.20.1, but does help a bit more on 1.21.1.
Now, hear me out, what if instead of having three @Nullable annotations,
we had *four*?
I've been wanting to switch away from javax.annoations for a while. The
library has been deprecated for ever and, unlike other @Nullable
annotations, the annotation is attached to the parameter/function
itself, rather than the type.
We use JSpecify rather than one of the alternatives (JetBrains,
CheckerFramework) mostly because it's what NullAway recommends. We keep
CheckerFramework around for @DefaultQualifier, and JB's for @Contract.
There are some ugly changes here — for instance, `@Nullable byte[]` is
replace by `byte @Nullable`, and `@Nullable ILuaMachine.Factory` is
`ILuaMachine.@Nullable Factory`. Ughr, I understand why, but it does not
spark joy :).
I removed this in fc834cd97f, way back in
late 2024. Looks like it's been updating in the meantime and I hadn't
noticed, so add it back.
I've simplified the code a little bit, to make use of our NeoForge's new
capability system, but otherwise it's almost exactly the same :D.
- Remove ContainerData.open.
- Change PlatformHelper.openMenu to take a separate display name and
MenuConstructor, rather than a MenuProvider. This makes the interface
slightly easier to use in the common case, where we want to use
lambdas instead.
- Check whether the computer is a command computer before registering
the capability.
- Add tests to check what is/isn't a peripheral. See also #2020, where
we forgot to register a peripheral on NeoForge 1.21.1.
Fixes#2070.
Jonathan Coates