- 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.
This is slightly more accurate for long strings and comments. Note that
we still work a line at a time (and in a non-incremental manner), so
doesn't actaully support multi-line strings (#1396).
We do now treat goto as a keyword (fixes#1653). We don't currently
support labels — those *technically* aren't a token (`:: foo --[[ a
comment ]] ::` is a valid label!), but maybe we could special-case the
short `::foo::` form.
Apparently this has been broken since the file was created in
53546b9f57d9acaa4cdca14ae00eaf68ce8c50bd!? I'm sure I fixed this before,
but maybe that was a different but similar issue >_>.
Convert GLFW's key codes back to their actual key, and then use that
when checking keyboard shortcuts. We *don't* do this for the paste key,
just to be consistent with vanilla's behaviour.
Fixes#2207.
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.
This allows equipping pocket computers on both the back (as before) and
bottom of a pocket computer. The asymmetry is a little unfortunate here,
but makes some sense with the crafting recipe (above goes behind, below
goes on the bottom).
- Move some functionality from IPocketAccess into a PocketComputer
interface (and PocketComputerInternal) interface, used by the pocket
API.
IPocketAccess preserves the same interface as before. Unlike
ITurtleAccess, we /don't/ expose the PocketSide in the public API.
- Several pocket-computer methods (e.g. setUpgradeData, setColour) are
now required to be called on the main thread, and when the computer
is being held. This allows us to write back changes to the item
immediately, rather than the next time the item is ticked.
Sadly this doesn't actually remove the need for onCraftedPostProcess
as I'd originally hoped, but I think does make the code a little
simpler.
- Rename "computercraft:pocket_computer" component to
"computercraft:back_pocket_computer".
- And finally, support multiple upgrades on the pocket computer. This
is actually quite an easy change, just tedious — there's lots of
places to update!
Fixes#1406, and I think fixes#1148 — you can use a speaker to notify
you now.
Every few years I get confused about which side turtle upgrades go on
when crafting. The fact that it's flipped always throws me! Let's add a
comment to the recipe, and add some tests to reassure myself.
- 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.
Reverts 76968f2f28. We'd originally added
this to gather some numbers for #1580, with the hope that it would also
be useful for server admins. Sadly, it's not as accurate as I originally
hoped — the number sometimes goes down for unclear reasons (something to
do with the TLAB maybe??).
Closes#1739.
The main thing of note is Spotless, which also bumps the version of
Ktlint. I've been putting this off for a while[^1], as this changed a
bunch of formatting, and Spotless's (broken) caching was making it hard
to test. Ended up downloading ktlint and running it localy.
[^1]: 8204944b5f
- Actually set colour when constructing the brain.
- Sync it back after crafting, much like we do for upgrades (see
dcc74e15c7) for more details.
We should take a proper look at this on 1.21.4 and make these methods
main-thread only, so we can sync immediately.
Fixes#2157
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.
- Fix isValidClipboard always returning true.
- Fix characters >=128 being rejected. We changed the signature from a
byte to an int in 0f123b5efd, but
didn't update all call sites.
Valhalla cannot come soon enough. I would love to be able to have
(cheap) wrapper classes for some of these types.
See Zeus-guy's comments in #860.
Sort of closes#2125. I've really struggled to find a way to make it
clear that the information returned here is a snapshot of the current
item, and not a live view and/or proxy. Most wordings I've tried end up
feeling really clunky — given that this is a relatively rare
misunderstanding, let's not stress about this too much.
Oh dear. I'd originally set out to *remove* logic from DiskItem — we're
so close to being able to remove this item in 1.21! However, while
looking at this code, I realised I could remove the whole Forge-specific
doesSneakBypassUse.
We now remove the use hook on the block, and override useOn on the item.
Obvious in retrospect!
Oh. This is from ye olde days (it's one of the first PRs to CC[^1]!). In
pre-1.13 days, furnaces changing their lit state would replace the block
(creating a new BE) and then set back the old BE. CC wouldn't pick up
the second event, and so would continue to use the peripheral from the
first.
We don't really need this any more, for a couple of reasons:
a) Furnaces don't do this any more.
b) Peripherals are now refreshed on the next tick rather than
immediately.
c) Forge's capabilities have an explicit invalidate() hook already. This
technically only detects *removing* block entities, but I'm not sure
there's any cases where you add a block entity without also
triggering a block state change.
Ironically, the place we probably need this more is Fabric, where the
lookup API doesn't have a public invalidate hook (it's hidden away in
the BlockApiCache). I'm mostly relying on c) here, in that we just won't
see this happen in practice.
[^1]: https://github.com/dan200/ComputerCraft/pull/180
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.
Introduced by the previous commit — I'd made one of the checks too lax.
Add some tests for this, so it doesn't happen again, though this code
does get a complete rewrite in 1.21 anyway >_>.
