Unlink a minion's container when it is destroyed - #2
Open
Crispi2k24 wants to merge 2 commits into
Open
Crispi2k24 wants to merge 2 commits into
Crispi2k24 wants to merge 2 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
MinionRegistrykeeps a second chunk index, this one keyed by the position of a minion's linked container, maintained in the same three places as the existing minion index (register,replace,remove).findLinkedToChestanswers from that index instead of walking every minion.A new
MinionChestLinkControllerlistens for a container being broken, burnt, or blown up and clears the link on every minion pointing at it, telling the owner when they are online.Why
A chest link is stored as a position, and
MinionContext#linkedChestaccepts whateverContainercurrently sits there:Nothing cleared the link when the container was destroyed, so the position outlived the chest it referred to. Break the linked chest, put a furnace in the same spot, and the minion happily starts filling the furnace - a container the owner never linked and may not even own the contents of. The same happens with a dropper, a hopper, or a shulker box placed by someone else entirely.
Checking the block type on every deposit would not fix it: a furnace is a
Containertoo, so the deposit path cannot tell a replacement apart from the original. The link has to be dropped at the moment the container stops existing, which is what this does.The lookup goes through an index rather than a scan because the check runs on every broken block. A server with thousands of minions would otherwise pay for a full pass each time anyone mines anything.
Testing / notes
./gradlew buildpasses. Verified on a Purpur 26.2 server: breaking a linked chest clears the link and notifies the owner, a container placed in the same spot afterwards is ignored, and blowing the chest up with a creeper behaves the same. Unlinking and relinking by hand through the panel still works, and links survive a restart.Only the four events that actually remove a block are handled. A container taken out while its chunk is unloaded - a world edit, say - still leaves a stale position; catching that would need the link to remember what it pointed at, which felt like a separate change.