Persist hidden items in permission-based ender chest rows#1774
Merged
granny merged 8 commits intoMay 1, 2026
Conversation
- Use the full backing ender chest storage size when loading and saving ender chest contents. Permission-based ender chest rows still limit the visible/accessible container size, but hidden slots are now preserved in persistent player data. This prevents items in higher rows from being dropped from EnderItems when a player loses permissions such as `purpur.enderchest.rows.six`.
4 tasks
GoodrichDev
changed the title
granny
requested changes
Apr 22, 2026
granny
left a comment
granny
left a comment
Member
There was a problem hiding this comment.
Based on all the discussion around this change, I feel like it wouldn't hurt to put this behind a config option that's enabled by default. I'll make sure to include it in an announcement so that those who relied on the container size "deleting" data when the container resizes can still have that available to them. Persisting the data would be the default, since I agree that most people would expect it to persist.
Add a settings.blocks.ender_chest.preserve-hidden-items option to control the recent change that preserves permission-hidden ender chest rows. The option defaults to true, and disabling it restores the legacy behavior that trims saved contents to the visible row count.
Contributor
Author
|
I made the necessary changes @granny |
granny
changed the title
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
2 participants
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.
This fixes item loss with permission-based ender chest rows.Previously,PlayerEnderChestContainer#getContainerSize()returned the player’s currently permitted row count, and the ender chest load/save methods also used that value. If a player stored items in higher rows and later lost the corresponding permission, those hidden slots could be skipped during load/save and omitted from saved player data.This changes ender chest persistence to use the full backing container size while keeping the permission-limited size for access/UI behavior. Hidden rows remain inaccessible without permission, but their contents stay saved and become available again if the player regains the required permission.EDIT: This adds support for preserving ender chest contents in rows hidden by permission-based row limits.
Currently, when permission-based ender chest rows are enabled, reducing a player’s allowed row count also reduces the size used by ender chest load/save logic. As a result, slots outside the player’s current permission range are not retained. This change keeps the existing permission-based access behavior intact: players can only view and interact with rows they currently have permission for. The new behavior is that hidden rows remain part of the backing storage during persistence, so their contents can be retained and become available again if the player regains the required row permission.
@/BillyGalbreath says this is not a bug and is working as intended, asked if it instead it could be intended to work this way. Hence the strike-through and rename