[MC-4] Item drops sometimes appear at the wrong location Created: 24/Oct/12  Updated: 08/Jan/25

Status: Reopened
Project: Minecraft: Java Edition
Component/s: None
Affects Version/s: Minecraft 1.4.1, Minecraft 1.4.4, Minecraft 1.4.5, Minecraft 1.4.6, Minecraft 1.4.7, Snapshot 13w02a, Snapshot 13w02b, Snapshot 13w04a, Snapshot 13w10b, Minecraft 1.5, Snapshot 13w11a, Minecraft 1.5.1, Minecraft 1.5.2, Snapshot 13w19a, Snapshot 13w21a, Snapshot 13w21b, Minecraft 1.6.1, Minecraft 1.6.2, Minecraft 1.6.4, Minecraft 13w38a, Minecraft 13w38b, Minecraft 13w38c, Minecraft 13w39b, Minecraft 13w41a, Minecraft 13w41b, Minecraft 13w42a, Minecraft 13w42b, Minecraft 13w43a, Minecraft 1.7, Minecraft 1.7.1, Minecraft 1.7.2, Minecraft 13w48a, Minecraft 13w48b, Minecraft 13w49a, Minecraft 1.7.3, Minecraft 1.7.4, Minecraft 14w02b, Minecraft 14w02c, Minecraft 14w03a, Minecraft 14w03b, Minecraft 14w04a, Minecraft 14w04b, Minecraft 14w05a, Minecraft 14w05b, Minecraft 14w06a, Minecraft 14w06b, Minecraft 14w08a, Minecraft 1.7.5, Minecraft 14w10b, Minecraft 14w10c, Minecraft 14w11b, Minecraft 1.7.8, Minecraft 1.7.9, Minecraft 14w17a, Minecraft 14w18b, Minecraft 14w20b, Minecraft 14w21a, Minecraft 14w21b, Minecraft 1.7.10, Minecraft 14w30b, Minecraft 14w30c, Minecraft 14w32a, Minecraft 14w32b, Minecraft 14w32c, Minecraft 14w32d, Minecraft 14w33c, Minecraft 14w34a, Minecraft 14w34b, Minecraft 14w34c, Minecraft 14w34d, Minecraft 1.8-pre3, Minecraft 1.8, Minecraft 1.8.1-pre1, Minecraft 1.8.1-pre3, Minecraft 1.8.1, Minecraft 1.8.3, Minecraft 1.8.4, Minecraft 1.8.8, Minecraft 15w40b, Minecraft 15w43a, Minecraft 15w43c, Minecraft 15w44a, Minecraft 15w46a, Minecraft 15w47a, Minecraft 15w47b, Minecraft 15w47c, Minecraft 15w49a, Minecraft 1.8.9, Minecraft 15w51b, Minecraft 16w02a, Minecraft 16w03a, Minecraft 16w04a, Minecraft 16w05b, Minecraft 16w06a, Minecraft 1.9, Minecraft 1.9.1 Pre-Release 1, Minecraft 1.9.1 Pre-Release 2, Minecraft 1.9.1 Pre-Release 3, Minecraft 1.9.1, Minecraft 1.9.2, Minecraft 16w14a, Minecraft 1.9.3 Pre-Release 3, Minecraft 1.9.3, Minecraft 1.9.4, Minecraft 16w20a, Minecraft 16w21a, Minecraft 16w21b, Minecraft 1.10 Pre-Release 1, Minecraft 1.10 Pre-Release 2, Minecraft 1.10, Minecraft 1.10.1, Minecraft 1.10.2, Minecraft 16w32a, Minecraft 16w32b, Minecraft 16w33a, Minecraft 16w35a, Minecraft 16w36a, Minecraft 16w39a, Minecraft 16w39b, Minecraft 16w39c, Minecraft 16w40a, Minecraft 16w41a, Minecraft 16w42a, Minecraft 16w44a, Minecraft 1.11 Pre-Release 1, Minecraft 1.11, Minecraft 1.11.2, Minecraft 17w06a, Minecraft 17w13b, Minecraft 17w17a, Minecraft 17w17b, Minecraft 1.12 Pre-Release 5, Minecraft 1.12, Minecraft 1.12.1 Pre-Release 1, Minecraft 1.12.1, Minecraft 1.12.2 Pre-Release 1, Minecraft 1.12.2 Pre-Release 2, Minecraft 1.12.2, Minecraft 17w43a, Minecraft 17w43b, Minecraft 18w03b, Minecraft 18w05a, Minecraft 18w11a, Minecraft 18w14a, Minecraft 18w14b, Minecraft 18w15a, Minecraft 18w16a, Minecraft 18w19a, Minecraft 18w19b, Minecraft 18w20a, Minecraft 18w20b, Minecraft 18w20c, Minecraft 18w21a, Minecraft 18w21b, Minecraft 18w22b, Minecraft 18w22c, Minecraft 1.13-pre1, Minecraft 1.13-pre2, Minecraft 1.13-pre3, Minecraft 1.13-pre4, Minecraft 1.13-pre5, Minecraft 1.13-pre6, Minecraft 1.13-pre7, Minecraft 1.13-pre8, Minecraft 1.13-pre10, Minecraft 1.13, Minecraft 18w30a, Minecraft 18w30b, Minecraft 18w31a, Minecraft 18w32a, Minecraft 18w33a, Minecraft 1.13.1, Minecraft 1.13.2-pre1, Minecraft 1.13.2-pre2, Minecraft 1.13.2, Minecraft 18w43b, Minecraft 18w43c, Minecraft 18w44a, Minecraft 18w45a, Minecraft 18w46a, Minecraft 18w47a, Minecraft 18w47b, Minecraft 18w48a, Minecraft 18w48b, Minecraft 18w49a, Minecraft 18w50a, Minecraft 19w02a, Minecraft 19w03a, Minecraft 19w05a, Minecraft 19w06a, Minecraft 19w07a, Minecraft 19w12b, Minecraft 19w13b, Minecraft 19w14a, Minecraft 19w14b, Minecraft 1.14 Pre-Release 2, Minecraft 1.14 Pre-Release 3, Minecraft 1.14 Pre-Release 4, Minecraft 1.14 Pre-Release 5, Minecraft 1.14, Minecraft 1.14.1 Pre-Release 1, Minecraft 1.14.1, Minecraft 1.14.2 Pre-Release 1, Minecraft 1.14.2 Pre-Release 2, Minecraft 1.14.2 Pre-Release 3, Minecraft 1.14.2 Pre-Release 4, Minecraft 1.14.3, 1.14.4, 19w37a, 19w38b, 19w39a, 19w40a, 19w41a, 19w42a, 19w44a, 19w46b, 1.15 Pre-release 1, 1.15 Pre-Release 2, 1.15 Pre-release 3, 1.15 Pre-release 4, 1.15 Pre-release 5, 1.15 Pre-release 6, 1.15 Pre-release 7, 1.15, 1.15.1, 1.15.1 Pre-release 1, 1.15.2 Pre-Release 1, 1.15.2 Pre-release 2, 1.15.2, 20w06a, 20w07a, 20w08a, 20w14a, 20w15a, 20w16a, 20w17a, 20w18a, 20w21a, 20w22a, 1.16 Pre-release 2, 1.16 Pre-release 3, 1.16 Pre-release 4, 1.16 Pre-release 5, 1.16 Pre-release 6, 1.16 Pre-release 7, 1.16 Pre-release 8, 1.16 Release Candidate 1, 1.16, 1.16.1, 20w27a, 20w28a, 20w29a, 20w30a, 1.16.2 Pre-release 1, 1.16.2 Pre-release 2, 1.16.2 Pre-release 3, 1.16.2 Release Candidate 1, 1.16.2 Release Candidate 2, 1.16.2, 1.16.3, 1.16.4 Pre-release 2, 1.16.4 Release Candidate 1, 1.16.4, 20w45a, 20w46a, 20w48a, 20w49a, 20w51a, 21w03a, 1.16.5, 21w05a, 21w05b, 21w06a, 21w07a, 21w08b, 21w10a, 21w11a, 21w13a, 21w14a, 21w15a, 21w17a, 21w18a, 21w19a, 21w20a, 1.17 Pre-release 1, 1.17 Pre-release 2, 1.17, 1.17.1 Release Candidate 1, 1.17.1, 21w37a, 21w38a, 21w39a, 21w40a, 21w41a, 21w42a, 21w43a, 21w44a, 1.18 Pre-release 5, 1.18 Release Candidate 1, 1.18 Release Candidate 4, 1.18, 1.18.1 Pre-release 1, 1.18.1 Release Candidate 1, 1.18.1, 22w03a, 1.18.2, 22w11a, 22w12a, 22w14a, 22w15a, 1.19, 1.19.1 Release Candidate 2, 1.19.1, 1.19.2, 22w42a, 22w43a, 1.19.3 Release Candidate 3, 1.19.3, 23w03a, 23w04a, 23w07a, 1.19.4 Release Candidate 2, 1.19.4, 23w13a, 23w17a, 23w18a, 1.20 Pre-release 6, 1.20, 1.20.1, 23w31a, 23w32a, 1.20.2 Pre-release 2, 1.20.2, 23w41a, 23w43a, 23w44a, 1.20.4, 23w51b, 24w03b, 24w04a, 24w06a, 24w09a, 24w13a, 1.20.5 Pre-Release 1, 1.20.5, 1.20.6, 24w20a, 1.21 Release Candidate 1, 1.21, 24w33a, 1.21.1, 24w39a, 1.21.3, 24w45a, 1.21.4 Pre-Release 1, 1.21.4
Fix Version/s: Minecraft 1.8.1-pre1

Type: Bug
Reporter: [Mod] Ezekiel (ezfe) Assignee: Unassigned
Resolution: Unresolved Votes: 820
Labels: desync, item-entity, packet, precision-loss, server

Attachments: PNG File 2016-08-10_17.29.13.png     PNG File 2016-08-10_17.29.16.png     PNG File 2021-02-03_20.08.05.png     PNG File 2021-05-12_14.43.55.png     PNG File 2021-05-12_14.43.58.png     File Item desync after explosion (Minecraft 1.8).mp4     File MC-4-16w32a-rep.mov     File MC-4.mp4     Zip Archive Minecraft bug MC-4 testcase backup.zip     Zip Archive Minecraft bug MC-4 testcase for debug.zip    
Issue Links:
Duplicate
is duplicated by MC-7500 Items can not be picked up Resolved
is duplicated by MC-9032 Ghost items Resolved
is duplicated by MC-9109 Spruce Sappling pick up Resolved
is duplicated by MC-9401 Ghost saplings Resolved
is duplicated by MC-10007 Items Jumping While Mining Or Item Is... Resolved
is duplicated by MC-11791 Coal dropping from ceiling repeatedly... Resolved
is duplicated by MC-12752 Dropped Items Shaking Resolved
is duplicated by MC-13010 Item Drop Glitch Resolved
is duplicated by MC-14655 Spirits (XP and items) twitch, move a... Resolved
is duplicated by MC-15292 items glitched when dropped Resolved
is duplicated by MC-15626 items Resolved
is duplicated by MC-15987 Dropped blocks fall up Resolved
is duplicated by MC-16960 Mini block in big block Resolved
is duplicated by MC-20354 Looped sapplings Resolved
is duplicated by MC-23220 Dancing egg glitch Resolved
is duplicated by MC-23611 A strange drop loop Resolved
is duplicated by MC-24273 Item Falling Loop Resolved
is duplicated by MC-33990 Block drops sometimes appear to fall ... Resolved
is duplicated by MC-39706 Cobblestone item block got stuck and ... Resolved
is duplicated by MC-69316 I don't even know where to start with... Resolved
is duplicated by MC-71907 When blocks are breaken some blocks o... Resolved
is duplicated by MC-71908 Blocks are dancing Resolved
is duplicated by MC-79486 Item drops bug Resolved
is duplicated by MC-97408 Items do not land properly when throw... Resolved
is duplicated by MC-98208 Torches end up far away from the plac... Resolved
is duplicated by MC-102470 items appear to fly away when blocks ... Resolved
is duplicated by MC-119318 Items can't be picked up in some cases Resolved
is duplicated by MC-134530 Items infinitely teleport up when thr... Resolved
is duplicated by MC-151891 Dropped items moves around without stop Resolved
is duplicated by MC-153822 Items dropped on top of a tree upon d... Resolved
is duplicated by MC-158673 Falling saplings glitch Resolved
is duplicated by MC-195438 sometimes item drops wrong direction Resolved
is duplicated by MC-222920 items are behaving really weird Resolved
is duplicated by MC-255892 water can't push items at the edge of... Resolved
is duplicated by MC-259534 stack too many items in a small area ... Resolved
is duplicated by MC-266415 Reminder: Item drops sometimes appear... Resolved
is duplicated by MC-1848 Items from decaying leaves not able t... Resolved
is duplicated by MC-2481 items still get stuck in transparent ... Resolved
is duplicated by MC-3167 Can not pick up some of witches drops Resolved
is duplicated by MC-3408 When you eject a record from a jukebo... Resolved
is duplicated by MC-3872 Droped item glitch Resolved
is duplicated by MC-4944 Of the record. Resolved
is duplicated by MC-5252 Items fail to pick up Resolved
Relates
relates to MC-249200 Several entities constantly deviate v... Open
relates to MC-94168 Items fall into opening shulker Open
relates to MC-106013 Item falling through boats Open
relates to MC-118411 Non cubic blocks do not properly push... Open
relates to MC-124375 Teleportation of item entity all tick... Open
relates to MC-173571 Regression with collision boxes of mo... Open
relates to MC-258368 When an item is thrown onto a big dri... Open
relates to MC-6626 Drops look buggy / move weirdly Resolved
relates to MC-73269 Glitchy item drops in 1.8.1-pre2 Resolved
relates to MC-87565 Conversion to integers in packets cau... Resolved
relates to MC-460 Experience orb position client-server... Resolved
relates to MC-2688 Thrown Items move after dropped Resolved
CHK:
Confirmation Status: Confirmed
Category:
Entities, Items, Networking
Mojang Priority: Low
Area: Platform

 Description   

The bug

When an item lands on the edge of a block, the client sometimes makes it fall over the edge while the server leaves it on the edge. This happens because the client thinks the drop can fall based on a slightly different location and attempts to predict the future incorrectly.

How to reproduce

  1. Throw an item on the ground and wait until it stopped moving
  2. Run in command block close to it:
    teleport @e[type=item,distance=..6] ~ ~1 ~-0.6249

Code analysis

Code analysis by marcono1234 can be found in this comment.

Fix

Fix by Panda4994 can be found in this comment.



 Comments   
Comment by 4ebugger [ 20/Dec/24 ]

They don't want to spend too much time focusing on this minor issue, its priority has been classified as low and it does not affect the actual gameplay very much so do not expect mojang will fix this issue soon.

Comment by Minecraft386882 [ 03/Dec/24 ]

Confirmed in 1.21.4 

Comment by [Mod] Ezekiel (ezfe) [ 04/Sep/24 ]

It is not against the rules to post when an issue affects a new version of the game. However… this is not an unknown issue to Mojang and commenting will not increase the likelihood it is fixed.

We will not be updating this with all pre-release and snapshot versions.

Comment by SightDash [ 03/Sep/24 ]

so what ur saying is that people shouldn't spam "Can confirm in [version]" because it's the oldest issue that wasn't resolved. But the reason people "spam" it is so that Mojang will see it and fix it. Believe it or not, this is how i found this issue in the first place. Telling people to not spam it will make it less likely to be fixed any time soon

Comment by traincrisis [ 20/Aug/24 ]

It is not required to spam "Can confirm in [version]". This issue is the oldest issue that is still not resolved on Mojira, and because of that, this bug haven't been yet fixed and will be in all versions until Mojang will fix it.

Comment by Fluffy64 [ 18/Aug/24 ]

Can confirm in 24w33a

Comment by Lunarian [ 20/May/24 ]

Can confirm in 1.20.6 & 24w20a

Comment by qvu217720 [ 13/Apr/24 ]

Confrimed at 1.20.5 Pre-release 1

Comment by Brain81505 [ 25/Oct/23 ]

Can confirm in 23w43a

Comment by [Mod] turbo [ 09/Sep/23 ]

osky2918: The issue isn't related to old or new hardware. It's primarily a client-side problem where the client prefers rounded positions even when exact positions are available. Fixing this would require changes on the server to send exact positions when entities stop moving in one axis or to optimize the handling of relative movement packets. This issue isn't tied to hardware but rather to how the game client handles entity positions and network traffic.

Comment by Oskar Edholm [ 09/Sep/23 ]

To people who still report this bug: What hardware do you run on? 

For example the picture in this bug clearly specify a CPU launched in 2009 playing a game in 2021 - 12 year old CPU also being a AMD, when the game most likely was optimized for Intel processors.

Do you run current hardware with full support for all libraries used by the game? Minimal requirments for running a game does not garantee a bug free experience compared to recomended requirments.

Being such a infrequent bug the posibilites of it being more related to sligtly incompatible hardware/clock skews/client-server architechture and loss in network packets could all be reasons for feeling the effects of this bug.

Comment by Dschinghis Khan [ 30/Aug/23 ]

23w35a

Comment by Brain81505 [ 09/Aug/23 ]

Can confirm in 23w32a

Comment by Qwe898 [ 03/Aug/23 ]

Can confirm in 23w31a

Comment by Kristijan Pintera [ 22/Jun/23 ]

Can confirm in 1.20.1

Comment by NguyenFranky [ 08/Jun/23 ]

Can confirm in 1.20

Comment by Dschinghis Khan [ 28/May/23 ]

in 1.20-pre6

Comment by Dschinghis Khan [ 06/May/23 ]

in 23w18a

Comment by Brain81505 [ 28/Apr/23 ]

Can confirm in 23w17a

Comment by peashooter [ 29/Mar/23 ]

still in 23w13a

Comment by Brain81505 [ 14/Mar/23 ]

Can confirm in 1.19.4

Comment by batbrain55 [ 21/Feb/23 ]

Can confirm in 23w07a.

Comment by Brain81505 [ 01/Feb/23 ]

Can confirm in 23w06a

Comment by Brain81505 [ 25/Jan/23 ]

Can confirm in 23w04a

Comment by Brain81505 [ 18/Jan/23 ]

Can confirm in 23w03a

Comment by Dschinghis Khan [ 08/Dec/22 ]

Relates to MC-258368

Almost the same (videos attached)

Comment by - [ 08/Dec/22 ]

Can confirm in 1.19.3

Comment by Josh Birk [ 06/Dec/22 ]

After updating to 1.19.3 Release Candidate 3, it still can be reproduced.

Comment by Josh Birk [ 06/Dec/22 ]

Still reproducible in 1.19.3 Release Candidate 1.

Comment by user-f2760 (Inactive) [ 31/Oct/22 ]

They kind of already did; you're only able to trigger this with extremely precise commands made in order to trigger this. You're not going to run into this without using a command like that.

Comment by Richard Anglin [ 31/Oct/22 ]

How has Mojang not fixed this yet? It’s been 10 YEARS since this opened.

Comment by [Mod] Avoma [ 06/Aug/22 ]

Can confirm in 1.19.2.

Comment by [Mod] Avoma [ 28/Jul/22 ]

Can confirm in 1.19.1.

Comment by sqvk [ 26/Jul/22 ]

can confirm for  22w12a.

Comment by [Mod] Avoma [ 08/Jun/22 ]

Can confirm in 1.19.

Comment by Onnowhere [ 01/Apr/22 ]

Appears to be fixed in 22w13oneblockatatime

Comment by [Mod] ManosSef [ 25/Mar/22 ]

Confirmed for 22w12a.

Comment by Connor Steppie [ 19/Mar/22 ]

It seems I had misinterpreted the newer reproduction steps and assumed they required a repeating command block, despite this not being the case. I've went ahead and reported this different case under MC-249200, so any discussion of this issue should continue there (I'd also recommend marking it as related).

Comment by [Mod] Ezekiel (ezfe) [ 17/Mar/22 ]

Awesoman3000 You're welcome to create separate issues for those other problems, but repeated teleportation with the tp is not part of this ticket and so is not related to those other things you're describing.

Since this ticket has ~150 people subscribed to it, I'd rather not extend discussion too much and spam people's mailboxes. This ticket is strictly related to the desync that occurs when an item is on a block edge, which has not been fixed. No repeated teleportation is needed to reproduce this issue.

Comment by Connor Steppie [ 17/Mar/22 ]

I'm mainly asking since the behaviour in question is basically exactly the same; we get the exact same "desync" behaviour from for example thrown eggs as we do from items when either is subject to repeated teleportation. It seems that due to this very similar observed behaviour that they'd make more sense to be included in this ticket, but if they warrant a separate ticket I'm all up for creating one.

Comment by [Mod] Ezekiel (ezfe) [ 17/Mar/22 ]

Awesoman3000 No change to this ticket is needed, the reproduction steps are simple and still work properly.

The steps you suggested are not related to this issue. While it is true that what you suggested does show (possibly) incorrect behavior, that would be a different bug that's only mildly related to this one.

This bug concerns the client receiving incorrect coordinate information. The client is taking the correct action based on the incorrect data it receives. The item falling is merely demonstrating that bad data was received.

Comment by Connor Steppie [ 17/Mar/22 ]

This may relate to some of the following tickets since they result from client-side interpolation causing unexpected visual results: MC-72846, MC-159802, MC-233911

Also reiterating my earlier question - would those other entities also qualify for inclusion in this ticket or should they be reported separately?

I'd also recommend adding the 12w18a label as this probably arises from the client-server split.

Comment by MMK21 [ 28/Feb/22 ]

Affects 1.18.2

Comment by Connor Steppie [ 19/Feb/22 ]

If I'm understanding what this ticket now concerns correctly (as the "item on a ledge" thing has been fixed from my testing and previous comments), a cleaner command to reproduce this would be the following command in a repeating command block:

tp @e[type=item] ~ ~2 ~

The expected behaviour, of course, would be for the item entities to appear suspended in midair (try this with arrows instead of items - this is the effect we're after), rather than continually falling.

By substituting "item" for some other entities, similar effects can be obtained; it seems to work for experience orbs, thrown eggs, thrown snowballs, thrown potions, thrown experience bottles, blaze fireballs and ghast fireballs. Should separate ticket(s) be created for these, or should the main ticket be updated to include these entities?

Comment by [Mod] Avoma [ 14/Dec/21 ]

Can confirm in 1.18.1.

Comment by Minh [ 28/Oct/21 ]

I could confirm in 21w42a, 21w43a

Comment by Vagdotcon [ 14/Oct/21 ]

Can confirm in 21w41a.

Comment by [Mod] ampolive [ 08/Oct/21 ]

Can confirm in 21w40a.

Comment by [Mod] ampolive [ 17/Sep/21 ]

Can confirm in 21w37a.

Comment by Matthew Ramirez [ 08/Jul/21 ]

Can confirm in 1.17.1. 

Comment by [Mod] ampolive [ 03/Jul/21 ]

Can confirm in 1.17.1 Release Candidate 1.

Comment by [Mod] Avoma [ 12/Jun/21 ]

Can confirm in 1.17.

Comment by Fabian Röling [ 24/May/21 ]

That's just a ghost block, probably leaves. Close and re-open the world to see it.

Comment by Jose Gallego [ 23/May/21 ]

Some explanation with video

Minecraft version 1.16.5 and server too

[*https://www.youtube.com/watch?v=rkgeLfqJwM4*]

Comment by [Mod] Avoma [ 30/Apr/21 ]

Can confirm in 21w17a.

Comment by Lentern [ 18/Apr/21 ]

I should mention this in case it hasn't already been posted.

PaperMC fix: https://github.com/PaperMC/Paper/pull/4872

PaperMC version before fix (build 326 is unavailable): https://papermc.io/api/v2/projects/paper/versions/1.16.4/builds/325/downloads/paper-1.16.4-325.jar

PaperMC version after fix: https://papermc.io/api/v2/projects/paper/versions/1.16.4/builds/327/downloads/paper-1.16.4-327.jar

Comment by [Mod] Avoma [ 16/Apr/21 ]

Can confirm in 21w15a.

Comment by Jonah Schroeder [ 14/Apr/21 ]

I still get the issue on any version modded or unmodded where the item will continuously fall and you have to pick it up from where it originally fell from, but also this bug report is the oldest still open bug at number 4.

Comment by [Mod] Avoma [ 12/Apr/21 ]

Can confirm in 21w14a.

Comment by The oldest trick in the book grian obsidian on chest [ 06/Apr/21 ]

This has been successfully reproduced by me in 21w13a, so please add 21w13a into the list so mojang knows its still an issue. 

Comment by Dudhhr [ 19/Mar/21 ]

Confirmed in 21w11a

i just didnt try enough times

Comment by [Mod] Avoma [ 13/Mar/21 ]

I've attached an updated video which demonstrates this issue.

Comment by Kihayu [ 12/Mar/21 ]

Can confirm in 21w10a

Comment by [Mod] Avoma [ 25/Feb/21 ]

Can confirm in 21w08b.

Comment by [Mod] Avoma [ 21/Feb/21 ]

Can confirm in 1.16.5.

Comment by [Mod] Avoma [ 17/Feb/21 ]

Can confirm in 21w07a.

Comment by [Mod] Avoma [ 10/Feb/21 ]

Can confirm in 21w06a.

Comment by [Mod] Avoma [ 04/Feb/21 ]

Can confirm in 21w05b.

Comment by Acheron River [ 04/Feb/21 ]

Alternate method of testing the effect.

Place dropper facing into cobweb and fire an item into it.

A water stream under will make the effect more dramatic.

Comment by [Mod] Avoma [ 03/Feb/21 ]

Can confirm in 21w05a.

Comment by [Mod] Avoma [ 21/Jan/21 ]

Can confirm in 21w03a.

Comment by Testing [ 13/Jan/21 ]

I confirm.

Comment by [Mod] Avoma [ 21/Dec/20 ]

Can confirm in 20w51a.

Comment by [Mod] Avoma [ 02/Dec/20 ]

Can confirm in 20w49a.

Comment by [Mod] Avoma [ 25/Nov/20 ]

Can confirm in 20w48a.

Comment by Josh Birk [ 18/Nov/20 ]

Still able to fully reproduce.

Comment by Tinay [ 05/Nov/20 ]

Still in 20w45a

Comment by [Mod] Ezekiel (ezfe) [ 20/Sep/20 ]

Bumblebee, It's in the report text at the top of the page

Comment by Bumblebee [ 20/Sep/20 ]

what is the new command, it would be very helpful, thanks

Comment by Tinay [ 12/Sep/20 ]

Can reproduce in 1.16.3 with the new given command.

Comment by [Mod] Anthony Cicinelli [ 11/Sep/20 ]

ItsTinay currently an effort is being made by the community over on the Mojira Discord attempting to figure out how to reproduce this from 1.16.2+ markderickson just found that the reproduction steps stopped working in that version. If you would like to continue the discussion on how to reproduce this I recommend going to the discord or subreddit since this site isn't a forum for discussion

Comment by Tinay [ 11/Sep/20 ]

Ok thanks Ezekiel

Comment by Tinay [ 11/Sep/20 ]

@Mark Derickson Are you sure that this bug was fixed in 20w27a? There are people telling before that it still wasn't fixed

Comment by [Mod] Ezekiel (ezfe) [ 11/Sep/20 ]

Thanks, ItsTinay, reproduction steps may be different starting with 1.16.2 onwards, we're aware of this and making new instructions–to everyone else, no need to comment if the command listed isn't working for you while we sort this out.

Comment by Tinay [ 11/Sep/20 ]

Also can't reproduce in 1.16.3 using the given command

Comment by [Mod] markderickson [ 11/Sep/20 ]

Hello!

I could reproduce in 1.16.1 first try, but not at all in 20w27a. Seems to be fixed in 20w27a.

Comment by [Mod] Anthony Cicinelli [ 11/Sep/20 ]

I also can't reproduce. Tested with the command

Comment by Bumblebee [ 11/Sep/20 ]

did you use the command?

Comment by Numeritos [ 10/Sep/20 ]

Cannot reproduce in 1.16.3

Comment by MMK21 [ 14/Aug/20 ]

@Bumblebee Only the latest stable release (currently 1.16.2) and latest development version (currently also 1.16.2; no updates are in development) are tracked here.

PS: Excessive markup not nessasery.

Comment by Bumblebee [ 14/Aug/20 ]

Affects Combat Test 7c  

Comment by Bumblebee [ 11/Aug/20 ]

affects 1.16.2 (full)

Comment by Bumblebee [ 10/Aug/20 ]

affects  {1.16.2 Release Candidate 2}}

Comment by MMK21 [ 07/Aug/20 ]

@Tinay Please don't comment if you have nothing useful to add. 118 users are watching this.

Comment by Tinay [ 07/Aug/20 ]

Its priority is so low, no one will fix that bug, we are here just to suffer

Comment by Bumblebee [ 07/Aug/20 ]

also affects combat test 6.

Comment by Bumblebee [ 07/Aug/20 ]

affects 1.16.2 Release Candidate 1. Like please fix.

Comment by Bumblebee [ 06/Aug/20 ]

affects 1.16.2 pre-2 and pre-3.

Comment by Bumblebee [ 29/Jul/20 ]

obviously, affects 1.16.2 Pre-release 1. Like this is such an old bug

Comment by MMK21 [ 20/Jul/20 ]

@thcrafter06 Unnecessary comment. There are over 100 people watching this ticket.

Comment by pulpetti [ 16/Jul/20 ]

Affects 20w29a

Comment by Bumblebee [ 10/Jul/20 ]

Affects 20w28a

Comment by Iosiv Visokogorskiy [ 06/Jul/20 ]

Affects 20w27a

Comment by Iosiv Visokogorskiy [ 25/Jun/20 ]

Affects 1.16.1

Comment by GamerZone [ 25/Jun/20 ]

confirmed in the full 1.16 release

 

Comment by Saisho Bready [ 18/Jun/20 ]

I can confirm 1.16-RC1

Comment by Numeritos [ 18/Jun/20 ]

Affects 1.16-pre8

Comment by Conem [ 17/Jun/20 ]

Confirmed in 1.16-pre7.

Comment by Conem [ 15/Jun/20 ]

Confirmed in 1.16-pre6.

Comment by Conem [ 12/Jun/20 ]

Confirmed in 1.16-pre5.

Comment by Sapsalo [ 07/Jun/20 ]

Affects 1.16 pre-release 2

Comment by MMK21 [ 03/Jun/20 ]

@Minecraft Loot Coming from the MCW? Please only comment if you have something useful to add.

Comment by Sapsalo [ 21/May/20 ]

Affects 20w21a.

Comment by Name Needed [ 18/Apr/20 ]

I tested and the bug affects 20w16a.

I feel that the bug could be used as a target for dupe glitches.

Comment by [Mod] Ezekiel (ezfe) [ 04/Apr/20 ]

I would like to keep the ticket

Comment by Connor Steppie [ 04/Apr/20 ]

Affects 20w14a, can I request ownership?

Comment by W_V [ 25/Feb/20 ]

Confirmed for 20w08a

 

Comment by Michael91273 [ 07/Dec/19 ]

Affects 1.15pre6

Comment by Connor Steppie [ 25/Nov/19 ]

Affects 1.15pre2

Comment by Santino lobos [ 21/Nov/19 ]

Affects 1.15 Pre-release 1
(it already shows that but its alright if you didnt see the Affects Version/s category.)

Comment by Connor Steppie [ 16/Nov/19 ]

Affects 19w46b, can I request ownership?

Comment by Connor Steppie [ 02/Nov/19 ]

Affects 19w44a

Comment by Connor Steppie [ 16/Oct/19 ]

Affects 19w42a

Comment by Connor Steppie [ 14/Oct/19 ]

Affects 19w41a

Comment by Connor Steppie [ 02/Oct/19 ]

Affects 19w40a

Comment by Connor Steppie [ 27/Sep/19 ]

Affects 19w39a

Comment by Connor Steppie [ 20/Sep/19 ]

Affects 19w38b

Comment by Spottedleaf [ 15/Jul/19 ]

It's similar in that we both keep double precision on the client/server - but mine changes the entity tracker serverside & clientside so that when relative move packets come in they do not discard the full precision data the client already has (Panda's will do that if the rel movement for the axis is not 0).

I'm also not familiar with the entity tracker 2 years ago but I know that applying his changes on the server entity tracker for 1.14 has an issue with the fact that it will not correctly record what position the client has - making relative move a use the wrong positions for delta (however you wont tend to notice it given how small the error would be). In fairness to Panda this might not have even been an issue 2 years ago, as I'm not familiar with the tracker then. But that issue stands for 1.14's tracker.

 

Comment by Christopher Martin [ 15/Jul/19 ]

Hey there @spottedleaf

 

Thanks for having a go at solving the issue. I believe that Panda had a go at fixing this a while back:

https://bugs.mojang.com/browse/MC-4?focusedCommentId=325432&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-325432

 

Pretty sure his solution is pretty close to yours.

Comment by Spottedleaf [ 11/Jul/19 ]

After some testing I've found a partial solution.

 

The current issue with the tracker is how it updates positions to the client. When an absolute position packet comes in (whether it be due to the spawn packet or teleport packet), the client will use the full precision to update the entity position. It will also update the fixed precision "server position" packets (serverPosX MCP 1.14 mappings) on the entity. This is good until a relative move packet comes along.

The handling for relative move is it will update the "server position" fields on the entity, and then re-set the position of the entity using those fields. This is where issues come in: The teleport packet data is rounded off within 3 seconds of it being sent!

 

I've updated clientside & server side trackers to handle this here:

https://gist.github.com/Spottedleaf/2b7fa048e5bfdf3b804a0864d7dca19d

I've lightly tested this to confirm it works - tested moving around, lots of entities, moving in and out of boats/horses, etc. The patch is for both server & clients, using oldish 1.14.3 MCP mappings. Ignore the // leaf comments - that's just a habit from working on paper.

This patch will ensure correct behavior if you use the following command in a command block:

summon item ~ ~1 ~-0.6249 {Item:{id:"stone",Count:1b}}

The item will fall on top of the command block and will stay there until removed.

 

My diff basically drops fixed precision positions on client/server - however it still sends relative move with fixed precision. It's just that now clients will store server positions as full precision double values. So when adding relative move, there's no casting away of precision - which was the original problem here.

The server has been modified accordingly to ensure that the positions do not get out of sync. The positions sent to the client are also now stored as full precision in the entity tracker, however I have ensured that we correctly update these positions when sending the fixed precision relative move packets so that they should be exactly what they are on the client.

 

Now this does NOT entirely solve the issue with MC-4, if an entity moves (on the x/z axis) to the edge of a block it's still possible for them to fall off clientside. However the server eventually sends a teleport packet (full precision) which would resolve it.

I think it is a good idea to also disable gravity client-side if the server has explicitly marked the entity as being on the ground - however that has its own mess to solve and inconsistencies elsewhere, but my patch is a good start to this issue.

 

EDIT:

I'd like to thank Billy from PaperMC for notifying me relative move packets were causing this issue.

Comment by Helga Rakel [ 10/Jul/19 ]

This bug is also found in 1.14.3 (https://youtu.be/65HCLpkqLfs)

Comment by Taylor Depree [ 24/May/19 ]

Affects 1.14.2-pre4

Comment by Taylor Depree [ 23/May/19 ]

Affects 1.14.2-pre3

Comment by Republican [ 21/May/19 ]

Affects 1.14.2-pre2

Comment by Hayden Wong [ 24/Apr/19 ]

Affects 1.14

Comment by Connor Steppie [ 12/Apr/19 ]

Affects 1.14pre2

Comment by Connor Steppie [ 05/Apr/19 ]

Affects 19w14b

Comment by Connor Steppie [ 04/Apr/19 ]

Affects 19w14a

Comment by Connor Steppie [ 02/Apr/19 ]

Affects 19w13b

Comment by Hayden Wong [ 27/Mar/19 ]

Affects 19w12b

Comment by Jack Hanna [ 15/Feb/19 ]

Affects 19w07a

Comment by Connor Steppie [ 12/Dec/18 ]

Affects 18w50a

Comment by Connor Steppie [ 05/Dec/18 ]

Affects 18w49a

Comment by Connor Steppie [ 30/Nov/18 ]

Affects 18w48b. This is a bit of a long shot, but can I request ownership of the ticket?

Comment by Connor Steppie [ 29/Nov/18 ]

Affects 18w48a

Comment by Connor Steppie [ 25/Nov/18 ]

Affects 18w47b

Comment by Connor Steppie [ 21/Nov/18 ]

Affects 18w47a

Comment by Connor Steppie [ 19/Nov/18 ]

Affects 18w46a

Comment by xXUnztoppablezXx [ 11/Nov/18 ]

Confirmed for 18w45a.

Comment by Kraif [ 19/Oct/18 ]

Confirmed for 1.13.2-pre2.

Comment by Kraif [ 16/Oct/18 ]

Confirmed for 1.13.2-pre1.

Comment by Kraif [ 22/Aug/18 ]

Confirmed for 1.13.1.

Comment by Kraif [ 15/Aug/18 ]

Confirmed for 18w33a.

Comment by Fabian Röling [ 08/Aug/18 ]

Pretty likely, as with most one to three digit bugs. But there's no way to track it here. If you can find the definite earliest version this occurs in, best an old snapshot, then leave a comment here and I'll write it into the description. But I guess it was even before Alpha, when client and server were separated.

Comment by James Moton [ 08/Aug/18 ]

When did bug MC-4 start appearing? Was it before MC 1.4, i.e. before Mojang started using JIRA as it's bug-tracker?

Comment by Kraif [ 08/Aug/18 ]

Confirmed for 18w32a. What an old bug!

Comment by Kraif [ 01/Aug/18 ]

Confirmed for 18w31a.

Comment by Kraif [ 25/Jul/18 ]

Confirmed for 18w30a.

Comment by Andrew Chang [ 18/Jul/18 ]

Can confirm for 1.13

Comment by carpet0928 [ 18/Jul/18 ]

Can confirm for 1.13-pre10.

Comment by Connor Steppie [ 10/Jul/18 ]

Affects 1.13-pre7

Comment by Connor Steppie [ 04/Jul/18 ]

Affects 1.13-pre6

Comment by Connor Steppie [ 28/Jun/18 ]

Affects 1.13-pre5

Comment by Connor Steppie [ 27/Jun/18 ]

Affects 1.13-pre4

Comment by Connor Steppie [ 21/Jun/18 ]

Affects 1.13-pre2

Comment by Connor Steppie [ 15/Jun/18 ]

Affects 1.13-pre2

Comment by Connor Steppie [ 04/Jun/18 ]

Affects 1.13-pre1

Comment by bdm68 [ 03/Jun/18 ]

Affects 18w22c.

Reproduced by creating a Superflat world and executing these commands:

  • /tp 4 4 -4
  • /setblock 0 4 0 minecraft:stone
  • /summon minecraft:item 0 5 -0.1249 {Item:{id:"minecraft:stone",Count:1b}}

 

Comment by Connor Steppie [ 31/May/18 ]

Affects 18w22b

Comment by Connor Steppie [ 23/May/18 ]

Affects 18w21a

Comment by Connor Steppie [ 18/May/18 ]

Affects 18w20c

Comment by Connor Steppie [ 16/May/18 ]

Affects 18w20b

Comment by Connor Steppie [ 15/May/18 ]

Affects 18w20a

Comment by Connor Steppie [ 08/May/18 ]

Affects 18w19a

Comment by Connor Steppie [ 19/Apr/18 ]

Affects 18w16a

Comment by Connor Steppie [ 11/Apr/18 ]

Affects 18w15a

Comment by Connor Steppie [ 05/Apr/18 ]

Affects 18w14b

Comment by Connor Steppie [ 04/Apr/18 ]

Affects 18w14a

Comment by Eiim [ 14/Mar/18 ]

1.13-style command format is: /summon minecraft:item ~ ~1 ~-0.6249 {Item:

{id:"stone",Count:1b}

}

Comment by Connor Steppie [ 14/Mar/18 ]

The command provided does not work in 18w11a.

Comment by Ice Trailer [ 22/Jun/17 ]

Can confirm in version 1.12. Occurrence most at leaves

Comment by user-f2760 (Inactive) [ 20/Jun/17 ]

Please take any further discussion to the Mojira reddit.

Comment by Meri Diana [ 19/Jun/17 ]

theosib2 First of all, the mods seem to have to stop any sort of "discussion" on this platform, if it does not add to the bugfix, which also may sometimes result in setting a post to private (so only mods/devs can read them, but not we regular members), and also sometimes in issueing a warning towards the participants of such an unwanted discussion.

I'm going to take the risk, as I don't like the way you phrased your message in a way of "hijacking" this bugpost for a more or less hidden motive that one can read out of it.


I didn't know ilmango works now for Mojang, that he's got such an obvious insight on their bugfix priorities and overall workflow and agenda.

Instead of fanboy-parroting what some technical player Youtuber with business/money interest is complaining about, it'd be better for starters to understand the totality of the general topic of bugfixing. A bug is not only that which - obvious for anyone - is one, but also that which developers (or their superiors) don't want the game to function like. Whether we like it or not, it's their decision, not ours. You seem to be an intelligent person with programming knowledge, so you should understand that.

Sometimes bugfixes that we may consider "unimportant" may have to be prioritised to prepare the grounds for some more important bugfixes, or other reasons we outsiders cannot know. Sometimes bugfixes and also new additions aren't so easy, e.g. sometimes it may (or does) even break the code on other areas.

All we can do is to hope they would give us an alternative, "clean code" addition at some point for some "bug toys" we've "lost" due to bugfixes, and understand that in order to get new implementations, the code has to be cleaned up more, which may result in bugfixes we won't like, and we may very late or never get a "clean code equivalent addition" for some "bug toys".

I'm not saying that I agree to each addition or change or bugfix in Java MC (I've stepped on some Devs' toes a couple of times over the past years and intend to continue to do so, if I see the need for it), but at least I don't use some more or less known Youtuber as an "argument" to "validate" my message.

To take your example of piston warping: There's not always, but often two opposing sides in the community regarding the fix of some bugs, some like a bug, some are annoyed by it. But what really counts is whether or not the developers want pistons to work like that, and if not, they're going to fix it, regardless of what the community does with those bugs. It's not as if some other technical Youtubers you may also follow would have never warned the tech community about using this or other bugs publicly, as it was obvious that the Devs would consider it a bug, right? Just because some Youtubers popularize a bug and make it seem a feature, does not make it less of a bug, or overall less likely to get fixed.

Generally, the technical Survival community still doesn't seem to have figured where Java MC seems to be obviously headed, nor the apparent need of a complete or at least very fundamental rewrite of Redstone; that bugposts which are not related to Survival tech are being prioritised for fixing is thus not surprising to me.

I hope you didn't mind my open words, but I'm not known for tip-toeing around and hiding my true opinion behind linguistic manipulation.

Comment by MalbaCato [ 19/Jun/17 ]

theosib2 - Every bug is a bug and it should be fixed, (unless jeb says its a won't fix), it doesn't matter how important or hard it is to fix.The more game-breaking ones are of course prioritised (like MC-111645), but for most issues the votes count is the way to sort them.

About the resolution of the bug itself - it's a little more complicated then that, go watch panda's video if you haven't.

sorry for the unnecessary bug updates, the syntaxes never work the first time

Comment by Timothy Miller [ 19/Jun/17 ]

I get that this is a "bug," but I don't see what all the hubbub is about. So I have a few dumb questions about this bug:

  • Does this cause any real breakages? This is a client-side glitch, but it doesn't cause any server-side corruption or anything. MC-4 is interesting because it's really really old, but there are sensible reasons why fixed-point numbers are sent from server to client.
  • Since the server knows how it's rounding float to fixed, and it knows where everything else is, it should be able to predict when the client is going to manifest, right? Why can't it then just tweak the fixed point numbers just slightly so as to arrive at a desired client-side effect? Abstract example: Let's say an original value is equivalent to 0111.11111111, but we want to round it to 8 bits, which results in the value 1000.0000, and let's say that this makes a difference on the client side where it would appear in the wrong location. Why could the server not anticipate this and send 0111.1111 instead? There may be a heuristic that works in most cases, or worst-case, the server could try out a few different possible conversions to determine which one works best and send that.

That all being said, unless someone can explain why this is such a huge problem, I don't see why anyone should really bother investing time into fixing it. Ilmango recently griped that Mojang doesn't seem to fix bugs in the basis of severity. There are far more severe bugs than this (e.g. MC-22147, which wrecks all kinds of things). As far as I can tell, MC-4 is more of a source of amusement and entertainment than anything else, and it's nothing that any of the devs should feel bad about. On the other hand, fixing piston translocation (which people were making product use of) before fixing chunk unload duping bugs... that seems like a significant priority reversal.

Comment by SunCat [ 27/May/17 ]

femoutarde, 1.11.2 was already marked as affected

Comment by femou [ 27/May/17 ]

Confirmed for 1.11.2

Comment by Vladimir Rizov [ 24/May/17 ]

Confirmed for 1.12 - Pre-release 5

Comment by Alawnely [ 01/May/17 ]

Confirmed for 17w17b

Comment by user33 [ 27/Apr/17 ]

Confirmed for 17w17a

Comment by Leo Izen [ 02/Apr/17 ]

Wow, I have an unfixed bug in the 20,000 range but I'm impressed that MC-4 hasn't been fixed yet.

Comment by [Mod] Sonicwave [ 18/Nov/16 ]

Confirmed for 1.11.

Comment by husky2490 [ 14/Nov/16 ]

Might I make a suggestion? Would it be possible to exempt dropped items from client-side gravity? It might create some weird floating items but you already do a similar thing with players

Comment by Fabian Röling [ 13/Nov/16 ]

Video by Panda4994 that doesn't fix this, but makes it less common: https://www.youtube.com/watch?v=VKHBJxtSlc0

Comment by Jake Gearhart [ 13/Nov/16 ]

This bug relies on the very basics of the code and to fix this it could cause a lot of other problems, I bet Mojang is doing the best that they can to try and find a lag free fix.

Comment by Nope. [ 05/Nov/16 ]

Confirmed for 16w44a.

THIS IS MC-4. FIX THE BUG ALREADY.

Comment by Kumasasa [ 24/Oct/16 ]

colorfusion: This ticket was already confirmed for 16w42a , no need to reconfirm.

Comment by user33 [ 29/Sep/16 ]

Confirmed for 16w39a

Comment by [Mojang] Panda [ 15/Aug/16 ]

jeb It indeed seems like the client preferred the rounded positions over the exact ones, even when it had access to it.
I made the following changes on the client side to better this: https://gist.github.com/Panda4994/741bde1d58054513e3d44c4ba7c7f660/revisions

This does fix the issue for the command:

summon Item ~ ~1 ~-0.6249 {Item:{id:"stone",Count:1b}}

However it does not fix it in cases in which an entity was moved by a relative teleport after the last forced teleport since the client can't possible know the exact location in these cases.
So throwing an item down and triggering a command block with this command will still produce the issue (the item needs to be within 8 blocks):

teleport @e[type=Item] ~ ~1 ~-0.6249

To fix this as well the server would have to tell the client the exact position when ever the entity stopped moving in one axis. Even just sending an absolute teleport when the entity stopped moving at all would solve most cases (except this one).
Either way, even though it would not be sending a teleport on each position update, it certainly would need to send more and be a bit more expensive on the network.

While looking at the server side code I noticed that the relative movement packets are send every 3 seconds, even if the entity didn't move at all.
So each movable, but currently not moving entity sends a relative movement package containing three zeros each three seconds.
The client resets the entities position to the last one it got from the server when receiving these packages, but the only information these packages convey is that 60 ticks have passed on the server side.
So instead of sending these “empty” packages the client could just make an assumption about the server running at the same time and update the entity position if it didn't receive a position update for more than 60+n ticks.
Alternatively the client maybe could use the received keep alive packages to tell how many ticks passed for the server.

Since most entities are stationary a lot of the time, I think that this would greatly reduce the traffic and possibly outdo extra teleport packages that would be needed to fix this issue.

Also I think MC-7809 may be seen as related to this issue as it likely is caused by network rounding errors of the rotation pitch.

Comment by Fabian Röling [ 12/Aug/16 ]

Jeb, I think that would generally be a good idea (if it doesn't have disadvantages, like too much traffic). But it wouldn't solve this bug. For example you could put an item on a ledge and then set up a repeating command block to give it momentum along this ledge. This way the item never stops, but keeps being in a state where it glitches up and down.

Comment by [Mojang] Panda [ 12/Aug/16 ]

I don't see through it completely yet, but to me it looks like the problem mainly is how the data is handled on the client side.
When summoning an item with the command by ezekielelin

summon Item ~ ~1 ~-0.6249 {Item:{id:"stone",Count:1b}}

there shouldn't be any reason for it be be affected by relative movements as it never moved.

From the looks of it the client keeps track of the position it believes the entity has on the server with 3 longs which store an encoded position.
Even when an absolute position update is send the accurate information gets thrown away when encoding it into the long-fields.
So as soon as the next relative position update is send the inaccurate values show again, even if the entity didn't move.

I think if the client would keep track of the accurate server position instead of the encoded ones and an absolute position update would be send each time an entity stops moving in x, y or z most cases would be solved.

An other thing I noticed is that on absolute position updates the client side entity position is only set to the values of the server if the change to the last client value is greater than 0.03125.
This doesn't make sense to me as the client just got to know the exact position of the entity on the server side and chooses to ignore it if he has it close to it already.
This kind of code would rather make sense for the inaccurate relative position updates where small changes might just be due to rounding errors.

As I said I don't see through 100% yet, so I'm ready to be corrected
(The comment is based on the code found in MCP 1.10, not the snapshots)

Comment by [Mojang] Jeb (Jens Bergensten) [ 12/Aug/16 ]

Yes, the entity move packet is indeed the problem. The relative movement is truncated into integers to save 12 bytes of data for each update, and in certain cases this is not granular enough to achieve correct movement physics.

The "hack" I had in mind was to simply let the server tell clients when an item has become stationary. When that happens the client should no longer predict the physics until the server says the item is moving again. Just feels like an awfully awkward workaround.

Comment by Marcono1234 [ 11/Aug/16 ]

Please link from the description to this comment again until MCP is released for the snapshots or 1.11

Jeb, please have a look at that comment, I assume the packets I mentioned there are causing this

Comment by Meri Diana [ 11/Aug/16 ]

jeb Personally I think "clean code" should be preferred over a "hack" (if you mean a temporary "ugly" fix with it).
Also to not make people unhappy if a "hack" gets fixed at some point with "clean code" (which then maybe would "break" that "hack/feature").

As you guys and gals want to have everything the same across all platforms, it'd be interesting to know about this behaviour on platforms other than Java-PC though.
I don't own any of the others, so I can't check on that myself.

If this bug does not occur on other platforms and you're sure it's fixable sometime on Java-PC via "clean code", I wouldn't use a temporary fix/"hack" but rather work towards clean code.
Even if that means that Java-PC will have that bug persisting until then.
Unless a "temporary hack" would not cause other bugs or interfere with you guys' and gals' code-cleaning and code-adding work in any way and make things harder or so.

Comment by [Mojang] Jeb (Jens Bergensten) [ 11/Aug/16 ]

:sadface: At least that command gives an identifiable rounding error in the network code. Could do a hack to fix it for items, but not sure that's the correct approach

Comment by [Mod] Neko [ 10/Aug/16 ]

Nevermind, still not fixed.

Comment by [Mod] Ezekiel (ezfe) [ 10/Aug/16 ]
summon Item ~ ~1 ~-0.6249 {Item:{id:"stone",Count:1b}}
Comment by [Mod] Neko [ 10/Aug/16 ]

Cannot reproduce in 16w32a, what command are you using?

Comment by [Mod] Ezekiel (ezfe) [ 10/Aug/16 ]

Still an issue in 16w32a

Comment by Marcono1234 [ 06/Aug/16 ]

Reddit comment of Jeb regarding the fix (please link in the description to this comment)

Comment by Samuel Lembas [ 04/Aug/16 ]

Does fixing this bug means that lying items won't constantly shoot in the air and appear back anymore? Because I've seen this issue every time on PvP servers.

Comment by Marcono1234 [ 04/Aug/16 ]

I updated my comment, can you please link from the description to it. In case the situation changes for 1.11 feel free to remove the link again

FaRoGaming, for me the item dropped only once with the previously provided command. The reason for that is very likely that the Motion is not send as double (see my previous comment). A little bit off-topic, but I think you create sometimes incorrect username links. You have to use the user name, not the full name (which is displayed). For example __null's user name is __null. To see the username you can either click on the name of someone of hover over it. The link to the profile contains the username as well.

Comment by user-f2760 (Inactive) [ 04/Aug/16 ]

FaRoGaming: https://twitter.com/jeb_/status/761127040653389824

As @SeargeDP mentioned we're aiming to snapshot 1.11 soon, and these snapshots will focus on bug fixing. Features to be revealed at Minecon

Comment by [Mod] Ezekiel (ezfe) [ 04/Aug/16 ]

FaRoGaming It's already been changed and the current one is the proper one.

Comment by Fabian Röling [ 04/Aug/16 ]

jeb Is fixing the oldest open bug a hint that 1.11 will be a bugfix update?
Marcono1234 For me the given command from the description reproduces the bug. I'll check again probably in 5 hours and then either change the description or correct you.

Comment by Marcono1234 [ 04/Aug/16 ]

Please link to this comment in the description

The following is based on a decompiled version of Minecraft 1.10 using MCP 9.30.

Please update the command to reproduce to

/summon Item ~ ~1 ~-0.6249999999 {Item:{id:"stone",Count:1b}}

The currently provided command does not cause this in 1.10.2 anymore.

In 1.10 (decompiled using MCP 9.30) the packets SPacketEntityTeleport, SPacketSpawnMob and SPacketSpawnObject use double s for the coordinates. So it might be something different that causes this.
Edit: The packet net.minecraft.network.play.server.SPacketEntity causes this. This packet first of all sends the relative coordinate changes as short instead of double and additionally uses a variable of the type long to store the position provided by the server.

Motion (for fireballs power)

Variable type used: double

Packet name variable type
SPacketSpawnMob int
SPacketSpawnObject int

Yaw and pitch

Variable type used: float

Packet name variable type
SPacketEntityTeleport byte
SPacketEntity byte
SPacketSpawnMob byte
SPacketSpawnObject int
Comment by [Mojang] Jeb (Jens Bergensten) [ 04/Aug/16 ]

It's fixed to the point that I can't reproduce it any more. Please update the bug report after the first 1.11 snapshot if you find a way to reproduce it. Obviously the items will jitter slightly depending on client-server lag issues, but items should no longer appear in the wrong locations.

Comment by Fabian Röling [ 22/Jun/16 ]

It's called "TinyTask", it just controls my mouse and keyboard.

Comment by [Mod] redstonehelper [ 22/Jun/16 ]

http://reddit.com/r/Mojira

And please don't run bots here without clearing it with us before.

Comment by Fabian Röling [ 22/Jun/16 ]

I set a little bot up to confirm it for those that aren't set to affecting 1.10.1 yet, so it might be that I confirmed something that someone else already confirmed. Additional notes are also in the according bug reports now.
To avoid off-topic discussions in the future: Is there a general place to discuss about JIRA while having mods read it?

Comment by [Mod] redstonehelper [ 22/Jun/16 ]

@FaRoGaming: Are any of the tickets you listed not updated yet? Regarding the ones you made separate notes for, please comment on those individually.

Comment by Kumasasa [ 22/Jun/16 ]

@__null: Wait until tomorrow, then you'll be able to update all the tickets.

Comment by Fabian Röling [ 22/Jun/16 ]

Well, if you report it in all the reports anyway, I could probably set a small bot up to do that.

Comment by Fabian Röling [ 22/Jun/16 ]

__null Nope, I just used a filter that gives me all open bugs in chronological order so that I can test them. I'm your new concurrency in confirming.
https://bugs.mojang.com/browse/MC-4?filter=-4&jql=project%20%3D%20MC%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20Postponed)%20ORDER%20BY%20createdDate%20ASC

Comment by null (Inactive) [ 22/Jun/16 ]

You've been following my user profile, haven't you?

Comment by Fabian Röling [ 22/Jun/16 ]

Ok, prepare for something... Could please a mod mark the versions for every bug I tell you here? That would be nice.
I have a world set up for fast bug testing. That means that going into each bug report and saying "Confirmed for 1.10.1" is way more work than actually testing it. So I want to confirm for 1.10.1 with this comment:
MC-4, MC-9, MC-14, MC-87, MC-112, MC-201, MC-212, MC-234, MC-258, MC-460, MC-577, MC-667, MC-679, MC-696, MC-697, MC-849, MC-868, MC-926, MC-957, MC-997, MC-1040, MC-1127, MC-1133, MC-1168, MC-1207, MC-1218, MC-1297, MC-1390, MC-1429, MC-1530, MC-1531, MC-1538, MC-1541, MC-1555, MC-1578, MC-1673, MC-1685, MC-1691, MC-1981 and MC-2023.
All of these are tested in 1.10.1. For some others I have additional information:
MC-711 not testable with my setup because of a crash that's new in 1.10.1.
MC-779: At least some appear outside, didn't test all. What's sure is that no general solution got introduced.
Confirmed MC-1511 for stone button, lever, torch, redstone dust, normal rail, end rod, tripwire hook, ladder and flower pot. Others are untested.
Confirmed MC-1874 for chest, brewing stand, enchanting table and flower pot. Others are untested. It's apparent that there isn't a general solution here either.

Comment by Fabian Röling [ 08/Jun/16 ]

Confirmed for 1.10 with the command by null. For some reason the drop first falls from the negative z side of the command block, but then suddenly appears 6 blocks farther in the positive z direction.

Comment by null (Inactive) [ 07/Jun/16 ]

Confirmed for 1.10-pre2.

Comment by null (Inactive) [ 03/Jun/16 ]

Confirmed for 1.10-pre1. Here's a command that will reproduce this bug:

/summon Item ~ ~0.54 ~-0.625 {PickupDelay:15,Motion:[0.0,0.0,1.0]}
Comment by null (Inactive) [ 26/May/16 ]

Confirmed for 16w21b.

Comment by null (Inactive) [ 25/May/16 ]

Confirmed for 16w21a.

Comment by null (Inactive) [ 18/May/16 ]

Confirmed for 16w20a.

Comment by null (Inactive) [ 11/May/16 ]

Confirmed for 1.9.4.

Comment by null (Inactive) [ 05/May/16 ]

Confirmed for 1.9.3-pre3.

Comment by Color Fusion [ 07/Apr/16 ]

Still able to reproduce in 16w14a, both by dropping and with commands. The command I'm using is:

    /tp @e[type=Item] 76 65 -112.1249
Comment by user-f2760 (Inactive) [ 07/Apr/16 ]

I seem to be unable to reproduce this in 16w14a, dropped an item, moved it by teleportation in portions of 0.00001 and it picks up at the spot where it is

Comment by null (Inactive) [ 23/Mar/16 ]

Confirmed for 1.9.1-pre3.

Comment by Nickolas Cosimo Cosentino [ 25/Feb/16 ]

This bug seems to be more apparent on servers that are less supported or have slower runtimes and lag. Which would make sense as a lot of servers can have lag spikes due to not having their arguments and times perfectly aligned with their clients'

Comment by Bren Rado [ 13/Feb/16 ]

When I saw this, I observed that the client will place the block back at the edge of the block and make it fall again, the cycle will repeat until the item despawns.

Comment by Color Fusion [ 11/Feb/16 ]

Still (16w06a) able to get this bug by just throwing items, though it does seem less common than before. Able to reproduce it 100% of the time by teleporting an item to just over #.875, which is on the edge of a block.

Comment by [Mod] Ezekiel (ezfe) [ 11/Feb/16 ]

grum, the only situation I commonly ran into the issue in practice was Apples and Saplings from tree. Will the changes in 06a alleviate these incidents?

Comment by [Mojang] Grum (Erik Broes) [ 11/Feb/16 ]

We changed some of the movement code reducing the frequency of the issue occuring.

There is no true fix for this until we get away from floats/doubles for entity positioning/movement or always send doubles over the wire (expensive).

Comment by [Mod] Ezekiel (ezfe) [ 11/Feb/16 ]

I was able to reproduce it in 16w06a, took a while though.

Comment by Fenhl (Max Dominik Weber) [ 10/Feb/16 ]

Appears to be fixed in 16w06a, or at least I can't reproduce by dropping items into a wall of cobwebs anymore. Can anyone confirm?

Comment by Fabian Röling [ 10/Feb/16 ]

The first attached file, the mp4, seems to be broken. I can't play it.

Comment by Fenhl (Max Dominik Weber) [ 09/Feb/16 ]

Affects 16w05b.

Comment by Fenhl (Max Dominik Weber) [ 29/Jan/16 ]

Affects 16w04a.

Comment by Fenhl (Max Dominik Weber) [ 28/Jan/16 ]

Affects 16w03a.

Comment by Sam Bone [ 24/Jan/16 ]

If it happens with glitched blocks it does really funny stuff, it glitches all over the place and if you reload it fixes it.

Comment by Fenhl (Max Dominik Weber) [ 14/Jan/16 ]

Affects 16w02a.

Comment by Fenhl (Max Dominik Weber) [ 17/Dec/15 ]

Affects 15w51b.

Comment by Fenhl (Max Dominik Weber) [ 03/Dec/15 ]

Affects 15w49a. This is now easy to reproduce by dropping items into a wall of cobwebs from the side.

Comment by Swekob [ 28/Oct/15 ]

Confirmed for 15w44a.

Comment by Swekob [ 25/Oct/15 ]

Confirmed for 15w43c.

Comment by Samuel Shank [ 22/Oct/15 ]

affects 15w43a

Comment by Spake Miner [ 02/Oct/15 ]

15w40b*

Comment by Color Fusion [ 02/Oct/15 ]

Still present in 14w40b 15w40b.

Comment by [Mod] Neko [ 28/Aug/15 ]

The code provided in MC-87565 seems to be a fix.

Comment by Anon Ymus [ 24/Aug/15 ]

The fix version indicates that a fix was attempted in 1.8.1-pre1, but it did not actually work.

Comment by Pierre Waldén [ 16/Oct/14 ]

Sadface
I hope you will be able to fix it and get it in to a pre-3 or somethging.
Good that you are working on it at least Searge.
We love you for trying to fix a bug as old as this one.

Comment by williewillus [ 16/Oct/14 ]

Made worse in some situations.

Test case
1. create 1x 7 water stream
2. Toss some items in. Notice how they jitter and flail more than they did in 1.8 (about as badly or worse than 1.7)
3. Now replace floor of stream with ice or packed ice. Toss items again. They flail even worse.

Most prominently, when they reach the end of the water stream, they seem to teleport back one block and re-flow.

I just want unglitchy undesynced items like 1.2.5 ssp

Comment by Thue [ 15/Oct/14 ]

The attached minecraft testcase world zip also still reproduces it. Might be the easiest way to consistently test.

Comment by [Mod] Ezekiel (ezfe) [ 15/Oct/14 ]

Reopened due too two confirmations.

Comment by [Mod] Ezekiel (ezfe) [ 15/Oct/14 ]

Also confirmed here: https://www.youtube.com/watch?v=xCZAA7_0f-8

Comment by [Mod] redstonehelper [ 15/Oct/14 ]

Sadly not fixed, affects 1.8.1-pre1: http://gfycat.com/WellgroomedNearAfricangoldencat

The world this happened in was created in 1.8.1-pre1.

Comment by Pierre Waldén [ 15/Oct/14 ]

searge: Wow!
When bugs that have been around this long (and with over 200 votes) gets fixed it gives some new hope!
Good job! This is a big step in the right direction!

Comment by [Mojang] Searge (Michael Stoyke) [ 14/Oct/14 ]

This issue is fixed for entities saved in 1.8.1 or newer. Loading older worlds can still have some entities with this issue in the world. Simply closing the world and loading it again should automatically solve the issue for those entities.

Comment by Andrew Thomas [ 05/Sep/14 ]

Confirmed for 1.8

Comment by PTR_91 [ 19/Aug/14 ]

Still occurs in 14w34b.

Comment by Maxwell Mcphearson Paradise [ 11/Apr/14 ]

This issue also occurs in Console Title Updates 14 and above (Technically update 1.4.7) So try and get some data from consoles as well.

Comment by PTR_91 [ 12/Feb/14 ]

it occurs even when not on the edge of a block in 14w06b
also items now (server-side) pop farther and through leaves (may be more blocks)
tested on iron and wood

Comment by branza [ 12/Feb/14 ]

@Alban Dalin: That's a different bug, MC-47650.

Comment by Alban Dalin [ 11/Feb/14 ]

This issue seems to become more important in the last snapshot : i fond many coal/lapis/redstone or cobblestone at place where i didn't comme before whereas i dont have any matter in the 14w04b (the last version i played).
Sometimes, when i mine in a safe place, i can hear my item burn in lava (even if the neer block of lava is a t 5-6 from me with a space totaly full of stone (so no air block).
For more precision, i often use my fortune III pickaxe. (hope my english is good enought to be understandable)

Comment by [Mojang] Grum (Erik Broes) [ 07/Feb/14 ]

This is a known issue, this issue is not going to get fixed soon.

This needs a major internal overhaul to get fixed (or some other cheating that causes problems elsewhere).

We know how it has to be fixed, but no all the places that are impacted are refactored enough so we can support such a change.

Comment by PTR_91 [ 07/Feb/14 ]

Confirmed for 06b, due to sir quartz

Comment by PTR_91 [ 30/Jan/14 ]

Confirmed for 14w05a, sapling decided to teleport.

Comment by PTR_91 [ 12/Dec/13 ]

Confirmed for 1.7.4... Annoying teleporting cobblestone.

Comment by Jesper the End [ 24/Sep/13 ]

It's probably because it's either too hard to fix and not worth it because there are more important bugs out there

Comment by 1234567 [ 23/Sep/13 ]

This is only the 4th Minecraft bug reported, it was reported years ago, and it still says "unresolved"?

Comment by Vrej [ 21/Sep/13 ]

Confirmed.

Comment by Caleb Tyler Tharpe [ 21/Sep/13 ]

Same with when im on a sky block server, if an item falls off the edge, when i go to the edge i grab it.

Comment by David Eshom [ 13/Aug/13 ]

@Jaqi Hegland
Singleplayer is nothing more than a small, personal server running inside the client. Singleplayer is just as much a server as Multiplayer is, making this quite possible even in a singleplayer environment.

Comment by Jaqi Hegland [ 01/Jul/13 ]

I'm a bit out on a limb here, because I don't know much about how the client/server relationship works, but that might not be the problem. I was having this issue occur when our internet was out for three days, so my desktop was the only machine involved. As I understand it, my desktop is the client and the server is whatever machine I connect to when I log in online, so perhaps this has a different cause than has been assumed.

Comment by Jaqi Hegland [ 26/May/13 ]

I've seen an oddity with spiders that I think may be the same thing. When they're bobbing up and down a vertical wall, sometimes they'll stop in one position and sit there, but when I try to hit them they aren't hit, and even though I'm in range for an attack, they don't hit me, but sit on the ground looking down as if I'm below them or something, and then after a few seconds they look at me and hit me simultaneously. If I keep swinging at them, they eventually get hit, but it seems like they're not in the spot where I'm seeing them for a while.

Comment by seth whitehead [ 25/May/13 ]

i always see this with paintings and, i don't know how i copied you this is a way different problem.

Comment by Aaron Loyd [ 08/Apr/13 ]

This can also apear with right/left side of blocks. If you get a item to be moved by water and it hits the edge of a block a ghost item appears and constanty is moved back.

Comment by 08Juan80 [ 26/Mar/13 ]

That's a way old bug that's not fixed yet.

Comment by Daniel "Glampkoo" [ 26/Mar/13 ]

Confirmed.

Comment by branza [ 26/Mar/13 ]

Still happening in 1.5.1.

Comment by Mr Dude [ 15/Mar/13 ]

I often have the same problem with painting drops.

Comment by Chloe Idun Anderson [ 04/Mar/13 ]

Can we get a confirmation of whether this happens in 13w10a and an update to the affected versions?

Comment by James Wright [ 12/Feb/13 ]

I've noticed that lately too, certain items travel with quite an unusually high velocity when broken. I've noticed Item frames and cobblestone fences personally. However, I don't think that it is part of this particular bug.

Comment by Chris Andrews [ 12/Feb/13 ]

I've seen something like this while knocking paintings or item frames off the wall. Sometimes they land quite far away from where you would expect them to land

Comment by Jesper the End [ 09/Feb/13 ]

yeah, I'm probably wrong then, because even if the velocity isn't sent the position of the drop should update after a while.

Comment by Moo [ 09/Feb/13 ]

@Jesper: The dropped-item being created at all is sent by the server, I think, so any velocity involved there should be sent by the server too. But as the items can be completely still, and still appear to fall when they shouldn't, I don't think it can just be related to spawn velocity.
@Thue: Yes, exactly what I was getting at. The server and client should both "think" the same way, and "talk" accurately enough that such problems are avoided.

Comment by Thue [ 09/Feb/13 ]

> Client predicting where the entity is VS server having it at another place. Not trivial to fix, will eventually be taken care of once the client stops having a mind of its own.

The funny thing about the attached save is that even after what are obviously client-server syncronization events, where the item jumps back up to where the server thinks it should be, the item still falls down again. So I would think that the problem is not the client thinking for itself about where the items land, but rather that the client's hitboxes differ subtly from the servers (or alternatively that the item position coordinates are not sent with enough precision).

Comment by Jesper the End [ 09/Feb/13 ]

@Moo when an item drops, it's velocity is random. So the velocity is different for the client and the server.
(at least that's what I think, correct me if I'm wrong)

Comment by Moo [ 09/Feb/13 ]

If the server and the client both have the same data about the entity, state of other things in the world, and "physics system", how can they get different results?
If they don't, isn't it just a case of altering whichever part is "wrong" in order that they do?

Comment by [Mojang] Grum (Erik Broes) [ 09/Feb/13 ]

Client predicting where the entity is VS server having it at another place. Not trivial to fix, will eventually be taken care of once the client stops having a mind of its own.

Comment by domi1819 [ 30/Jan/13 ]

still happening in snapshot 13w04a

Comment by Jesper the End [ 28/Jan/13 ]

When an item drops, it's velocity is random. To prevent all drops from being the same. So what mojang has to do is send the velocity to the client instead of just the position.
(Not sure though)

Comment by Paulquappe [ 13/Jan/13 ]

confirm this in snapshot 13w02b. delocation torches when placed on a block and block is destroyed. but it seemed to be much better than it used to be.

Comment by Maarten Thijs [ 13/Jan/13 ]

no, not item drops for me in this version. but xp is a disaster. xp appears at the wrong location

Comment by [Mod] Ezekiel (ezfe) [ 13/Jan/13 ]

Can someone confirm that this still occurs in the snapshots?

Comment by MisterSanderson [ 30/Dec/12 ]

Something like that occured to me now on 1.4.6: the sand blocks were dropped, but started "dancing" like they didn't knew where to fall.

Comment by nickyjefferz [ 14/Dec/12 ]

Lol, I designed the same sugarcane farm and recently started having this problem, It is very annoying; before I had a 95% collection rate, now its about 40%

Comment by Joël Fivat [ 04/Dec/12 ]

With the save file provided they can easily reproduce, debug and fix that.

Comment by Jesper the End [ 01/Dec/12 ]

I'm not sure how anybody can fix this

Comment by Joël Fivat [ 12/Nov/12 ]

Also attached a screenshot that shows how the item (green box) is positioned in relation to the blocks.

Comment by Joël Fivat [ 12/Nov/12 ]

Thanks a lot for the world. I edited it in MCEdit so we can easily reproduce and debug it. When loading
"Minecraft bug MC-4 testcase for debug.zip", we can see the sugar cane falling. We can't pick it up. If we exit and reopen, the sugar cane falls again. This is because the client is making it fall, when the server is making it stay on the block. I hope with this Mojang will be able to fix the problem.

Comment by Thue [ 08/Nov/12 ]

I have attached a world save with a sugarcane farm which reproduces this most of the time. Demo video: http://www.youtube.com/watch?v=S1IHkLQIqOs

Comment by Thue [ 08/Nov/12 ]

Click the button of the diamond sugarcane farm. Most of the time, there will be ghost items.

Comment by Thue [ 30/Oct/12 ]

Yes, water moves the ghost items on my sugarcane farm.

Comment by Joshua [ 30/Oct/12 ]

What if there is flowing water where the ghost item falls? Will this ghost item move?

Comment by Thue [ 24/Oct/12 ]

I have a piston-powered automated sugarcane farm which reproduces this very reliably.

Generated at Sun Jan 12 11:49:28 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.