Skip to content

feat(session): open barrels, ender chests and shulker boxes - #155

Open
xRookieFight wants to merge 1 commit into
devfrom
feat/container-coverage
Open

feat(session): open barrels, ender chests and shulker boxes#155
xRookieFight wants to merge 1 commit into
devfrom
feat/container-coverage

Conversation

@xRookieFight

Copy link
Copy Markdown
Contributor

Description

Only a chest opened. Barrels, trapped chests, shulker boxes and ender chests were registered blocks that did nothing when clicked, and the storage path was written around the one block that worked.

  • A block that stores items now declares it once, through block.container_kind. Adding a container is a registration rather than another branch in the session.
  • Barrels, trapped chests and every shulker box colour open, store and drop their contents on break, on the same world-backed path the chest already used.
  • Ender chests store on the player instead of the block: every ender chest shows the same 27 slots, nothing drops when one is broken, and the contents save and load with the rest of the player data.
  • The session's open-container tracking carries what kind is open rather than just a position, so the read, write and release paths ask the kind instead of assuming a chest.

Related issue

Part of #130

Double chests are not in this PR. Pairing is not a server-side decision the client will follow: it reads pairx/pairz off the two chest block entities, and without writing those the client draws 27 slots however many the server offers - which would leave half a double chest unreachable. It needs chest block-entity data first.

Shulker boxes also still drop their contents like any other container rather than keeping them in the item, which needs item NBT round-tripping (#120).

Checklist

  • v -check . is clean
  • v test server/block, server/player, and the session inventory/items/blocks/place/break tests are green
  • Follows the conventions in AGENTS.md (OOP, pub/capitalized exports, no import cycles, minimal comments)
  • Cross-session gameplay state is only mutated on its owning world's actor thread (via world_call/wr.submit/WorldTx), never through a global Hub actor
  • No unrelated changes bundled in

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant