detecting the SHIFT Key

Hi All,

have seen some objects that somehow register the SHIFT key in their scripts... I think I have anyway... sadly I can't recall where I saw this! (grrr)

Anyone know how?

Thx

-Ryder-

No, never heard of that. I think you might be mistaken on that one.

The keys which can be detected are detailed under the llTakeControls function in the Wiki.

I may indeed be wrong...

Q: Why in BLAZES, does LL limit the key controls so much? It seems so arbitrary.

Why not add a few. Space bar? RMB? I dunno... something.

"Give me a bone, people!"

I don't believe it's possible to detect the shift key in LSL. I've railed against this for months, but even looking at the open source viewer code I don't see any way to enable that since the control events are all server-side in your LSL script and the server simply doesn't process any keys not mentioned in the llTakeControls documentation that Talarus mentioned above.


.

Then I guess we are stuck with combinations of keys... (W+S) etc.

Does someone have a code snippit of how to detect key combos?

Detecting key combos is rather easy, since they key constants are bit flags. You might have some problems with timing, so you might have to explicitly look for both keys being pressed and not just one of them, or you might have an issue where one of the "chord" keys are pressed just slightly before the other, though.

I am assuming that you've read the quoted Wiki page, but if you look at the ExampleControls script, you can see that they are already kind of checking for combinations.

Here's an example that checks for the mouse, jump, and crouch buttons simulaneously:

// example_controls.lsl // ready jack // 21 jan 2006 // v1.0
 
// Put this in an attachment. When you put the script in or make
// a change, you have to re-attach the object to activate the controls.
 
default
{
    attach(key who)
    {
        if (who == NULL_KEY) {
            // detached
            if (llGetPermissions() & PERMISSION_TAKE_CONTROLS) {
                llReleaseControls();
            }
        } else {
            llRequestPermissions(who, PERMISSION_TAKE_CONTROLS);
        }
    }
 
    run_time_permissions(integer perms)
    {
        integer desired_controls =
                CONTROL_FWD |
                CONTROL_BACK |
                CONTROL_LEFT |
                CONTROL_RIGHT |
                CONTROL_ROT_LEFT |
                CONTROL_ROT_RIGHT |
                CONTROL_UP |
                CONTROL_DOWN |
                CONTROL_LBUTTON |
                CONTROL_ML_LBUTTON
        ;
 
        if (perms & PERMISSION_TAKE_CONTROLS) {
            llTakeControls(desired_controls, TRUE, TRUE);
        }
    }
 
    control(key id, integer down, integer new)
    {
        integer pressed = down & new;
        integer held = down & ~new;
        integer released = ~down & new;
 
// Notice that held is used instead of pressed, to 
// allow a little flexibility in detecting the chord
// while allowing one key to be pressed just slightly
// ahead of others.  In other words, do nothing until
// *all* of these keys are pressed.
        if (held & (CONTROL_FWD | CONTROL_UP | CONTROL_DOWN)) llOwnerSay("chord complete");
    
    }
}

This has not been tested, so lemme know if it doesn't work, but I'm pretty sure it's going to


.

Mmmm nope... does not work.

I think it is close... but the CONTROL_ML_LBUTTON does not work in the combo.

CONTROL_ML_LBUTTON returns a strange value... 1073741824

?????
-Ryder-

Ummm. What part of "bit flags" is not clear?

CONTROL_ML_LBUTTON is the bit flag 0x40000000, which is the same as decimal 1073741824.

Oh... CONTROL_ML_LBUTTON is the mouse button in MouseLook mode. The other one, CONTROL_LBUTTON, is likely the one you want.


.

THx guys...

I am using it in mouselook, so ML is the one I want.

But the combos are not working... they pass the IF condition by themselves...

I made these changes...

    control(key id, integer down, integer new)
    {
        integer pressed = down & new;
        integer held = down & ~new;
        integer released = ~down & new;
        integer dn = FALSE;
        integer mlb = FALSE;
        
        if (held & CONTROL_DOWN) dn = TRUE;
        if (pressed & CONTROL_ML_LBUTTON) mlb = TRUE;
        if (dn & mlb)
        {
         llSay(0,"it works!");
        }
    }

Changing your code just SLIGHTLY to make it a bit more efficient...

Hi all...

I thought I was nuts when I recalled seeing someone use the Shift key as part of user input... and I have now seen it again.

Twice.

One is part of the golfing interface system in Hollywood, it uses a shift left mouse button combination.

Another is a bar stool... where a shift click causes a change in the seating position on the stool.

Can anyone else confirm or shed light on this "shift" key business?

Thanks in advance.

-Ryder-

The only thing is see where the shift key comes into play is where CONTROL_LEFT and CONTROL_RIGHT are used. while out of mouselook and hitting CONTROL_LEFT A/left arrow key you spin where as hitting CONTROL_LEFT and shift makes you walk left. while in mouselook doing the same key presses produces the same results where as you'll strafe left even if you held down the shift key while pressing A/left arrow key, CONTROL_LEFT. Now with the golf game i would have to play to see but from what it sounds it uses the left mouse button in conjunction with shift A/left arrow key to produce a certain control or outcome for a control in the game. As far as LSL actualy decting the shift key alone seems to be limited to just the above mentioned keys. Kinda like llGetAgentInfo where it will detect and return AGENT_CROUCHING but not AGENT_CROUCHWALKING. Things they seemed to forget to add while making the codes, or left out for some unknown reason.

So I went to Hollywood and checked out the golfing instructions. The Shift key appears in: "Select a club by clicking on the appropriate button. Then use the left and right arrow keys to aim your shot. Shift-arrows will move the address arrow faster." So this particular use of the Shift key would effect CONTROL_LEFT rather than CONTROL_ROT_LEFT, for example, as Alicia describes, but wouldn't involve a mouseclick at all.

The only other place I can think of where the Shift key does anything a script could detect does involve the mouse: the Control-Shift-Drag operation on movable objects, which will cause them to rotate rather than translate as does Control-Drag. Mischief could be made, then, with llDetectedGrab() in the touch() event.

Yes, my bad... it is shift + arrow keys... The bar stool that uses it changes poses based on this... but still, an interesting addition of shift key function