Item drops sometimes appear at the wrong location

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.

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

I'm not sure how anybody can fix this

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

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%

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.

Can someone confirm that this still occurs in the snapshots?

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

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.

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)

still happening in snapshot 13w04a

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.

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?

@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)

> 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).

@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.

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

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

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.

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

I often have the same problem with painting drops.

Still happening in 1.5.1.

Confirmed.

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

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.

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

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.

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.

@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.

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.

Confirmed.

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

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

Confirmed for 1.7.4... Annoying teleporting cobblestone.

Confirmed for 14w05a, sapling decided to teleport.

Confirmed for 06b, due to sir quartz

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.

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)

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

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

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.

Still occurs in 14w34b.

Confirmed for 1.8

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.

@unknown: 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!

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

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

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

Reopened due too two confirmations.

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

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 😞

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 @unknown.
We love you for trying to fix a bug as old as this one. 🙂

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

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

Still present in 14w40b 15w40b.

15w40b* 🙂

affects 15w43a

Confirmed for 15w43c.

Confirmed for 15w44a.

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

Affects 15w51b.

Affects 16w02a.

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

Affects 16w03a.

Affects 16w04a.

Affects 16w05b.

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

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?

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

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).

@unknown, 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?

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.

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.

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'

Confirmed for 1.9.1-pre3.

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

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

Confirmed for 1.9.3-pre3.

Confirmed for 1.9.4.

Confirmed for 16w20a.

Confirmed for 16w21a.

Confirmed for 16w21b.

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]}

Confirmed for 1.10-pre2.

Confirmed for 1.10 with the command by @unknown. 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.

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.

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

@unknown 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

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

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

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

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?

http://reddit.com/r/Mojira

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

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

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.

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

Yaw and pitch

Variable type used: float

@unknown Is fixing the oldest open bug a hint that 1.11 will be a bugfix update? 😃
@unknown 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. 😉

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

@unknown: 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

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

@unknown, 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 @unknown'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.

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.

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

Still an issue in 16w32a

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

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

Nevermind, still not fixed.

: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

@unknown 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.

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

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

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.

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 @unknown

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)

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.

@unknown 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.

Confirmed for 16w39a

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

Confirmed for 16w44a.

THIS IS MC-4. FIX THE BUG ALREADY.

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.

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

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

Confirmed for 1.11.

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

Confirmed for 17w17a

Confirmed for 17w17b

Confirmed for 1.12 - Pre-release 5

Confirmed for 1.11.2

@unknown, 1.11.2 was already marked as affected

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.

@unknown - Every bug is a bug and it should be fixed, (unless @unknown 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 @unknown's video if you haven't.

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

@unknown 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.

Please take any further discussion to the Mojira reddit.

Can confirm in version 1.12. Occurrence most at leaves

The command provided does not work in 18w11a.

1.13-style command format is: /summon minecraft:item ~ ~1 ~-0.6249 {Item:{id:"stone",Count:1b}}

Affects 18w14a

Affects 18w14b

Affects 18w15a

Affects 18w16a

Affects 18w19a

Affects 18w20a

Affects 18w20b

Affects 18w20c

Affects 18w21a

Affects 18w22b

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}}

Affects 1.13-pre1

Affects 1.13-pre2

Affects 1.13-pre2

Affects 1.13-pre4

Affects 1.13-pre5

Affects 1.13-pre6

Affects 1.13-pre7

Can confirm for 1.13-pre10.

Can confirm for 1.13

Confirmed for 18w30a.

Confirmed for 18w31a.

Confirmed for 18w32a. What an old bug!

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?

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.

Confirmed for 18w33a.

Confirmed for 1.13.1.

Confirmed for 1.13.2-pre1.

Confirmed for 1.13.2-pre2.

Confirmed for 18w45a.

Affects 18w46a

Affects 18w47a

Affects 18w47b

Affects 18w48a

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

Affects 18w49a

Affects 18w50a

Affects 19w07a

Affects 19w12b

Affects 19w13b

Affects 19w14a

Affects 19w14b

Affects 1.14pre2

Affects 1.14

Affects 1.14.2-pre2

Affects 1.14.2-pre3

Affects 1.14.2-pre4

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

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.

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.

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.

Affects 19w38b

Affects 19w39a

Affects 19w40a

Affects 19w41a

Affects 19w42a

Affects 19w44a

Affects 19w46b, can I request ownership?

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

Affects 1.15pre2

Affects 1.15pre6

Confirmed for 20w08a

Affects 20w14a, can I request ownership?

I would like to keep the ticket

I tested and the bug affects 20w16a.

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

Affects 20w21a.

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

Affects 1.16 pre-release 2

Confirmed in 1.16-pre5.

Confirmed in 1.16-pre6.

Confirmed in 1.16-pre7.

Affects 1.16-pre8

I can confirm 1.16-RC1

confirmed in the full 1.16 release

Affects 1.16.1

Affects 20w27a

Affects 20w28a

Affects 20w29a

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

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

affects 1.16.2 pre-2 and pre-3.

affects 1.16.2 Release Candidate 1. Like please fix.

also affects combat test 6.

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

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

affects  {1.16.2 Release Candidate 2}}

affects +_*{color:#ff2b00}1.16.2 (full){color}*_+

^{Affects Combat Test 7c} 😞 

@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.

Cannot reproduce in 1.16.3

did you use the command?

I also can't reproduce. Tested with the command

Hello!

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

Also can't reproduce in 1.16.3 using the given command

Thanks, @unknown, 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.

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

Ok thanks Ezekiel

@unknown 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+ @unknown 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

Can reproduce in 1.16.3 with the new given command.

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

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

Still in 20w45a

Still able to fully reproduce.

Can confirm in 20w48a.

Can confirm in 20w49a.

Can confirm in 20w51a.

I confirm.

Can confirm in 21w03a.

Can confirm in 21w05a.

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.

Can confirm in 21w05b.

Can confirm in 21w06a.

Can confirm in 21w07a.

Can confirm in 1.16.5.

Can confirm in 21w08b.

Can confirm in 21w10a

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

Confirmed in 21w11a

i just didnt try enough times

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

Can confirm in 21w14a.

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.

Can confirm in 21w15a.

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

Can confirm in 21w17a.

Some explanation with video

Minecraft version 1.16.5 and server too

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

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

Can confirm in 1.17.

Can confirm in 1.17.1 Release Candidate 1.

Can confirm in 1.17.1. 

Can confirm in 21w37a.

Can confirm in 21w40a.

Can confirm in 21w41a.

I could confirm in 21w42a, 21w43a

Can confirm in 1.18.1.

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?

Affects 1.18.2

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.

@unknown 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.

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.

@unknown 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.

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).

Confirmed for 22w12a.

Appears to be fixed in 22w13oneblockatatime

Can confirm in 1.19.

can confirm for  22w12a.

Can confirm in 1.19.1.

Can confirm in 1.19.2.

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

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.

Still reproducible in 1.19.3 Release Candidate 1.

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

Can confirm in 1.19.3

Relates to MC-258368

Almost the same (videos attached)

Can confirm in 23w03a

Can confirm in 23w04a

Can confirm in 23w06a

Can confirm in 23w07a.

Can confirm in 1.19.4

still in 23w13a

Can confirm in 23w17a

in 23w18a

in 1.20-pre6

Can confirm in 1.20

Can confirm in 1.20.1

Can confirm in 23w31a

Can confirm in 23w32a

23w35a

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.

@unknown: 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.

Can confirm in 23w43a

Confrimed at 1.20.5 Pre-release 1

Can confirm in 1.20.6 & 24w20a

Can confirm in 24w33a

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.

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

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.

Confirmed in 1.21.4 

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.

Confirmed in 1.21.8

Can confirm in 25w44a