-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Description
Expected behavior
Setting a replacement item — even if it’s visually the same item — should result in the slot staying in sync between client and server, just as in vanilla or older Paper builds.
Observed/Actual behavior
The server correctly keeps the replacement item,
but the client removes it from the hotbar slot.
Re-opening the inventory or relogging shows the item again.
When using PlayerItemConsumeEvent#setReplacement(...) to restore or keep the consumed item,
the client and server can fall out of sync — the client thinks the item was consumed (slot visually empty),
while the server still keeps the item.
This happens even if the replacement is a cloned ItemStack with identical data and amount.
The only way to prevent the desync is to manually resend the slot or call updateInventory().
Before recent Paper changes (possibly around the “sendAllDataToRemote” adjustments),
this behavior did not occur.
Steps/models to reproduce
@Override
public void onEnable() {
Bukkit.getPluginManager().registerEvents(this, this);
}
@EventHandler
public void onConsume(PlayerItemConsumeEvent event) {
ItemStack item = event.getItem().clone();
if (!item.getType().equals(Material.COOKED_BEEF)) return;
event.setReplacement(item);
}
1. Hold a stack of cooked beef
2. Eat one
3. After eating, the item disappears visually
4. Re-login → item reappears (desync fixed client-side)
- Happens in 1.21.x (tested on Paper 1.21.8–1.21.10 builds)
- Cloning or reusing the same ItemStack instance both trigger the issue
- Calling updateInventory() or manually sending a SET_SLOT packet resolves the desync
- Possibly related to internal optimizations reducing unnecessary item copies
Plugin and Datapack List
only the test plugin shown above
Paper version
[12:40:41 INFO]: This server is running Paper version 1.21.8-60-main@29c8822 (2025-09-06T21:49:13Z) (Implementing API version 1.21.8-R0.1-SNAPSHOT)
Other
No response