Mobs that are under the influence of speed modifiers, such as potions, are more affected by them than they should be.
The apparent reason in the game's code shows in the movementInputToVelocity function in Entity, called by applyMovementInput in LivingEntity.
public Vec3d applyMovementInput(Vec3d movementInput, float slipperiness) {
this.updateVelocity(this.getMovementSpeed(slipperiness), movementInput);
...public void updateVelocity(float speed, Vec3d movementInput) {
Vec3d vec3d = Entity.movementInputToVelocity(movementInput, speed, this.getYaw());
this.setVelocity(this.getVelocity().add(vec3d));
}private static Vec3d movementInputToVelocity(Vec3d movementInput, float speed, float yaw) {
double d = movementInput.lengthSquared();
if (d < 1.0E-7) {
return Vec3d.ZERO;
}
Vec3d vec3d = (d > 1.0 ? movementInput.normalize() : movementInput).multiply(speed);
float f = MathHelper.sin(yaw * ((float)Math.PI / 180));
float g = MathHelper.cos(yaw * ((float)Math.PI / 180));
return new Vec3d(vec3d.x * (double)g - vec3d.z * (double)f, vec3d.y, vec3d.z * (double)g + vec3d.x * (double)f);
}Each mob is given a movementInput forward value of whatever its speed attribute is, while for players it is usually 1. Since the speed attribute is multiplied by this value in applyMovementInput, this means this means that what is added to the mob's velocity is its movement attribute squared. Modifiers affect movementInput, so a 2x multiplier to the mob's speed attribute will cause a 4x increase in speed.
I made a video to demonstrate this behavior in vanilla 1.19.3. On the left is a normal zombie, in the middle is a zombie with slowness III (-45% speed), and on the right is a zombie with swiftness V (+100% speed). The swiftness zombie should reach the villager by the time the normal zombie reaches the halfway point, but the normal zombie only reaches about a quarter of the way through. The same happens for the slow zombie. The normal zombie should reach the villager when the slow zombie is a little past the halfway point, but instead the slow zombie makes it about a third of the way.
Attachments
Comments 8
I cannot seem to reproduce this in the latest snapshot, 24w18a. I also cannot seem to find the section of code outlined in the issue, indicating it has since been changed from the original report date (that is, unless you are using different mappings. I was using MojMap).
Here is my setup:
The zombie spawned on the left side has no active effects, and the one on the right has speed with an amplifier of 4 (total = speed V like in your test).
Can you still reproduce the issue? If so, it would be helpful to update the report with steps to reproduce that are up to date with the latest behavior in the game. Addressing any possible errors in my own personal test would also be appreciated. Here is the world download of my test, feel free to take a look:
[media]
With the attached test world I was able to reproduce the issue, I can confirm it in 24w18a now. I'm unsure what was wrong in my test to cause me to not be able to get the same result as you. Maybe because I applied the effect via nbt data and not a seperate command? I'm not sure.
I was able to recreate this in 24w18a in this test world:
[media]This world has two demonstrations. On the right, the zombies have their generic.movement_speed attributes set to 0.2 and 0.1. On the left, one zombie is given speed 5, while the other is unaffected. There are commands that log how long it takes for each zombie to reach the end. In both cases, the left zombie is twice as fast as the right zombie, but reaches the end nearly four times as fast.
In your test world, for some reason the speed effect was not applying to the zombies via the summon command, and both zombies were moving at the same speed. Using the effect command on a zombie after it is summoned works. That could be an unrelated bug.
When I first did a code review, I was on a 1.19 Fabric mod developer environment, which I believe uses Yarn mappings. That is what the code in the bug report is based on. I will try to look again for this code in 24w18a.
Thanks for the updated information 🙂
I'll look into the behavior of the effect not applying via the summon command, I may be a new issue if it's not been reported before.
The issue I ran into could have been MC-171688
You forgot to link/attach the video you mentioned.