There was an informative discussion in the Scripting Group. The scripting group’s general discussion meetings are good meetings for advanced LSL programmers to attend.
If you don’t understand precedence, sorry Google for an explanation. (LSL Precedence) It was brought up that the operators || and && should have equal precedence. Kelly Linden conformed that they are not equal.
Estate Owners Access List
The update running on the release channels will likely make it to the main channel this week. This will give residents the ability to use the new LSL functions discussed in the Server Update News here. ( llManageEstateAccess(integer action, key id) ).
The idea behind this function is it will make it easier for estate managers to manage ban lists.
I find it interesting to know what Kelly and other Lindens are working on. We can’t always know because some projects have not been announced. The rules say if it is not announced, the help cannot talk about it.
In this case all we can know is the Kelly will be working on server maintenance issues. I think that means bugs and performance issues.
When I learned the Linden flavor of scripting I was told LLSleep() was a major resource hog. Kelly says it isn’t. I guess at some point I’ll test that idea.
Kelly brought up llSleep() because he found some anomalous behavior in some scripting he was doing. He will be tweaking llSleep() in coming releases. That should be interesting. Because my understanding of llSleep() I’ve avoided it. So, tweaks will have no effect on my scripts… well very little.
I’ll describe what I think Kelly says he found when optimizing a WHILE( not_changed) loop. If you want to read his words see the meeting transcript.
There is a trick used to reduce the script load on servers when using WHILE statements. A llSleep(0.00001) function call is used to, in theory, have the WHILE check only once per frame for a change.
If you don’t know, events are triggered on the frame edge. At the beginning of a frame a burst of events fire and bubble up. That means a server frame typically lasts about 22ms when the server is running at 44 FPS. Rather than use up all of the 22ms in a while loop for the script one can add a llSleep() and release the script time. Kelly says llSleep values over 0.022 should cause the script to release the remainder of the scripts’s frame time.
The anomaly Kelly was seeing is the llSleep(0.0001) was causing the script to skip a frame. So, if one was doing a WHILE loop to add and display a count they should see it hit 44. But, since it is skipping one sees a count of 22. This is the issue Kelly will be looking at. We are getting more sleep than we need… right.
Kelly looked at the code. It shows that no matter how short the sleep, the entire frame is skipped. So, anything <0.022 that should allow the script to resume running within the frame, doesn’t. So, all values from >0.0 to 0.022 will cause the same delay. Kelly prefers any really small llSleep() time result in a ‘yield frame’.
I suppose as the region slows the 0.022 value increases.
Kelly says, “It means that while(llGetObjectDesc() == “”) llSleep(0.00001); will be just as fast as while(llGetObjectDesc() == “”);. But the former will be much nicer to the simulator [and] other scripts.”
Some think it would be good to allow llSleep() to use negative values as the number of frames the script is to sleep. So, llSleep(-1.0) would skip a frame.
When one is talking about llSleep() the comparison to llSetTimerEvent() comes up. Kelly says, “llSetTimerEvent(0.001) is less aggressive than while(). Anything less than ~0.02 is the same.”
Whatever is decided and changed, figuring out what llSleep() is doing in a WHILE loop gets a bit complex.
Events like touch_start can occur 45 times per second. Kelly says events have no capped setting. It is a matter of simulator speed. Ke;;y says, “There is no explicit limit on number of timer events a single script can have per second. I’m sure there is an implicit limit. The “0.04s” makes me think it is a similar off-by-one issue as sleeps – otherwise it would be 0.02s.”
Qie (qie.niangao): Speaking of llSetMemoryLimit()… just to confirm, this really has no beneficial effect for the sim, right? It just helps us “promise” others about what our scripts use — the sims can’t actually do anything with that to save on garbage collection or anything, right?
tehKellz (kelly.linden): Correct Qie. Except, your script will crash if it goes past it. Mono scripts use only the memory they need, unlike LSL which always uses a fixed 16k. The ‘limit’ is the promised ceiling.
Jeremy Duport: Then it has psychological worth. 🙂
tehKellz (kelly.linden): Correct Jeremy. Also, when/if we move forward with memory pooling and memory limits the reported ceiling for mono scripts is what will be used in the accounting – same as the reporting now.
Summing It Up
Lots of useful information. I’ll be changing how I do WHILE loops in LSL.