Using BetterCharacterControl with Y axis movement

I have a character control case where the player can transition into a free flying state (the gravity is set to near zero and the character can move up and down).

It’s basically similar to the flycam, but I want to take advantage of the BetterCharacterControl features.

My approach was to just alter adjust the player’s walk direction to include the Y axis (ie, just the cam’s direction):
if (up) {walkDir.addLocal(cam.getDirection().clone().multLocal(forwardSpeed));}

if (down){walkDir.addLocal(cam.getDirection().clone().multLocal(forwardSpeed).negate());}[/java]

But this causes the player to shoot quickly up/down - it’s like flying a plane with hypersensitive elevation. I think this code is the same as the flycam so I’m not sure what’s going wrong. I took a look at the BetterCharacterControl source but wasn’t sure where to look. Any ideas?

Could it be that the forward speed vector is a bit to large ? Cause generally we multiply the camDir by a very low value like multLocal(.1f,.1f,.1f) to slow down the character movement

Also, your effective direction vector will be considerably longer than unit length (in most cases) when you just add them together without renormalizing.

And while I’m here, this:

Is a little bit overkill when this:

…does effectively the same thing.

…and while I’m on the subject:

Is the same as:

Thanks guys. I still get the same problem when normalising the cam direction. I also tried slowing down the forwardSpeed, but the problem persists (albeit slower).

What happens if you just set the walk dir to the camera dir?

No change - the walkdir vector is zeroed at the start of the function anyway. Here’s the full code:

[java]walkDir.set(0, 0, 0);

if (left) {walkDir.addLocal(cam.getLeft().mult(strafeSpeed));}

if (right) {walkDir.addLocal(cam.getLeft().mult(-strafeSpeed));}

if (up) {walkDir.addLocal(cam.getDirection().normalize().mult(forwardSpeed));}

if (down) {walkDir.addLocal(cam.getDirection().normalize().mult(-forwardSpeed));}


Well, for starters this isn’t the same as fly cam because fly cam has no physics. It doesn’t move unless you tell it to.

That aside, I know nothing about the player control but presumably it already has some notion of speed? In which case you are still doubling it.

What I meant was try setting playerControl.setWalkDirection( cam.getDirection() ) which is considerably different than the code you’ve posted.

Ugh, also, you aren’t normalizing the resulting vector you are normaling the already normalized cam direction… which isn’t really what you want but the walk dir was already zeroed for that case. I still think it’s wrong to put the speed in the walk dir. I don’t know the better character control but if it’s walk direction is not supposed to be a unit vector then it’s a horribly named property.

Actually, I’m 99% sure that the problem is that you keep multiplying the direction vector by speed when speed is already considered in the calculations (and properly scaled for frame rate). So stop doing that and it should fix your problem.

Yep, I tried setting the walkDir to cam.getDirection(), but it still moved the same way, though at a tiny speed.

I think walk direction needs to be a speed vector though - here’s the javadoc from BetterCharacterControl:

[java] /**
* Sets the walk direction of the character. This parameter is framerate
* independent and the character will move continuously in the direction
* given by the vector with the speed given by the vector length in m/s.
* @param vec The movement direction and speed in m/s

So what exactly is the problem?

Is your concern that you keep moving or that you move too fast? I’m confused now because you say you move too slow. I’d expect you to keep moving because now there is no friction.

…and yes, based on the javadoc walkDirection is a poorly named method since you are really setting walk velocity.

When I say it’s moving to slow, it was in response to passing cam.getDirection() as the walkdirection vector, rather than cam.getDirection().mult(speed).

What I want to happen is similar to the flycam - point your crosshairs at a target, push forward, and you head toward it. I know flycams are different to physics objects, but I want to replicate this behaviour with the physics object if I can.

But it behaves differently - basically, the player moves very rapidly up or down the Y axis, even though the camera has moved only a small amount. Imagine being in a plane flying dead level toward the horizon, then pulling the stick back very slightly, and the plane quickly starts ascending, even though you’ve just barely moved the stick.

From the javadoc:

Forces in the local x/z plane are dampened while those in the local y direction are applied fully (e.g. jumping, falling).
1 Like

Blimey, can’t believe I missed that. Setting the damping to 0 sorted it out. Thanks for the help folks.