server/session: Resend inventories on item release to keep the client in sync - #1281
Closed
root-nat wants to merge 1 commit into
Closed
server/session: Resend inventories on item release to keep the client in sync#1281root-nat wants to merge 1 commit into
root-nat wants to merge 1 commit into
Conversation
… in sync When a player releases an item such as a bow, the client predicts the result and, for example, decrements the arrow it expects to be consumed. If the server does not actually consume anything (the release is cancelled, the bow is not drawn long enough, or there are no arrows), it never corrected the client, leaving the displayed inventory out of sync with the server. Resend the inventories before handling the release in both release paths, mirroring what handleUseItemTransaction already does for item use. The existing slot updates from an actual consumption are still sent afterwards, so a successful shot ends up with the correct count either way. Fixes df-mc#1001. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
| // handleReleaseItemTransaction ... | ||
| func (h *InventoryTransactionHandler) handleReleaseItemTransaction(c Controllable) error { | ||
| func (h *InventoryTransactionHandler) handleReleaseItemTransaction(s *Session, c Controllable) error { | ||
| // The client predicts the result of releasing an item, such as an arrow being removed from the |
Collaborator
There was a problem hiding this comment.
this comment could be 1 line
| case protocol.PlayerActionStartItemUseOn: | ||
| // TODO: Properly utilize these actions. | ||
| case protocol.PlayerActionStopItemUseOn: | ||
| // The client predicts the result of releasing an item, such as an arrow being removed from |
Collaborator
There was a problem hiding this comment.
this comment could be 1 line
FDUTCH
reviewed
Jun 27, 2026
| // The client predicts the result of releasing an item, such as an arrow being removed from the | ||
| // inventory when a bow is fired. Resend the inventories so that the client stays in sync if the | ||
| // release does not actually consume the predicted items, for example when it is cancelled. | ||
| s.resendInventories() |
Contributor
There was a problem hiding this comment.
wrong logic, It won't fix anything, it will only make things worse...
FDUTCH
reviewed
Jun 27, 2026
| // the inventory when a bow is fired. Resend the inventories so that the client stays in sync | ||
| // if the release does not actually consume the predicted items, for example when it is | ||
| // cancelled. | ||
| s.resendInventories() |
Author
|
You're right — resending before the release was the wrong placement (it re-sends the pre-release inventory on every successful shot and relies on the slot update to re-correct it, causing a redundant resend and a one-frame flicker). Reworked in #1289: it now resyncs only when the release consumes nothing, and leaves successful shots to the existing inventory slot-change callback ( |
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
3 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.
When a player releases an item such as a bow, the client predicts the result and, for example, decrements the arrow it expects to be consumed. If the server does not actually consume anything (the release is cancelled, the bow is not drawn long enough, or there are no arrows), it never corrected the client, leaving the displayed inventory out of sync with the server.
The inventories are now resent before handling the release in both release paths, mirroring what
handleUseItemTransactionalready does for item use. The slot updates from an actual consumption are still sent afterwards, so a successful shot ends up with the correct count either way.Fixes #1001.
🤖 Generated with Claude Code