Talk:Control

unheld

Is this code snippet right?

       integer start = level & edge;
       integer end = ~level & edge;
       integer held = level & ~edge;
       integer unheld = ~(level & edge);

unheld would be true for any bit that had a falling edge, was held high, or was held low. I think that last line should be...

       integer unheld = ~(level | edge);

...or the equivalent...

       integer unheld = ~level & ~edge;

With this new code, unheld would be true for any bit that was held low.

---

*kicks self* you are correct, I'll correct that, good catch. for some reason I though ~(level & edge) was going to be equivelent to ~level & ~edge. Strife Onizuka 11:42, 2 March 2007 (PST)

llMinEventDelay

All of my testing seems to show that llMinEventDelay affects the control event as much as it does any other event... I'm editing out the line that says "If llMinEventDelay is set to at least double this events delay, then this event will treat the llMinEventDelay as if it were half; in other words, this event can trigger twice as often as other events if the llMinEventDelay is greater than 0.1", but if anyone else wants to test it and change it back if they find discrepancies, feel free. Acheron Gloom 23:25, 22 May (PST)

Did you test the LSO VM or just the Mono VM? That passage predates Mono and was based on LSO testing, it is unlikely that with the introduction of Mono they kept the old timing rules in place. -- Strife ^{(talk|contribs)} 10:35, 23 May 2011 (PDT)

Both Mono and LSO showed the same results. My test was a simple script with llMinEventDelay, llRequestPerms, and llTakeControls in the state_entry and control event with llGetAndResetTime(). Both showed the same delay that was set in the llMinEventDelay function. Acheron Gloom 13:04, 23 May (PST)

It's good to know it's consistent. How many control events did you get to fire per second? -- Strife ^{(talk|contribs)} 08:33, 24 May 2011 (PDT)

That is another interesting thing... I was able to get it to fire pretty fast. Holding spacebar I was able to get 41.688 EPS, and not holding spacebar I got up to 27.11 EPS. The reason its interesting is that its noted that the control event has a 0.05 second delay (and I think all events are supposed to) and yet in reality they're all less than 0.05, and as low as 0.025. And yes this is the same for both Mono and LSO. Acheron Gloom 11:31, 25 May (PST)

CONTROL_ROT_LEFT and CONTROL_ROT_RIGHT SELF TRIGGERING

CONTROL_ROT_LEFT and CONTROL_ROT_RIGHT can be triggered when an object is selected or edited. CONTROL_ROT_LEFT and CONTROL_ROT_RIGHT can be also triggered when link is changed, i.e. sitting on a prim.

This triggers CONTROL_ROT_LEFT and CONTROL_ROT_RIGHT almost often:

   run_time_permissions(integer perm) 
   {
       if (perm & PERMISSION_TRIGGER_ANIMATION && perm & PERMISSION_TAKE_CONTROLS) 
           {               
               llStartAnimation(ANIM);
               llTakeControls(CONTROL_UP | 
                              CONTROL_DOWN |
                              CONTROL_FWD |
                              CONTROL_BACK |
                              CONTROL_RIGHT |
                              CONTROL_LEFT |
                              CONTROL_ROT_LEFT |
                              CONTROL_ROT_RIGHT,
                              TRUE, FALSE);                                            
           }        
   } 

It seems that delaying taking control may avoid CONTROL_ROT_LEFT and CONTROL_ROT_RIGHT triggering on sitting down:

This seems not to trigger:

   run_time_permissions(integer perm) 
   {
       if (perm & PERMISSION_TRIGGER_ANIMATION && perm & PERMISSION_TAKE_CONTROLS) 
           {               
               llStartAnimation(ANIM);
               llSleep(1);
               llTakeControls(CONTROL_UP | 
                              CONTROL_DOWN |
                              CONTROL_FWD |
                              CONTROL_BACK |
                              CONTROL_RIGHT |
                              CONTROL_LEFT |
                              CONTROL_ROT_LEFT |
                              CONTROL_ROT_RIGHT,
                              TRUE, FALSE);                                            
           }        
   }

—The preceding unsigned comment was added by Blade Gaelyth

Yes, this is an annoying side effect of the autopilot stuff built into avatar motions. This is what makes the avatar turn to face things when we look at or select them. LL chose not to fix it in the control event, worried that there could be scripts out there that rely on the behavior. Instead, we can check AGENT_AUTOPILOT from llGetAgentInfo to detect when it happens. The timing is finicky to catch the autopilot flag, but it sort of works. --Cerise Sorbet 12:04, 9 November 2013 (PST)