Minecraft 1.21.2 added a mouseScroll override to
AbstractContainerScreen, which means that child widgets no longer
receive scroll events. We reimplement that logic in our computer screen.
Fixes#2245.
We use getLevel() specifically for reading the current registries
(and/or server). We don't need the exact position of the speaker to
query this, so add a dedicated method for it.
We actually had a similar method on 1.21.7 already for upgrades. This
just moves it to SpeakerPeripheral.
Fixes#2236.
- Remove unused MonitorRenderer. I'm sure this had been deleted
already, but apparently not!
- Add missing items to the changelog.
- Fix crash when clearing tests in a world.
- Bump Iris deps, to help with debugging #2229.
I don't love the implementation of this (see discussion in #2220), but
it's better than nothing. Wow, the editor really needs a bit of a
rewrite, the code is kinda messy.
Fixes#1396.
Still one TODO left, but around data fixers, so fairly small.
- GUI rendering got a big overhaul. I avoided the worst of it with
9272e2efcd5a13f1796609652c1739b9d91b73fe, 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.
I've been putting this off for a while, as I had issues in the past with
people using old Node versions (e.g. #1806), but it no long works on my
machine, so time to make the switch.
Also do a bit of a package update. Hit a rollup bug while doing this
(https://github.com/rollup/plugins/issues/1877), so holding that update
back for now.
In the 1.21.4 update (9277aa33e97456c94b5f7d1aa54e00e204a316dd), we
removed our DirectVertexBuffer class, and switched to vanilla's
VertexBuffer. This forced us to use MeshData and thus
ByteBufferBuilder instead of allocating the ByteBuffer ourselves.
One thing I'd missed with this is that Iris's text vertex sink API
requires us to allocate the whole buffer up-front and so the resulting
buffer has a limit of the *maximum* number of vertices rendered, not the
actual one.
This wasn't an issue on 1.21.4, as we didn't check this (I guess we just
silently rendered junk??), but for the 1.21.5 update
(a1df19667361601c7f37a71074ea7755ccc4019d) we added some extra
assertions here, which now fail on Iris.
Typically, the whole original change was is now entirely redundant, as
Vanilla has removed VertexBuffer entirely, and so we can/should work in
terms of raw ByteBuffers again.
Fixes#2219.
- 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 f10e401aeac0b141b230607f6c3347215f0093cc, 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.
