When a non-player entity is riding another Mob. The Passenger's movement speed is used instead of the movement speed of the entity that is being ridden.
I already know that the mods know about this, however it was always brought up in an issue primarily about using the Passenger AI instead of the Ridden AI and so it was marked as resolved as the way the AI is controlled is working as intended. This issue pertains only to how movement speed is allocated rather than what AI controls the stacked entity.
This is observable in Skeleton Trap Horses, Spider Jockeys, Chicken Jockeys and any other combination of Mount a player summons into the game.
The best way to observe this is by summoning a stacked entity like so:
/summon zombie ~ ~ ~ {Passengers:[{id:"minecraft:zombie",Attributes:[{Name:generic.movement_speed,Base:0.05}]}],Attributes:[{Name:generic.movement_speed,Base:0.25}]}
The movement speeds of both Zombies have been changed so that the Zombie being ridden is much faster than its passenger. However, the slower movement speed applied by the Passenger Zombie is what's being used. By killing the Passenger, the ridden Zombie can now use its movement speed.
Linked issues
is duplicated by 1
Attachments
Comments 8
Still in 20w21a. Test with:
/summon minecraft:skeleton_horse ~ ~ ~ {SkeletonTrap:1b}
Skeleton horses move far slower than normal see MC-161108
This issue still persists in the latest 21w11a snapshot and official release of 1.16.4. It's a shame skeleton traps are just not as threatening as they used to be. If the ridden entity inherits the speed of the rider, couldn't you just increase the movement speed of the skeleton rider to bring back the original speed of the skeleton trap?
I cannot reproduce it using the provided command in current version and even in 1.14.2(with generic.movementSpeed). Has this bug really existed ever?
Skeleton horsemen are slow, just because the movement speed of the ridden entity (skeleton horse) is used, which means that this bug does not exist. So, MC-161108 was incorrectly marked as a duplicate of this. In fact, it is a duplicate of MC-159865.
MC-159865 describes the opposite of this issue, and I think MC-159865 is correct.
Can confirm for 1.14.4.