[SPIGOT-989] Item setPickupDelay() resets on Chunk unload/reload Created: 15/Jun/15  Updated: 29/Sep/15  Resolved: 29/Sep/15

Status: Resolved
Project: Spigot
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: SnowGears Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: delay, entity, item, pickup


 Description   

I was trying to make an item not able to be picked up with item.setPickupDelay(Integer.MAX_VALUE) and it works fine as long as the chunk remains loaded. But after testing, I found that if I fly away from the said item far enough that the chunk it resides in unloads, and I come back to it (reloading the chunk), the item is then able to be picked up. This is a bug because setPickupDelay(Integer.MAX_VALUE) should make the item not able to be picked up for approximately 3.4 years.

 Comments   
Comment by Blacky Paw [ 24/Jun/15 ]

In that case the fix I proposed in this pull request should work around this so nobody will have to figure this out ever again https://hub.spigotmc.org/stash/projects/SPIGOT/repos/craftbukkit/pull-requests/147/overview

Comment by SnowGears [ 23/Jun/15 ]

This works! (As far as I can tell)

Comment by Blacky Paw [ 21/Jun/15 ]

This issue might be caused due to an internal bit overflow. Minecraft will store the pickup delay as a short value internally. If you consider Integer.MAX_VALUE to have the following bit pattern:

01111111 11111111 11111111 11111111

This will convert to

11111111 11111111

when cast to a short value thus being equivalent to (-1).

The reason why it is fine as long as the chunk remains loaded is that the shortening cast will only occur inside the save / load mechanisms of the chunk and it will use an integer with its 32-bits whilst loaded.

As suggested here: http://minecraft.gamepedia.com/Chunk_format#Items, you might want to set the pickup delay to Short.MAX_VALUE as that should cause the item to never be able to be picked up at all.

I still do have to test these assumptions, though.

Generated at Mon Apr 21 21:46:28 UTC 2025 using Jira 10.3.5#10030005-sha1:190c783f2bd6c69cd5accdb70f97e48812a78d14.