Mouselook and Flight Assist

Something interesting.. and forgive me if this is "over the heads" of a number of you.

I built a flight assist. I'm pretty proud of it actually. It increases the flight ceiling (as it should) has variable speeds, and works perfectly fine in 3rd-person.

But in mouselook, I can't break the 200-300m ceiling. That is to say, at a high altitude, pressing "forward" will fly me in the direction I'm looking.. but it won't fly "up" when I look up. I can press "up" and I'll fly up.

Below 200-300m, I can look up, and press forward, and fly up. The impulse I'm using is this.

llApplyImpulse(<1,0,0> * speed * llGetMass(), TRUE);

When I press up, I apply impulse like so:

llApplyImpulse(<0,0,1> * speed * llGetMass(), FALSE);

Now, I checked this in other flight assists I have, Xflight has the same limitation. The flight feather (1.2.1) actually seems to lose altitude. MystiTool's flight assist, however, seems to be able to mouselook-fly up, regardless of altitude.

Any suggestions on what might be the fix? Some sort of manual multiplication with the llDetectedRot of the agent, and llApplyImpulse with the "local" set to false?

Actually, here's what I've worked out so far.. it's working "somewhat".. but as should be fairly obvious, it's "snapping" to 45 degree angles. (thanks to my "translation" set of if's).

thrust(vector input)
{
    integer status = llGetAgentInfo(llGetOwner());
    if(status & AGENT_FLYING) 
    {
        if(status & AGENT_MOUSELOOK)
        {
            vector rot = llRot2Euler(llGetRot()) * RAD_TO_DEG;
            vector outRot;
            if (rot.x > 0) outRot += <1,0,0>;
            else if (rot.x = 0) outRot += <0,0,0>;
            else if (rot.x < 0) outRot += <-1,0,0>;
            if (rot.y > 0) outRot += <0,1,0>;
            else if (rot.y = 0) outRot += <0,0,0>;
            else if (rot.y < 0) outRot += <0,-1,0>;
            if (rot.z > 0) outRot += <0,0,1>;
            else if (rot.z = 0) outRot += <0,0,0>;
            else if (rot.z < 0) outRot += <0,0,-1>;
            llApplyImpulse(llGetMass() * outRot * factor, FALSE);
        }
        else llApplyImpulse(llGetMass() * input * factor, TRUE);
    }
}

At this point, the next problem would seem to be turning the actual rotation into a series of "+1 to -1" floats in a vector.. So let's have a look at Radians.

I am not sure what you are exactly trying to do but can't you just use llApplyImpulse( factor * llGetRot(), FALSE ); ?

llGetRot returns a 4-float rotation.
llApplyImpulse requires a 3-float vector.

Okay here's where I'm at now...

thrust(vector input)
{
    integer status = llGetAgentInfo(llGetOwner());
    if(status & AGENT_FLYING) 
    {
        if(status & AGENT_MOUSELOOK)
        {
            vector rot = llRot2Euler(llGetRot()) * RAD_TO_DEG;
            llApplyImpulse(llGetMass() * rot / 360 * factor, FALSE);
        }
        else llApplyImpulse(llGetMass() * input * factor, TRUE);
    }
}

The problem I'm running into now, is that I don't seem to be getting the "right" impulses. I'm considering dividing by 180, and then subtracting <1,1,1>... This is so over my head.

Part of the issue, is that "rotation" isn't really directional data. Here's an example. Facing "east" is actually a rotation on z, like so: <_,_,0>

Yet to get impulse to PUSH east, you need <1,0,0>

so that ("rotation.z" = 0) has to translate into ("impulse.x" = 1)

I can see this requiring quit a bit of strange math. There's GOT to be a more logical approach to this.

thrust(vector input)
{
    integer status = llGetAgentInfo(llGetOwner());
    if(status & AGENT_FLYING) 
    {
        if(status & AGENT_MOUSELOOK)
        {
            rotation rot = llGetRot();
            llSetText ((string)(input / rot), <1,1,1>, 1);
            llApplyImpulse(llGetMass() * (input / rot) * factor, FALSE);
        }
        else llApplyImpulse(llGetMass() * input * factor, TRUE);
    }
}

THIS is looking promising, but Y seems to be inverted.

Just try it...

llApplyImpulse( llGetMass() * input * llGetRot(), FALSE );

If I may intrude...

vector impulse = <speed, 0.0, 0.0> * llGetRot();

That will convert your rotation into a direction vector.

If in mouselook, you use:

vector impulse = <speed, 0.0, 0.0> * llGetCameraRot();

You should be able to push yourself in any direction the camera is pointing, including up and down.

Don't ask me why <x, 0, 0>, I hate the rotations...

Does not compile.



Results.... Can't maintain altitude properly. Falls 10x faster than it should, or climbs faster than it should.

thrust(vector input)
{
    integer status = llGetAgentInfo(llGetOwner());
    if(status & AGENT_FLYING) 
    {
        if(status & AGENT_MOUSELOOK)
        {
            llApplyImpulse( llGetMass() * input * factor * llGetRot(), FALSE );
        }
        else llApplyImpulse(llGetMass() * input * factor, TRUE);
    }
}

For the record, when the forward key is pressed, "input" is <.25,0,0>

Gonna try changing that to 1, and see if there's some voodoo with the math going on.


----------

Okay did that, didn't see any major change, BUT I noticed another issue. When I let up on the controls, I stop moving forward, but I sort of "downcurve" or "upcurve" depending on which way I was going.

if I was flying down at an angle, letting go of [fwd] stops my forward movement, but I continue downward for a second or so. If I was flying upward at an angle, letting go of [fwd] stops forward movement, but I continue upward for a second.

You don't have to differentiate. You can just use the camera rotation. At least that's what I did. I spent a great deal of time getting all the details of flight assist down. I remember making the camera rotation change but don't remember why. I wish I had kept better notes about why I did things.



Because that is "forward". To apply a force "to the right" of where the camera is pointing, you'd use <0,speed,0>*llGetCameraRot(). That's only useful for shift-rightkey movement unless you want to move in circles.

This is SL's normal movement. Your flight control doesn't disable it, it just makes it less important. Until you release your control. Then you find that some of your movement was still being handled by normal SL control.

It's not difficult to counteract this movement, but doing so has side-effects that I can't figure out how to eliminate. You'll find my discussion about it here...

/54/81/135024/1.html

That doesn't seem like what's happening at all.

I have my flight assist currently NOT passing controls.. which should mean that I'm ONLY flying through the action of the impulses I'm applying.

The following ONLY happens in mouselook.

diagram:

thrust(vector input)
{
    integer status = llGetAgentInfo(llGetOwner());
    if(status & AGENT_FLYING) 
    {
        if(status & AGENT_MOUSELOOK)
        {
            rotation rot = llGetRot();
            llSetText ("", <1,1,1>, 1);
            llApplyImpulse( llGetMass() * input * factor * rot, FALSE);
        }
        else llApplyImpulse(llGetMass() * input * factor, TRUE);
    }
}

Okay, here's how it currently stands...

The up/down curve in mouselook persists, but here's a new symptom. I don't "take" controls for slide-left or slide-right. (nor rot-left or rot-right). In mouselook, if I press Left, my avatar slides to the left. If I press right... I slide right AND downward at a steep angle.

And then I posted about it... played with it a bit more, and it stopped.

And now the left arrow does it.

Now the right arrow. Doesn't seem to be relevant to which way I'm facing either.


Addendum: the angle flight issue DOES happen when Up and Fwd are pressed OUT of mouselook. so.. weird.

Well, what is your method of hovering in place? That might be what is affecting it.

EDIT: OH!

I just remembered! There is a bug with anti-gravity on attachments, I remember that I had a LOT of troubles getting full anti gravity on my attachment aircraft but no matter what it seems to be a simulator side issue. I have the same problem, so you might want to use llMoveToTarget and/or constantly move towards a target instead of doing impulses/forces.

llSetForce(<0,0,9.8> * llGetMass(), FALSE);

You don't need to apply an impulse to hover. You can just set buoyancy.

My impression, based on past experience, is that buoyancy is far flakier.

But just to be sure, I went ahead and replaced my hover with llSetBuoyancy(1) and the problem with the curving is still there.

Sort of. The flying toggle is outside the reach of llTakeControls. The system will still see you as hovering, so the built-in compensations are still going to be fighting against you.