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)