Item entities turn invisible when dropped on the ground

The first file "crash-2017-01-20_00.06.06-client.txt" is with the bug present in the form of an invisible partial stack of sugar. Two saddles were visible.

The second file "crash-2017-01-20_00.08.50-client.txt" is after the crash and a relog with all three entities visible.

If you search the first file for "sugar" nothing returns. However, if you search the second file it is there. This looks like the client actually does not register the entity at all. This appears to be a similar bug to crafting quickly from stacks of items left on the ground where they do not show in the crafting grid but when combined the server returns the proper end item from the crafting grid. I am not sure if this is a reported bug however.

I've been receiving this bug too. It is quite annoying, and I've attempted to solve it by changing my graphics settings, and by restarting my computer. Neither seemed to have any affect. It is worth mentioning that the current world is on Realms, and was previously a single player lan world which my friend started on with 1.8. However I don't think that would cause any issues because my previous world before this on Realms was started in 1.8 and didn't have any issues. It happens randomly while mining blocks or when dropping them. For example I'll be mining and some blocks will show the items while others won't.

I've attached a set of photos as an example, I mined 9 blocks of stone and didn't see anything on the ground, but when I walked over them I collected 9 cobblestone.

Edit: I've attached a crash report from my game

I'm experiencing this bug on 1.13. It's much more severe than when I reported it. In some locations, items thrown on the ground from inventory turn invisible roughly 50% of the time.

@unknown, please attach a current forced crash report after having this issue.
What I could see out of the crash report as of 2016, that your Minecraft ran out of memory:

Memory: 385125896 bytes (367 MB) / 1060372480 bytes (1011 MB) up to 1060372480 bytes (1011 MB)

This is happening to me very severely on a 1.13.2 server. Dropped items from broken blocks are invisible VERY often. It's especially annoying when collecting resources from the ocean floor, I have to blindly swim around all over the place to make sure I've collected everything.

I've also had instances of rideable mobs going invisible after dismounting until I relog onto the server. Not sure if that's related or not.

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.

EntityItem.java

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:

World.java

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:

WorldClient.java

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.

@unknown, the issue you're experiencing is presumably something else – possibly MC-90683 but I'm not 100% sure.

Is still still and issue as of 1.15 Pre-release 1 or later?

has this been resolved? because I see this bug a lot in 1.15.2

I don't think it's been fixed. I'll do a quick test to verify. 19w34a (1.15) removed the metadata field from spawn mob and spawn player, so theoretically other entities could be affected (though I don't think any other entities remove themselves if they're missing metadata).

i hope this gets fixed in the next patch

edit: no it did not.

I can't reproduce this in any version

it only started hapening when i updated to 1.16.3

Please try to provide repro steps.