Rather than handling right clicks within the block entity code, we now
handle it within the block. Turtles now handle the nametagging
behaviour themselves, rather than overriding canNameWithTag.
This fixes several issues with @Nullable fields not being checked. This
is great in principle, but a little annoying in practice as MC's
@Nullable annotations are sometimes a little overly strict -- we now
need to wrap a couple of things in assertNonNull checks.
Historically, computers tracked whether any world-visible state
(on/off/blinking, label and redstone outputs) had changed with a single
"has changed" flag. While this is simple to use, this has the curious
side effect of that term.setCursorBlink() or os.setComputerLabel() would
cause a block update!
This isn't really a problem in practice - it just means slightly more
block updates. However, the redstone propagation sometimes causes the
computer to invalidate/recheck peripherals, which masks several other
(yet unfixed) bugs.
While ComputerFamily is still useful, there's definitely some places
where it adds an extra layer of indirection. This commit attempts to
clean up some places where we no longer need it.
- Remove ComputerFamily from AbstractComputerBlock. The only place this
was needed is in TurtleBlock, and that can be replaced with normal
Minecraft explosion resistence!
- Pass in the fuel limit to the turtle block entity, rather than
deriving it from current family.
- The turtle BERs now derive their model from the turtle's item, rather
than the turtle's family.
- When creating upgrade/overlay recipes, use the item's name, rather
than {pocket,turtle}_family. This means we can drop getFamily() from
IComputerItem (it is still needed on to handle the UI).
- We replace IComputerItem.withFamily with a method to change to a
different item of the same type. ComputerUpgradeRecipe no longer
takes a family, and instead just uses the result's item.
- Computer blocks now use the normal Block.asItem() to find their
corresponding item, rather than looking it up via family.
The above means we can remove all the family-based XyzItem.create(...)
methods, which have always felt a little ugly.
We still need ComputerFamily for a couple of things:
- Permission checks for command computers.
- Checks for mouse/colour support in ServerComputer.
- UI textures.
- Remove ITurtleItem (and ITurtleBlockEntity): this was, AFAIK, mostly
a relic of the pre-1.13 code where we had multiple turtle items.
I do like the theory of abstracting everything out behind an
interface, but given there's only one concrete implementation, I'm
not convinced it's worth it right now.
- Remove TurtleItemFactory/PocketComputerItemFactory: we now prefer
calling the instance .create(...) method where we have the item
available (for instance upgrade recipes).
In the cases we don't (creating an item the first time round), we now
move the static .create(...) method to the actual item class.
This adds SPDX license headers to all source code files, following the
REUSE[1] specification. This does not include any asset files (such as
generated JSON files, or textures). While REUSE does support doing so
with ".license" files, for now we define these licences using the
.reuse/dep5 file.
[1]: https://reuse.software/
While it's a nice immersive interaction, it's far too easy to trigger by
accident. Dying/undying can now only be done via crafting and the
cauldron.
Closes#1321
- Document the thread safety of DetailRegistry a little better.
- Turtles now duplicate their inventory to the "previous
inventory" (now called inventorySnapshot) immediately, rather than
when the block is ticked.
This is slightly more resource intensive, but I don't think it's so
bad we need to worry.
- As this snapshot is now always up-to-date, we can read it from the
computer thread. Given the item is immutable, it's safe to read NBT
from it.
_Technically_ this is not safe under the Java memory model, but in
practice I don't think we'll observe the wrong value.
Closes#1306
Use `InteractionResult.sidedSuccess` / `.CONSUME` where applicable instead of `.SUCCESS`. This prevents the server from sending an additional swing animation packet to the client. Normally this isn't a problem, since the client will de-duplicate swing packets if they are within the animation duration of the currently playing swing; however, when connected to a server with a high ping the packet is sent after the animation is already finished on the client, resulting in a duplicate animation.
This commit got away from me, okay? No, I'm not proud of it either.
- Remove our overrides of handleUpdate tag: we now try to detect
whether we're on the client or server inside BlockEntity.load. Alas,
this is needed for Fabric.
- Remove BlockGeneric/TileGeneric entirely: we've slowly whittled this
down over the years, and nowadays we can get away with putting most
of its functionality into subclasses.
This allows us to do some nice things with overriding HorizontalBlock
(or our new HorizontalContainerBlock class), rather than
reimplementing functionality in each class. Though it would be nice
if Java had some sort of trait system :D:
- Simplify a lot of our container class so it's just defined in terms
of a NonNullList<ItemStack>. This also includes a total rewrite of
the disk drive which I'm not ... thrilled about. It ended up being
easier to copy the code from the mc-next branch :D:.
- Try to test some of the gnarly bits of this. Still a /lot/ more to be
done with testing this.
Closes#658
After several weeks of carefully arranging ribbons, we pull the string
and end up with, ... a bit of a messy bow. There were still some things
I'd missed.
- Split the mod into a common (vanilla-only) project and Forge-specific
project. This gives us room to add Fabric support later on.
- Split the project into main/client source sets. This is not currently
statically checked: we'll do that soon.
- Rename block/item/tile entities to use suffixes rather than prefixes.
Jonathan Coates