Repository navigation
Predict slot rules on the client's machine menu - #85
Merged
Merged
Conversation
The client's menu backed its slots with a blank ItemStackHandler, which accepts anything up to a full stack. So it predicted placing items in output slots, past slot limits and against filters, until the server corrected it. ClientMenuItems keeps the same contents, filled by vanilla's menu sync, but takes isItemValid and getSlotLimit from the client block entity's own screenItems(), which has the same roles, filters and limits on any ScreenHost. Its contents aren't read or changed. The server still decides, so a filter that depends on server-only state can still mispredict. screenItems() must now work on the client, which ScreenHost and the docs now say. The default screenDestinations already relied on it. The test machine gets an output slot, a filter and a limit, and the GUI smoke test checks them through a real client menu. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018zpP6ZrFjaGe477FvWAZKo
Collaborator
|
No comments -- waiting on CI, this is an excellent PR |
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 this is
A small fix to how the client predicts clicks in machine menus, and the first step towards the reservations design on #83. It has no reservations in it and doesn't need the processor.
The problem. The client's
MachineMenubacks its slots with a blanknew ItemStackHandler(count), which accepts anything up to a full stack. From the code, it predicts placing items in output slots, past slot limits and against filters, and the server then corrects it. I haven't watched that flicker happen in a running game.The fix.
ClientMenuItemsis the new client handler:isItemValid,getSlotLimit) come from the client block entity's ownscreenItems(), which has the same roles, filters and limits on anyScreenHost. Its contents aren't read or changed.The server still decides. A filter that depends on server-only state can still mispredict, and the server corrects it as it does today.
Review notes
screenItems()must now work on the client.ScreenHostanddocs/gui-screens.mdsay so. The defaultscreenDestinationsalready relied on it, but a host that overrides that and has no client storage would now fail when the menu asks about a slot.Countergets an output slot, a filter and a limit, because it had none, so the GUI smoke test can check them.Testing
./gradlew checkpasses locally, including all 19 game tests.clientMenuItemsis new and checks the handler against a realItemStorage.🤖 Generated with Claude Code