[SOLVED] Scripting vehicles. Keyboard sensitivity

[Anna Nova]

I'm trying to mod a helicopter script, to use it for another, much larger helicopter.

Basically it now works, but I have a problem with the sensitivity of the script to the arrows and page up/dwn keys.  It is far too sensitive, and overshoots my target.  I have pushed the Operating System keyboard repeat sensitivity to slow (and fast) and this makes no difference.  And I cannot find anything in the script that seems to be related to this.  Can anyone point me at an LLSOMETHING()  page I should read?  Or something to search for?

I can't really show you a copy of the scripts, as they are not mine to release publicly.  Grateful for any tips.

Edited January 23, 2019 by anna2358

[Innula Zenovka]

Since you can't show us the script, there's a limit to what I can suggest, and I'm not sure I can visualise what you're doing in the script that's causing the difficulty.

I see there's a free helicopter script at https://www.outworldz.com/cgi/freescripts.plx?ID=377    Maybe you could play around with that,  particularly the control event.   And if it doesn't work as you want, then we could work on that example rather than your script.

[Rolig Loon]

As Innula says, it' s hard to know what it going on without seeing the script.  Still, it may be something a simple as the way you are handling the forward and reverse control commands.  If you have scripted them to respond when the arrow keys on your keyboard are held, rather than just when touched, they could easily run away fast.

if you write

if (level & edge & CONTROL_FWD)
{
    // Do something
}

then your script will "Do something" only when you first touch the forward arrow.

However, if you write

if (level & ~edge & CONTROL_FWD)
{
    // Do something
}

or just 

if (level & CONTROL_FWD)
{
    //Do something
}

then your script will keep doing "something" as long as the key is held down.  If that's the case, and if the "something" looks like

X_motor += 10.0;

then your forward speed will keep increasing faster and faster the longer you long the key down.  So, there are a couple of solutions.  One is to script the controls to respond only on the first click.  Another is to change the "something" to

X_motor = 10.0;

so that the forward speed stays at a constant 10.0 regardless of how long you hold down the key.  The third option is to script the control with a built-in governor

if (level & CONTROL_FWD)
{
    X_motor += 1.0;
    if (  X_motor >= 15.0 )
    {
        X_motor = 15.0;
    }
}

So, when you hold down the forward arrow key, your vehicle starts moving slowly and then gathers speed until it reaches X_motor = 15.0 and doesn't go any faster after that.  You have to mess around with things experimentally to determine how rapidly to let speed change and where to cap it, but that's the approach.

Edited January 23, 2019 by Rolig Loon
typo, of course

[SeanMcDonald]

If the issue is just that the script lets the 'copter overshoot the target, wouldn't it also work to add a pause after the key-checking if-statement to slow down the key repeats?  It seems like a llSleep() call might be a bad idea in some situations, but a loop that simply counts to a large number would accomplish the same end.  Maybe use a for loop or while loop?

[Rolig Loon]

Another thought ....

Again, not knowing what your script looks like, I assumed that you are handling the movement controls by using llSetVehicleVectorParam and VEHICLE_LINEAR_MOTOR_DIRECTION in the control event.  That would be the standard way to control a vehicle's velocity.  There's another approach, however.  You can use the control event to set the value of X_motor (the vector component of motion in the forward direction) but then actually move the vehicle in a timer event:

timer()
{
    llSetLinkPrimitiveParams( LINK_THIS, [ PRIM_POSITION, llGetPos() + <X_motor, 0.0,0.0> * llGetRot() ] );
}

This avoids using any of the standard vehicle functions, simply moving the vehicle as you would move any non-physical object. If you do that, you can control the vehicle's speed by fiddling with both X_motor and the rate at which the timer fires.  This can be a clumsy method, but it's great for remote control vehicles (like toys) and it's remarkably simple to script because you don't have to mess with all of the confusing vehicle functions.

[Rolig Loon]

13 minutes ago, SeanMcDonald said:

If the issue is just that the script lets the 'copter overshoot the target, wouldn't it also work to add a pause after the key-checking if-statement to slow down the key repeats?  It seems like a llSleep() call might be a bad idea in some situations, but a loop that simply counts to a large number would accomplish the same end.  Maybe use a for loop or while loop?

The problem with llSleep, generally, is that it does exactly what it says -- puts the entire script to sleep for the designated time.  It is a very useful function for those places where you need to give the script a chance to stop and wait for something else to happen.  (When you rez an object, for example, tell the rezzer to llSleep for 0,3 seconds before sending a message to the rezzed object, so that it has a chance to open a listen handler first.)  Putting llSleep in  a loop, however, can be tricky.  You are potentially disabling the script for a long time, effectively making it stall, unable to respond to other inputs.  A control event is designed to trigger very rapidly so that you can sample the state of keyboard key presses continually.  If you tie up the event with a llSleep after it checks the state of the Forward key, then it won't be awake to sample the state of the Right or Left keys.  You will have lost control of other motions as long as the script is waiting.

Edited January 23, 2019 by Rolig Loon

[Anna Nova]

3 hours ago, Rolig Loon said:

...

if (level & edge & CONTROL_FWD)
{
    // Do something
}

....

Rolig, this helps me a heap.  At least now I have found the section of the script that might be relevant.  I was never good at boolean algebra, it's too black and white for me

I'll do some more debugging, and report back.

❤

EDIT:   Thanks to the help I got here, I found where the control(...) event handler was (hidden in link #9, the pilot seat), and fixed it.  Very many thanks to everyone.

Edited January 23, 2019 by anna2358