Disk IDs and treasure disk colour were not being correctly converted.
This also adds several tests to ensure that these items are handled
correctly.
Closes#1934.
This adds a new mechanism for attaching additional objects to a
computer, allowing them to be queried by other mods. This is primarily
designed for mods which add external APIs, allowing them to add APIs
which depend on the computer's position or can interact with the turtle
inventory.
I will stress that the use-cases for custom APIs are few and far
between. Almost all the time a peripheral would be the better option,
and I am wary that this PR will encourage misuse of APIs. However, there
are some legitimate use-cases, and I think we should enable them.
- Add a new "ComputerComponent" class, and several built-in components
(for turtle, pocket and command computers).
- Add a method to `IComputerSystem` to read a component from the
computer. We also add methods to get the level and position of the
computer.
- Move all our existing APIs (built-in turtle, pocket, command) to use
the public API.
We don't actually use this functionality in other projects (e.g.
emulators). In fact the method to add new APIs only exists in the mod
itself!
We still need some mechanism to remove mounts when the computer is
shutdown. We add a new ApiLifecycle interface (with startup and
shutdown hooks), and use those in the ComputerSystem impl.
Oh, I hate the pocket computer code so much. Minecraft was really not
designed to attach this sort of behaviour to computers. This commit is
an attempt of cleaning this up[^1].
Firstly, we move the the pocket computer state (upgrades, light) out of
PocketServerComputer and into a new PocketBrain class. This now acts as
the sole source-of-truth, with all state being synced back to the
original item stack on the entity tick.
This also adds a new PocketHolder interface, which generalises over the
various types that can hold a pocket computer (players and item
entities right now, possibly lecterns in the future).
[^1]: I'd say simplifying, but this would be a lie.
- Update to latest NeoForge, fixing issues with config API changes.
Closes#1903.
- Update to latest Fabric, switching to the ender pearl conventional
tag, and new loot API.
In c8eadf4011 we marked our various modems
as "brittle", which ensures they do not pop-off computers when the whole
structure moves.
However, this still requires the modem to be glued — if the modem is
outside the superglue range, it will still pop off. We can fix it by
registering a special "attached check" for the various modem blocks,
which says that the modem should be moved when the adjacent block does.
Fixes#1913
- Add a new computercraft:turtle_overlay dynamic registry, which stores
turtle overlays. Turtle overlays are just a model id and an
(optional) boolean flag, which specifies whether this overlay is
compatible with the elf/christmas model.
- Change the computercraft:overlay component to accept a
Holder<TurtleOverlay> (instead of just a model ID). This accepts both
an overlay ID or an inline overlay object (e.g. you can do
cc:turtle_normal[computercraft:overlay={model:"foo"}].
- Update turtle model and BE rendering code to render both the overlay
and elf (if compatible). Fixes#1663.
- Ideally we'd automatically load all models listed in the overlay
registry. However, resource loading happens separately to datapacks,
so we can't link the two.
Instead, we add a new assets/computercraft/extra_models.json file
that lists any additional models that should be loaded and baked.
This file includes all built-in overlay models, but external resource
packs and/or mods can easily extend it.
The X scale factor should now be flipped. I'm not quite sure what in MC
has meant this should be changed, possibly the cameraOrientation matrix?
Fixes#1872
Due to the earlier commits, the only functionality this block entity
adds is to register the command API. This commit:
- Add the command API when constructing the ServerComputer instead.
This is not a good long-term solution (I think we need to make API
factories more powerful), but is sufficient for now.
- Replace usages of CommandComputerBlockEntity with a normal
ComputerBlockEntity.
- Move the command permisssion checks to a new
ComputerFamily.checkUsable method (from
CommandComputerBlockEntity and ViewComputerMenu). I don't feel great
about putting new functionality in ComputerFamily (trying to move
away from it), but I think this is fine for now.
- Use this method from within the computer menu and computer block, to
check whether computers can be interacted with.
- Remove ViewComputerMenu, as it now no longer needs any special
is-usable logic.
Historically we used to have separate menu types for computers and
pocket computers, as the screen had to be initialised with the correct
terminal size.
However, as of c49547b962 (which was
admittedly two years ago now), we have the terminal available when
constructing the screen, and so the code for the two is identical.
This change actually merges the two screens, replacing usages of the
pocket computer UI with the computer one.
API Changes:
- Minecraft had updated ModelResourceLocation to no longer inherit from
ResourceLocation.
To allow referencing both already baked models
(ModelResourceLocation) and loading new models (via ResourceLocation)
in turtle model loadders, we add a new "ModelLocation" class, that
acts as a union between the two.
I'm not entirely convinced by the design here, so might end up
changing again before a stable release.o
- Merge IMedia.getAudioTitle and IMedia.getAudio into a single
IMedia.getAudio method, which now returns a JukeboxSong rather than a
SoundEvent.
Other update notes:
- Minecraft had rewritten how buffers are managed again. This is a
fairly minor change for us (vertex -> addVertex, normal -> setNormal,
etc...), with the exception that you can no longer use
MultiBufferSource.immediate with the tesselator.
I've replaced this with GuiGraphics.bufferSource, which appears to be
fine, but worth keeping an eye on in case there's any odd render
state issues.
- Crafting now uses a CraftingInput (a list of items) rather than a
CraftingContainer, which allows us to simplify turtle crafting code.
Historically (and according to the docs) getAudioTitle returned "false"
when the drive was empty (or had invalid media), and "null" when the
disk had no item. This was accidentally changed in a later refactor --
this change fixes that behaviour.
Rather than having one single hard-coded recipe, we now have separate
recipes for printed pages and printed books. These recipes are defined
in terms of
- A list of ingredients (like shapeless recipes).
- A result item.
- An ingredient defining the acceptable page items (so printed page(s),
but not books). This cannot overlap with any of the main ingredients.
- The minimum number of printouts required.
We then override the shapeless recipe crafting logic to allow for
multiple printouts to appear.
It feels like it'd be nice to generalise this to a way of defining
shapeless recipes with variable-count ingredients (for instance, the
disk recipe could also be defined this way), but I don't think it's
worth it right now.
This solves some of the issues in #1755. Disk recipes have not been
changed yet.
- Update EMI and REI integration, and fix some issues with the upgrade
crafting hooks.
- Just use smooth stone for recipes, not #c:stone. We're mirroring
redstone's crafting recipes here.
- Some cleanup to printouts.
- Remote upgrade data generators - these can be replaced with the
standard registry data generators.
- Remove the API's PlatformHelper - we no longer have any
platform-specific code in the API.
Turtles currently read their textures from a single 128x128 sprite
sheet. Most of this texture is unused which means we end up wasting a
lot of the block texture atlas[^1].
This change splits up the turtle textures into individual 32x32
textures[^2], one for each side, and then an additional backpack
texture.
I'm very sorry to any resource pack artists out there. The
tools/update-resources.py script will update existing packs, but does
not (currently) handle non-standard resolutions.
[^1]: It used to be worse: https://github.com/dan200/ComputerCraft/issues/145
[^2]: Turtle textures are a bit weird, in that they mostly *look* 16x16,
but have some detail in places.
Turtle tools were not equippable, as we considered the stack enchanted
due to the item's base attribute modifiers. We now only check the
component patch for enchantments/attribute modifiers.
This also removes the craftItem property of tools - this hasn't worked
since we added support for enchanted tools!
Fixes#1810
Replace turtle_modem_{normal,advanced} with a single turtle_modem
upgrade (and likewise for pocket upgrades). This is slightly more
complex (we now need a custom codec), but I think is more idiomatic.
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!
