Mojang Math.

[HashtagShell]

So I was looking at the code for elytra motion, and I found this:

In net.minecraft.entity.EntityLivingBase#moveEntityWithHeading, in the isElytraFlying() if-clause, this happens:

Vec3d vec3d = this.getLookVec();
float f = this.rotationPitch * 0.017453292F;
double d6 = Math.sqrt(vec3d.xCoord * vec3d.xCoord + vec3d.zCoord * vec3d.zCoord);
double d8 = Math.sqrt(this.motionX * this.motionX + this.motionZ * this.motionZ);
double d1 = vec3d.lengthVector();
float f4 = MathHelper.cos(f);
f4 = (float)((double)f4 * (double)f4 * Math.min(1.0D, d1 / 0.4D));
this.motionY += -0.08D + (double)f4 * 0.06D;

Looking at javadocs and stuff, getLookVec() returns a normalised vector.

A few lines later, the length of that vector is calculated, and further down the line used in computations.

 

Isn't the length of a normalised vector always 1?

[xXWitherBossXx]

Yes, the length of a normalized vector is always one. However, in this page I found, http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/modification-development/1434994-how-to-get-the-x-y-z-of-the-block-the-player-is, it appears that you have to add .normalize() to getLookVec to get the normalized version. (look at the first reply) However, this was in 1.6.4 and this may have changed, I don't know. If it has not changed, that means that getMin will not always return 0.4.

[HashtagShell]

That may be the case, but there are other grave inefficiencies in the code. When you look at the variables' values after this block of code, you will find that two will have the same value (I think f4 and d6) and are calculated differently (=overhead). I made a more efficient version of it with a little hacked together benchmark (https://gitlab.com/snippets/1657880). 

Mojang Math.