Two main interfaces are introduced:
- Container (chest, furnace, etc)
- MenuAccessor (includes Containers but also anvils, crafting tables etc. which are not containers)
Containers have inventories, locks, and everything from MenuAccessor
MenuAccessors have obstruction checks, and openToUnchecked() for plugins to use
I opted not to include precondition checks in openTo() because it's possible
to replicate those using the provided APIs if desired.
this could be used for a bunch of different things aside from double chests
since the DoubleChestInventory no longer references anything specific about chests,
I figured it was time to generalize this.
This reverts commit 1d2b52732e.
I hadn't considered that the likes of plugins and hoppers need to be
able to interact with double chest inventories as well as players.
If we were to move this logic to the Block side, we'd have to expose
APIs on the Chest block to get the correct inventory lazily. I'm not
sure I want to commit to having getInventory() on the block right now,
as we can't guarantee it's available (see problems around Campfire
inventory on the block).
Short term, it'll probably be better to just expose the logic in
block\Chest for deciding which side the inventories should be on.
this allows getting rid of several container window classes.
we should probably look into adding more info to the BlockInventoryWindow to make the type easier to identify, though.
now that holder is tracked by an ephemeral window, we can put whatever we like in there.
it already needs to locate the correct pair anyway to know the left/right for DoubleChestInventoryWindow, so we might as well use this logic for initializing the DoubleChestInventory itself too. The old logic in tile/Chest didn't work correctly.
this unblocks a variety of changes, such as positionless tiles, enhanced APIs on Blocks for inventories, and also eliminates a bunch of cyclic references within the core code.
linked to #5033
This commit completely revamps the way that blocks are represented in memory at runtime.
Instead of being represented by legacy Mojang block IDs and metadata, which are dated, limited and unchangeable, we now use custom PM block IDs, which are generated from VanillaBlocks.
This means we have full control of how they are assigned, which opens the doors to finally addressing inconsistencies like glazed terracotta, stripped logs handling, etc.
To represent state, BlockDataReader and BlockDataWriter have been introduced, and are used by blocks with state information to pack said information into a binary form that can be stored on a chunk at runtime.
Conceptually it's pretty similar to legacy metadata, but the actual format shares no resemblance whatsoever to legacy metadata, and is fully controlled by PM.
This means that the 'state data' may change in serialization format at any time, so it should **NOT** be stored on disk or in a config.
In the future, this will be improved using more auto-generated code and attributes, instead of hand-baked decodeState() and encodeState(). For now, this opens the gateway to a significant expansion of features.
It's not ideal, but it's a big step forwards.
fixes#4856fixes#458fixes#4529fixes#3299
Added API method Block::getSupportType(Facing) : SupportType
Added SupportType enum
fixes torch, lantern, door etc. placement on slabs and upside-down stairs
