Item entities turn invisible when dropped on the ground

Thank you for your report!
However, this issue has been temporarily closed as Awaiting Response.

We do not have enough information to find the cause of this issue.
Please force a crash by pressing F3 + C for 10 seconds while in-game and attach the crash report ([minecraft/crash-reports/crash-<DATE>-client.txt|http://hopper.minecraft.net/help/finding-minecraft-data-folder]) here.

Once attached, the report will be reopened automatically.

Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki

This is happening to me on a server. Do I need to create a crash report from my client, or from my server?

Just your client.

I triggered the bug when throwing a stack of string on the ground from my inventory. When I logged back in to the server after crashing the game, the string was visible on the ground in front of me.

Crash report attached. Please let me know if there's any other information you need.

This is easily reproduced in 1.11.2. If you open your inventory and drop an item, or stack of items by picking it up and dragging it off the inventory window it will behave as expected. However, if you CTRL-Q the items out of your inventory to the ground, normally stacked items will "disappear." To reproduce, CTRL-Q 5-6 items or stacks of items from your inventory (not hot bar slots) to the ground. Then exit inventory. Now walk over items to pick up again. Open inventory and quickly CTRL-Q them again. about 90% of the time one or more of the items will disappear from view. The items are still there just not being rendered. I suspect that the client does not have time to render the icon for the item before the next one is being ejected from inventory and so it is blank.

Some more information: Interestingly doing this with rockets, sword, bed, potion, food stack from my existing inventory failed every time (did it about 30 times to test). However, I had a stack of sugar and two saddles in a chest. When I picked those items from the chest, closed inventory, and then did the test as described above, it reproduced the bug easily. I was at y-level 40 and facing East, night time, light level 8 on solid blocks when I did these tests.

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.

Hi all, looks like the issue has been inactive for a few months, but I recently discovered this bug while running a paper server. The issue persists in spigot and vanilla, though the chance for an item being invisible seems to be much higher on paper and spigot than in vanilla–oftentimes, the first block dropped or broken upon loading into the world is rendered as normal, but subsequent drops become invisible while running on paper.

However, of note is reproducibility when connecting through either my local IP or through my public IP.

Steps to reproduce:

Preconditions:

1. 1. The server and client are running on the same machine.

   2. Using Java 15, with startup arguments: `java -Xms3G -Xmx8G -jar server.jar nogui`

   3. Client is running optifine, have not tried vanilla yet but I assume behavior will be similar.

   4. Port-forwarding and IP configuration is already set up properly in my router configuration–for reference, my pc is configured to be a set IP of 192.168.1.55 with my router forwarding port 25565 to this IP.

1. Start the server from a fresh world, with nothing changed (no server-ip set) – connect to localhost using client, and items will drop as normal when broken or dropped by the player. The server, as of now, should neither be accessible through 192.168.1.55 nor my public ip.

2. Now, stop the server, and input the appropriate server-ip into server.properties. Restart the server.

3. Connect to the server using the local IP, and block drops should behave normally.

4. Connect to the server using the public IP, and block drops and player item drops suddenly disappear as described in this issue.

I have confirmed that this is not an issue with my network, as I have done the exact same steps without precondition #1–meaning, the server is run by a different machine on the same network. The issue does not appear when connecting with that other machine's local IP or through the public IP (again, assuming proper network configuration with port-forwarding).

I don't know if this set of conditions is particular to me or if it's a wild goose-chase or not, but I hope this information may be helpful in solving this issue.

Edit: see later comment, this issue is only reproducible when I am connected to my wifi extender, and not my home's main router.

@unknown Any modifications to the game (like optifine) are not accepted on the tracker. Please try to reproduce this without OptiFine

Just tested using vanilla 1.16.4, issue persists.

Important information:

The issue disappears when I am directly connected to my home's main router. The issue only appears when I am connected to my wifi extender, which is how I produced the issue in the first place (my first post). Not sure how this plays into the situation–could mean lost packets going in/out? But I don't notice this issue when the server and client are hosted on separate machines, so again, not sure why this network configuration produces the issue.

Edit: how do I tag someone??

I'm working on a datapack, and the weird thing about this is that it doesn't happen if the datapack is disabled, but happens if the datapack is enabled. I'm sure it's not the datapack code that is causing this, the hitbox of the item is disappearing (if it was caused by a regular invisibility effect the hitbox would still be visible)

Based on a discussion in #mcdevs on around September 11 2024, this was probably fixed in 1.19.4/23w03a due to the packet bundle feature (mentioned on https://www.minecraft.net/en-us/article/minecraft-snapshot-23w03a), which should eliminate the chance of an item spawning and then the entity metadata getting processed on the next tick. I haven't had any time to do any testing, though, so I'm marking this issue as Awaiting Response for now.

(The issue in #mcdevs was with someone who was implementing a custom server from scratch, and having items always disappear when dropped from breaking a block. They determined that their issue started happening in 1.19.4, and the issue went away when they implemented packet bundles. So presumably the code that removes items that have no entity metadata still exists, but hopefully packet bundles prevent it from being an issue with the official server software.)