Difference between revisions of "Talk:LlSleep"

From Second Life Wiki
Jump to navigation Jump to search
m (→‎Use of small values with llSleep(): Added syntaxhighlight for more beautiful rendering of LSL)
 
Line 66: Line 66:


: {{SL-Profile|Poppet McGimsie}} 17:10, 17 February 2014 (PST)
: {{SL-Profile|Poppet McGimsie}} 17:10, 17 February 2014 (PST)
== Trivial question: does llSleep() block all events from being queued? ==
I suppose that this question ''is'' obvious, or trivially answered with 'aye, of course, that's the whole point of llSleep()'.
In any case, if that's how it works — e.g., event queue suspension — then it might be worth adding it to the main page.
Or perhaps it's so obvious that it has been left out deliberately 🤣
— [[User:Gwyneth Llewelyn|Gwyneth Llewelyn]] ([[User talk:Gwyneth Llewelyn|talk]]) 17:53, 22 September 2024 (PDT)

Latest revision as of 17:53, 22 September 2024

Use of small values with llSleep()

I believe these 2 script shows that a small value (as in less than 0.0222... (1/45)) sent to llSleep() causes the script to sleep out the rest of the server frame it's then active within, always causing a minimal delay of approximately 0.022s. They also show that llSleep(0.0); is a NOP.

To show this, I'm using a technique to see what gets en-queued during the detach event. Both scripts announce when their attach event handler is triggered. The "Sub" script, when it detects a detach event message, also sends a link message to "Main" which then announces when it's been received. With either no llSleep() or with llSleep(0.0) in the indicated spot within "Sub", nothing is queued through the detachment. However, use of a small value will cause the response of the link message to delay until it's reattached again.

To use, place both scripts within one prim, attach and detach enough times to note the chat messages and when they occur. Uncomment either of the llSleep() statements in "Sub" to observe the differences.

    // Main
    default{
        link_message(integer sender_num, integer num, string msg, key id){
            llOwnerSay(msg);
        }
        
        attach(key id){
            if (id == NULL_KEY)
                llOwnerSay("Main detached.");
            else 
                llOwnerSay("Main attached.");
        }
    }

    // Sub
    default{
        attach(key id){
            if (id == NULL_KEY){
                llOwnerSay("Sub detached.");
            
                // Uncommenting next line will not change the observed behavior
                // llSleep(0.0);
            
                // Uncommenting next line will cause this script to sleep until the end of the server frame
                // llSleep(0.0001);
            
                llMessageLinked(0, 0, "DETACHED", NULL_KEY);
            } else
                llOwnerSay("Sub attached.");
        }
    }
LepreKhaun Resident 19:23, 13 January 2014 (PST)


Try this:-

    default
    {
        touch_start(integer total_number)
        {
            llResetTime();
            llSleep(0.0001);      // Try also with 0.0
            llSay(0, (string) llGetTime() );
        }
    }

I got values as low as 0.01825, mostly around 0.021, and once 0.044 (2 frames) from a sleep of 0.0001

but consistently 0.00000 from a sleep of 0.0

Omei Qunhua 03:28, 14 January 2014 (PST)

Mo' bettah, fo' sure. LOL I'd made the observation while tinkering with synchronicity in multiple scripts and never thought to simplify. I guess the question would be does it warrant mention on the front page and, if so, would it fall under Caveats?

LepreKhaun Resident 07:26, 14 January 2014 (PST)

IMHO it would be great to have this with the scripts on the llSleep page. Wouldn't it fit under deep notes?

Poppet McGimsie 17:10, 17 February 2014 (PST)

Trivial question: does llSleep() block all events from being queued?

I suppose that this question is obvious, or trivially answered with 'aye, of course, that's the whole point of llSleep()'.

In any case, if that's how it works — e.g., event queue suspension — then it might be worth adding it to the main page.

Or perhaps it's so obvious that it has been left out deliberately 🤣

Gwyneth Llewelyn (talk) 17:53, 22 September 2024 (PDT)