SL to Kitely control event tweak

[Xxaxx Constantine]

As you may have seen in another thread, I've been working on importing a flight script from SL to Kitely.
In doing this I have run a couple experiments, and removed the llSleep kluge.

I'm posting this thread as one tiny clue for folks making the transition from SL to Kitely.

For the experiment I used the following event handler in my script.

Code: Select all

    control( key id, integer levels, integer edge ) {
        integer start = level & edge;
        integer end = ~level & edge;
        integer held = level & ~edge;
        integer untouched = ~(level | edge);
        llOwnerSay(llList2CSV([level, edge, start, end, held, untouched]));    
    }

Using the above code I pressed and released the pgup (quickly), then pressed and released the pgdn (quickly)

Output from Kitely:
[15:04] Box Plane: 16, 16, 16, 0, 0, -17
[15:04] Box Plane: 0, 16, 0, 16, 0, -17

[15:04] Box Plane: 32, 32, 32, 0, 0, -33
[15:04] Box Plane: 0, 32, 0, 32, 0, -33

Output from SL:
[15:03] Box Plane: 16, 16, 16, 0, 0, -17
[15:03] Box Plane: 16, 0, 0, 0, 16, -17
[15:03] Box Plane: 16, 0, 0, 0, 16, -17
[15:03] Box Plane: 16, 0, 0, 0, 16, -17
[15:03] Box Plane: 16, 0, 0, 0, 16, -17
[15:03] Box Plane: 0, 16, 0, 16, 0, -17

[15:03] Box Plane: 32, 32, 32, 0, 0, -33
[15:03] Box Plane: 32, 0, 0, 0, 32, -33
[15:03] Box Plane: 32, 0, 0, 0, 32, -33
[15:03] Box Plane: 32, 0, 0, 0, 32, -33
[15:03] Box Plane: 32, 0, 0, 0, 32, -33
[15:03] Box Plane: 0, 32, 0, 32, 0, -33

You will notice that SL sends the "key held" messages.

At first I thought, well maybe Kitely is just slow in its cycles so my quick release was beating the held event.
So I held the button down for a minute or more.
Still no "held key" signal in Kitely.

I wasn't planning on using the "key held" in my programs. Maybe there is a special flag that can be set?
I don't know if this is client side, or server side.
Just an FYI.

The real reason I bother you with this post is: llSleep( 0.15 );
There are a bunch of scripts (of the free script variety) bouncing around that stick a llSleep in the control event.
This was probably used to avoid processing the held and end events.

I find the following code a bit cleaner for me -- i.e. no kluge llSleep.

Code: Select all

    
control(key id, integer level, integer edge)
    {
        if (level & edge) {
            // drop through to control handlers
        } else {
            // is either held or end
            return;
        }

        integer throttle_up = CONTROL_UP;
        integer throttle_down = CONTROL_DOWN;
        
        if ((level & throttle_up)) {
            throttle++;
            if (throttle > maxThrottle) {
                throttle = maxThrottle;
            }
        } else if (level & throttle_down) {
            throttle--;
            if (throttle < 0) {
                throttle = 0;
            }
        }
       etc.
       etc.
    }

I'm pretty darn new to lslscript. So there may be a good reason for using llSleep rather than checking for "key down" specifically.
Please clue me in if you happen to know of such a good reason.

[Ilan Tochner]

Hi Xxaxx,

llSleep is used to reduce the load the script creates on the sim. Without it the script will run every frame (45+ times per second) as opposed to 6-7 times per second. I'd advise against removing it.

[Xxaxx Constantine]

Nice explanation.
In the scripts I've seen banging around the lsl wiki and free scripts space the sleep is included with no explanation or it is called a kluge.

I'd like to understand this a little better.

If I set a timer [ llSetTimerEvent(3); ] is the script running every frame? Or, is the script hanging in limbo until the timer event is called?

I'd be curious about scripts with touch_start and/or changed event handlers. Are these scripts running every frame? Or are they in some kind of limbo waiting for an avatar to either sit on them or touch them as the case may be?

From what you are saying it might be necessary to change my programming style to prevent a door script or giver script from running every frame.

Or, perhaps this is something special with scripts that use llTakeControls function.

Thanks for any expansion.

[Ilan Tochner]

Hi Xxaxx,

Setting a timer for a duration that is longer than a frame (for example the 3 seconds you stated in "llSetTimerEvent(3)") means that the script will not run every frame and will only execute when the timer event happens. As a general rule, it's much more efficient to use code that gets triggered when an event happens than use code that constantly checks whether the event you're interested in happened.

Scripts that wait on an event are added to a queue of things that should be called when that event happens. They aren't in limbo they are simply not running until they are called.

I would highly advise against writing code that runs every frame, especially for things that can be triggered by an external event, handled in a short period of time then sent back to wait until that event happens again.

[Xxaxx Constantine]

I would highly advise against writing code that runs every frame, especially for things that can be triggered by an external event, handled in a short period of time then sent back to wait until that event happens again.

Am I correct in assuming that llSetTimerEvent is the only way to cause a script to run every frame?

Or, are there certain functions that will cause this to happen as a side-effect?