MC-1347Items do not "update looks" when stacked on ground.
Stacked items on ground do not "update"
To reproduce: trow 2 or more items on the ground and make them stack. As you will see it looks like 1 block/item not more.
Environment
Java 7 update 7, Windows 7 Ultimate 64x
Linked Issues
Attachments1
Created Issue:
Items do not "update looks" when stacked on ground.
Stacked items on ground do not "update"
To reproduce: trow 2 or more items on the ground and make them stack. As you will see it looks like 1 block/item not more.Environment
Java 7 update 7, Windows 7 Ultimate 64x
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
relates to
x10A94 over on #mcdevs experienced a similar issue (albeit with a modded setup, when writing a proxy server). This ended up being this issue, and while we did not find an exact set of steps to reproduce on vanilla, we did find a way to consistently cause it in a modded case. The specific information is in logs #177 (starting at 2019-03-09 22:50:48) and #178.
This bug is a continuation of MC-11834, as it now behaves after 16w32a (the first 1.11 snapshot). Where before, "Item entity #### has no item" would have been logged, now the item is removed. This happens both clientside and serverside.
public void tick() { if (this.getItem().isEmpty()) { this.remove(); } else { // actual tick } }
I think the intent of this code is partially to reject invalid items (but the same thing exists in the NBT loading code...). However, this can also be hit if the item is ticked after it has spawned, but before the associated metadata has been sent. For whatever reason, the spawn object packet does not include entity metadata in it, despite the fact that the spawn mob packet does. This means that, to properly spawn an item entity, the game must first send a spawn object packet, and then immediately after that send an entity metadata packet to actually set the item.
However, if the metadata packet hasn't arrived yet, the item is initially empty. Before, this would have led to the item rendering as stone and the log receiving 1 message each time the item renders (I think, might be each time it ticks), since the game detected the empty case within getItem and returned stone explicitly (the same check to remove items actually existed then, but it would never trigger because of stone). Now, the item is just removed.
How can you actually get the spawn object packet without the metadata packet, given that they're always sent one after the other? Simple – latency or delay in processing! If one packet is sent over the network completely, but then you get some lag and the other one takes a little while to arrive, they'll still arrive in order... but there's enough time for the client to tick after the spawn packet is received but before the metadata one happens. It's a fairly simple race condition. This can be forced by manually adding some extra delay to the entity metadata packet (e.g. a Thread.sleep(200) call in SPacketEntityMetadata.processPacket), and it was confirmed that this could be reproduced consistently in the case of the proxy if the packet is always delayed. However, without such modifications, it's completely up to lag whether or not it will happen and it's likely to be very rare except for on a very bad connection. (The proxy case had it happen more frequently due to buffering, but that's out of scope).
The pickup animation
There is one other weirdness: the item pickup animation actually still works! This can be seen in a video (recorded with the proxy) at around 15 seconds in. Note that for normal drops, the "All" value on F3 goes to 4 and then back to 3 when it's collected (and P is 1 in the collect animation), but for the missing item, All does not change while P still does. To understand why this is weird, recall that the collect item packet uses entity IDs; it doesn't send a complete copy of the item but instead assumes that the client already has a reference to the item. Also note that internally, the item pickup animation is a particle, hence the P value.
What's happening there is that the item's own call to remove doesn't fully remove it. It instead sets the removed flag to true, which is processed in World.tickEntities:
public void tickEntities() { // ... all sorts of stuff ... this.profiler.endStartSection("regular"); for (int i1 = 0; i1 < this.loadedEntityList.size(); ++i1) { Entity entity2 = this.loadedEntityList.get(i1); // ... ticking and riding stuff this.profiler.startSection("remove"); if (entity2.removed) { int l1 = entity2.chunkCoordX; int i2 = entity2.chunkCoordZ; if (entity2.addedToChunk && this.isChunkLoaded(l1, i2, true)) { this.getChunk(l1, i2).removeEntity(entity2); } this.loadedEntityList.remove(i1--); this.onEntityRemoved(entity2); } this.profiler.endSection(); } // ... all sorts of stuff ... }
This includes a call to onEntityRemoved, which for WorldClient is this:
protected void onEntityRemoved(Entity entityIn) { super.onEntityRemoved(entityIn); // Responsible for notifying IWorldEventListener instances if (this.entityList.contains(entityIn)) { if (entityIn.isAlive()) { // i.e. !entityIn.removed this.entitySpawnQueue.add(entityIn); // This seems odd, but it won't apply here so pretend it doesn't exist } else { this.entityList.remove(entityIn); } } }
This removes the item from WorldClient.entityList (appears in crash reports as "Forced entities", at least until 1.14) and World.loadedEntityList (which controls the All value in F3), and also the chunk. However, it doesn't touch World.entitiesById, and that's what the collect item effect uses. The fact that an entity can be left in one of these collections seems a bit broken (it's a bit of a memory leak if it could happen in actual cases) but I'm not sure what really should be done about it or if other things are affected. I also don't know if that leak still exists in 1.14; I've seen that the entity lists are different.
Fix and a bit more history
The fix is rather simple: just include entity metadata in the spawn object packet, like with spawn mob. This would make it impossible for the entity to exist before the metadata has been received (if something breaks up in the middle of the packet, the game will wait for the full packet to be received). Given that 1.14 already did some cleanup of the spawn object packet, it would make sense to clean up more of the weirdness here.
Funilly enough, this wasn't an issue in the distant past; there originally was a distinct spawn dropped item packet that included the item in it. This was changed to entity metadata circa 1.4.6 (actually 12w50a), presumably so that information about the item could be changed after it was spawned (e.g. MC-1347). This was also when the "Item entity #### has no item?!" logging and returning of stone were added, as well as the remove check that wouldn't have been – my guess is that empty items would rarely cause crashes before those checks were added and the checks were added to attempt to sidestep things that were hard to reproduce.
SpaghettiGoat, the issue you're experiencing is presumably something else – possibly MC-90683 but I'm not 100% sure.
Thats intended.
While intended I think it would make sense if the icon of the single entity changed to indicate it contains multiple items instead of just the one.
I don't think i'ts intended because if you throw a stack of cobblestone then it shows as more, and not if they stack while being on ground.
Confirmed in 1.4.5.
The stack on the left was thrown as a stack, but the items in the stack on the right were thrown individually and autostacked. Notice that there are visibly multiple blocks on the left.
Fixed as of 12w50a.