Misleading VelocityData values

[RobertHerhold]

While testing out the newly implemented VelocityData, I found something odd: while at rest, the player's (entity's) velocity is: (0.0, -0.0784000015258789, 0.0). Obviously, the player should not have a downward velocity while at rest. When I jumped, I got the following output:

(0.0, -0.0784000015258789, 0.0)
(0.0, 0.41999998688697815, 0.0)
(0.0, 0.24813599859094576, 0.0)
(0.0, 0.16477328182606651, 0.0)
(0.0, 0.16477328182606651, 0.0)
(0.0, 0.08307781780646721, 0.0)
(0.0, 0.0030162615090425808, 0.0)
(0.0, -0.0784000015258789, 0.0)
(0.0, -0.230527368912964, 0.0)
(0.0, -0.230527368912964, 0.0)
(0.0, -0.30431682745754424, 0.0)
(0.0, -0.0784000015258789, 0.0)

And while these values make sense relative to each other, the issue still persisted. Additionally, while just moving around in general, the x and z components of the velocity vector never deviated from 0.

I used this plugin to test this. Is there something I'm missing, or...?

[JBYoshi]

I think the y value would be due to gravity?

[RobertHerhold]

But the entity is not moving down, so the velocity should not be anything but 0. I see what you're saying, but it doesn't make sense logically.

[ST-DDT]

@RobertHerhold Have you tested this with non-Player entities as well?

[DDoS]

I think someone mistook gravity for velocity...

[RobertHerhold]

@ST-DDT I just tested it with a minecart, and it's velocity is (0.0, -0.0, 0.0) when it is at rest

[JBYoshi]

In that case, blame the movement packet. Sponge could do some custom calculations server-side though.

[nickrobson]

I'm just going to go ahead and point out that you don't experience that behaviour in Vanilla or Bukkit, so it is definitely Sponge.

[gabizou]

Is this still broken?

[RobertHerhold]

@gabizou Yes. I updated the gist to the latest version of the API.

[simon816]

From testing the value is always -0.0784000015258789 at rest.

I have done some investigation and found out how this value came to be.

This snippet is in EntityLivingBase.moveEntityWithHeading, towards the end of the method

                if (this.worldObj.isRemote && (!this.worldObj.isBlockLoaded(new BlockPos((int)this.posX, 0, (int)this.posZ)) || !this.worldObj.getChunkFromBlockCoords(new BlockPos((int)this.posX, 0, (int)this.posZ)).isLoaded()))
                {
                    if (this.posY > 0.0D)
                    {
                        this.motionY = -0.1D;
                    }
                    else
                    {
                        this.motionY = 0.0D;
                    }
                }
                else
                {
                    this.motionY -= 0.08D;
                }

                this.motionY *= 0.9800000190734863D;
                this.motionX *= (double)f2;
                this.motionZ *= (double)f2;

motionY is 0 , then it subtracts 0.08 and multiplies by 0.98
-0.08 * 0.9800000190734863 = -0.0784000015258789

moveEntityWithHeading gets called as part of onLivingUpdate so this will happen for all living entities.

So either we leave this as-is directly from vanilla, change the method so that it's 0 at rest or check for this magic value in the velocity data processor and report velocity y as 0

[Zidane]

@nickrobson

Maybe not Bukkit but Vanilla has this issue as @simon816 points out above :P.

@simon816

Changing this in Vanilla isn't happening so I guess we can report this as "0".

[ryantheleach]

I get wanting to correct this, but this only fixes it for the rest state right? so wouldn't anything not at rest still be incorrect? or is it only because it's always colliding that the velocity is incorrect?

This seems like a nextVelocity value more then a velocity value.

[Zidane]

@ryantheleach Data always gives you the now so this is the velocity now.

[Deamon5550]

Non-rest states would be correct as the velocity does accurately represent the change in position. It is only once at rest that the velocity is not displaying as what it should be at rest (0, 0, 0).

Someone should double check that walking into a wall does not show a velocity into the wall though as this would not surprise me...(and our lives will get a lot more complicated if this is the case)

[JBYoshi]

@Deamon5550 I tested it, and here are my results:

• When the player moves on the ground, the X and Z velocities remain at 0, even when moving upwards via slabs/stairs.
• When the player jumps or falls, the velocity works properly (X, Y, and Z).
• When the player climbs a ladder, the Y velocity behaves as if the player was jumping (immediately jumps to a positive value, then decreases to -0.2254).
• When the player climbs a ladder while sneaking, the Y velocity remains at 0.
• When the player flies, the velocity initially works properly, but it soon approaches 0.
• When the player is riding a vehicle, the velocity remains at 0, and (in the case of a minecart) the vehicle moves at a constant speed.

Code:

package jbyoshi.sponge.test;

import org.spongepowered.api.data.key.Keys;
import org.spongepowered.api.event.Listener;
import org.spongepowered.api.event.game.state.GameStartingServerEvent;
import org.spongepowered.api.event.game.state.GameStoppingServerEvent;
import org.spongepowered.api.plugin.Plugin;
import org.spongepowered.api.service.scheduler.Task;
import org.spongepowered.api.text.Texts;
import org.spongepowered.api.text.chat.ChatTypes;

import javax.inject.Inject;

@Plugin(id = "jbyoshi.sponge.test", name="JBYoshi Sponge Test")
public final class SpongeTestPlugin {
    private Task task;

    @Listener
    public void stateChanged(GameStartingServerEvent event) {
        this.task = event.getGame().getScheduler().createTaskBuilder().intervalTicks(1).execute(() -> {
            event.getGame().getServer().getOnlinePlayers().forEach(p -> {
                p.sendMessage(ChatTypes.ACTION_BAR, Texts.of(p.get(Keys.VELOCITY).get()));
            });
        }).submit(this);
    }

    @Listener
    public void stateChanged(GameStoppingServerEvent event) {
        this.task.cancel();
    }
}