| Type: | Bug | ||
| Reporter: | [Mod] Ezekiel (ezfe) | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 820 |
| Labels: | desync, item-entity, packet, precision-loss, server | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Category: |
Entities, Items, Networking
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Mojang Priority: | Low | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Area: | Platform | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
The bugWhen 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
Code analysisCode analysis by marcono1234 can be found in this comment. FixFix 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: 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 ] | ||||||||||||||||
|
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 | ||||||||||||||||
| 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:
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:
| ||||||||||||||||
| 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 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:
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. | ||||||||||||||||
| 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. 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. 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). 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. 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 | ||||||||||||||||
| 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.
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. 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. As I said I don't see through 100% yet, so I'm ready to be corrected | ||||||||||||||||
| 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). 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. 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. | ||||||||||||||||
| 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
| ||||||||||||||||
| 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? | ||||||||||||||||
| 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. Motion (for fireballs power)Variable type used: double
Yaw and pitchVariable type used: float
| ||||||||||||||||
| 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 ] | ||||||||||||||||
|
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. | ||||||||||||||||
| 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. | ||||||||||||||||
| 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. | ||||||||||||||||
| 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 | ||||||||||||||||
| Comment by [Mod] Neko [ 28/Aug/15 ] | ||||||||||||||||
|
The code provided in | ||||||||||||||||
| 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 | ||||||||||||||||
| Comment by williewillus [ 16/Oct/14 ] | ||||||||||||||||
|
Made worse in some situations. Test case 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! | ||||||||||||||||
| 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 | ||||||||||||||||
| Comment by branza [ 12/Feb/14 ] | ||||||||||||||||
|
@Alban Dalin: That's a different bug, | ||||||||||||||||
| 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). | ||||||||||||||||
| 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 | ||||||||||||||||
| 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. | ||||||||||||||||
| 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. | ||||||||||||||||
| 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? | ||||||||||||||||
| 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. | ||||||||||||||||
| 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 | ||||||||||||||||
| 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. |