Passenger Entities get dismounted client-side when rerendered

Confirmed. It's a client-server desinс, because if you make the boat fall, skeleton stays on the same place, but /tp sends you to the boat (where the skeleton actually is). Also, if the skeleton is far from the boat, you can't hit it.
Relates to MC-91290

Confirmed for

• 16w06a

The Skeleton does not have to have NoAI:1b

Could be also caused by fix of MC-91857

This bug still exists in 1.9 pre-release 1

As stated in MC-98066 the entity also doesn't move with the ridden entity

This is still very much a problem and very easy to reproduce. To reproduce, join a LAN server with a friend, ask them to get into a boat, walk far enough away so the entities are despawned in the client, then move back into visible range - you'll see the passenger in a fixed position with the boat moving and only the passengers head updating.

The issue lies in chunk sending, it appears the server sends the entity spawn packets correctly, but the server does not send the PacketPlayOutMount correctly (it never gets sent, it's only sent when you are within the entity-range when the passenger is set/vehicle is mounted).

Would love to see this fixed. 🙂

Confirmed for 1.9, I really need this fixed.

@@unknown: This was already confirmed for 1.9.

This is a major pain with the Skeletal Horse Riders. You'll be shot by an invisible skeleton, because the skeleton is being rendered somewhere completely different. That makes shooting the rider off the horse rather difficult.

Confirmed for 1.9.2.

Fixed for 16w15b

@unknown Not fixed for me, I went out of render distance, then back, and the skelly in the boat of the OP's test command is standing upright, not sitting anymore.

Screenshot attached.

Confirmed for 16w15b

I edited the bug description a bit to show, that every entity is affected by this and added another example.

This is a really essential bug with the new Passengers-Tag.

For your FallingSand example: Since the Time tag of FallingSand is now correctly an Integer, you can set it to -2147483648 to make sure it does not despawn so fast.

So how exactly can we turn mojang's attention to this issue? since it basicly breaks mounted pvp it doesn't make any sense for a serwer owners to update to 1.9. Or are there any plugins that can fix it?

All you can do is vote for the issue.

Confirm for 1.9.3 pre-2 and when I go close to the skeleton I get this warning message in the Game Output [Client thread/WARN]: Received passengers for unknown entity

Confirmed for 1.9.3-pre3.

@unknown that one is already marked as affected.

I don't see pre-3 on the list... It was only just released.

Most likely because the passenger mobs are getting loaded before the ridden mob.

Oh, sorry, mistakely read 2 instead of 3. facepalm

Confirmed for Release 1.9.3... sigh Was really hoping this would be fixed already...

Yes, it is indeed very annoying for a whole bunch of things.
Btw: You are really fast in this. I just came back home and wanted to test it in 1.9.3 and eventually update my bug report...

Ha!
Added 1.9.4 to Affected Versions 😛
@unknown I cannot confirm that game output.

Please link to this comment in the description

The following is based on a decompiled version of Minecraft 1.9 using MCP 9.24 beta.

The reason why this happens is that currently a SPacketSetPassengers packet is only send when an entity is created or when the passengers changed. The method net.minecraft.entity.EntityTrackerEntry.updatePlayerEntity(EntityPlayerMP) should send a passengers packet as well when it sends a spawning packet to the client. This will probably send two passenger packets when an entity with passengers is spawned, because the method net.minecraft.entity.EntityTrackerEntry.updatePlayerList(List<EntityPlayer>) will notice a difference. To fix this the constructor could set the tracked passengers list (field net.minecraft.entity.EntityTrackerEntry.field_187263_w) because the method updatePlayerList(List<EntityPlayer>) would send a passengers packet. Besides that it might be pretty inefficient to test all the time if the passengers list changed. Instead it could be event based.

Note: Fixing this only by using the provided solution will cause MC-90683. This means both bugs should be if possible fixed at once.

We really need this fixed in 1.9 before 1.10 or it'll stay consistently screwing with tons of stuff until 1.10 is released 😞. Some things it messes with for example is one of the only method left in 1.9 to keep entities in place without moving, which is putting the entity on something that does not move. With this, that method is no longer usable in non-spawn chunks

Yes. The ting that rally bugs me is that this is not only a bug mapmakers have to deal with but also a bug that effects vanilla frequently. That should have been more than enough to fix it before the release of 1.9. And it is still in 1.9.4.
Also 98 votes is a lot and therefore it should have a high priority. There is even a nice guy that did some code analysis for them (Thank you btw, @unknown).
But, well, I am not Mojang and it is not on me to decide this kind of stuff.

Can confirm.

Really annoying if you want to make a boat race on ice, you permanently crash into other players who stay on the road.

This bug is a great barrier for mechanisms development 😞

Confirmed for 16w21b.

Seems like this should be much higher priority to be fixed before 1.10 - perhaps almost one of the highest priority bugs? Insanely game-breaking for both servers and single-player, as it can be difficult to tell if a mob is supposed to have a rider and can result in players being caught unaware by players or monsters that are invisible to the client while riding other entities. It's a terrible game experience to be killed by an invisible skeleton shooting arrows at you or thinking a horse in a multiplayer server is just a wild horse and walking up to it and getting killed by an invisible player who was riding it.

Added attachment: dUWBZQ1.png

A demo of this happening on a multiplayer server (with a custom plugin but none relevant to this issue).

The arrow is shot by the "Elven Horserider", which is actually riding the horse but is desynced on the client to be floating in place. Thus the arrow comes from above the horse, but the passenger entity that shoots the arrow is in a totally different place.

Confirmed for 1.10 pre-2.

sigh Confirmed for 1.10... Can this please be fixed already? It should honestly be a higher priority than a lot of these other bugs that have been getting fixed. This actually affects survival gameplay as well!!!

There appears to be a general problem at Mojang with assigning bugs to someone who will work on it. If you search for bugs that are not Resolved and order by Votes (Advanced search: Status != Resolved ORDER BY Votes) then you'll see that of the top 10 voted bugs only 3 have been assigned. Of the top 20 only 4 are assigned. Of the top 50 only 15 are assigned. This bug is currently 7th in this list.

[Edit: Pestering via youtubers is a bad idea]

Wait... why did my comment get deleted? I didnt say anything wrong.
I just sighted and said that 209 votes are a little something.

@unknown I already saw YTs mention that bug, e.g. samasaurus6.

This is not a discussion forum.

This bug most annoyingly also affects Villagers in Minecarts. This messes up my Minecart-based villager trading hall. Often when I send a villager on its way it looks like only the minecart is moving and the villager stays behind. Not so! This is the bug in action. To avoid confusion (and possible further complications) I need to move away far enough and then come back to have the villager show up in its proper place, namely in the minecart.

This bug of course also affects other mobs in minecarts.

(Sorry mods for getting a tad meta, but it's important imo)
@unknown I'm absolutely against involving big YTers who don't know what they're talking about for bugs; it only makes their followers/fans pester the Devs and gets them under pressure (it happened already on several occasions).

Big YTers seem to not rarely have connections to Devs anyway and might tell them, but I know for a reason that YTers who don't know in what way a bug affects the whole game or even call some of the bugs a "feature" do no good at all, quite the opposite, as their fans take it for granted and then rage as soon as it's removed/changed (or if it is not removed/changed soon enough, if at all).

If someone who actually knows what he is talking about like Panda4994 makes one of his "bugs and fixes" videos, or someone from the CommandBlock community who uses riding mobs for their contraptions and knows what he/she is talking about, that's another talk, but please don't have YTers with high influence but zero technical/code knowledge blabber about such topics, it gets me furious each time.

I also wish this bug would have been fixed for 1.10 release, as it affects both Survival as well as Creative, but it can't be helped it isn't.

If highly ranked bugs have not been fixed yet, there must be a good reason for it.

If you want to discuss and complain about it, open a Minecraft Reddit post to complain about it not being fixed, if it gets many upvotes, the Devs might see it as well.

@unknown you make a good point. Edited my post accordingly.

Well, I actually thought that this was exactly for discussing bugs to give Mojang an idea of how a bug effects the game. But I guess it is not really wanted to point out things, that are pretty obvious and dont really add something, then.
I wont go to reddit, I think that's pointless. If so thinks it helps, they can still do it.
So let's stop this at that point, I guess.

@unknown: Of course the comment section of the tickets is for discussion about the bugs but not for any meta discussion about why this bug isn't fixed, how many votes it has, how much that bug annoys you and so on.

This is indeed a bug that just has to be solved.
I tried some things to get it fixed. But they did not work.

Examples:
Give both entities the same Rotation - Nope, doesn't work.

Using a directions MCEdit filter by NanoRex to detect where the bottom entity is looking. Then update the rotation of the passenger to the same way the bottom entity is facing. - Doesn't work either.

tp the passenger to the bottom entity - This works a bit, but it makes the passenger turn all over the place.

I need this to be fixed for my Pokémon map where Pokémon (Custom 3D Models) are just walking and flying around.

Confirmed for 1.10.2

really freaking annoying and weird when it happens to skeleton traps, it's as if it has a slight chance to pacify them too.

1.10.2 also, breaks my pvp server. Literally unplayable as everyone at some point becomes just a horse/donkey.

@@unknown: You have been warned before. Don't make us take further action.

OMG YES THANK YOU

Spreading love!

Thanks! ;D

Love you.

Tested in 16w32a with a Skelly sitting in a boat; went out of render distance, went back, Skelly sits still in there as it is supposed to }=)
So I'd say confirmed fixed, also read other reports it's fixed for them.
Thank you!

Some players with Windows and Mac clients still seeing this (as MC-98683) in 1.10.2
(Ignore this - I mis-read the Fix Version)

@Kevin It's fixed in 1.11, not for 1.10.2