Properly handle 'result' type inventories #10732
Draft
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.
Partially replaces #7265. That PR still has some stuff that this PR won't address.
While this might seem invasive, the pattern is very straightforward and easy to implement across all "result" type inventories. The worst part about it is the "mirroring" of the NonNullList that is initially created to hold the stacks. We have to use the exact same list for every Menu created so that the container is shared across multiple menus. We don't want to replace the
Container
instances on each Menu, because eachContainer
instance created there has special logic specific to that menu, so instead we pass in the list of itemstacks from the created inventory.Tasks
Download the paperclip jar for this pull request: paper-10732.zip