Technical questions about LSL itself

I have a few questions about LSL itself, so I can better understand how I should be scripting:

1. Do events get called in sequence or in parallel? For example, if I had a timer event and a sensor event, would they ever be called at the same time, or would one go first? If so, what determines that order?

2. How is recursion used in application? I hear about it all the time, but I've never thought of a place where I would need or want it.

3. Is explicitly coded math always faster than function calls? The best example I can think of is llEuler2Rot v. the LSL wiki's Euler2RotFast function. Should I do math myself to avoid extra function calls in scripts where speed is necessary?

Thanks, all.

Events get queued. Only one event can fire at once. There is no multithreading.


Recursion in what context?


I'd think that any instance where the sim can use a known value instead of having to compute it, it would be faster. It'd run faster, but probably not anything appreciable.

Recursion as in using a function within itself.

Oh, and one more thing: Is it possible for a script to delete itself?

Recursion is kinda hard to explain beyond your definition, without citing a specific case. You just know when you need it.


Yes, through llRemoveInventory().

There is a note on the efficacy of recursion in LSL here:

http://www.lslwiki.net/lslwiki/wakka.php?wakka=memory

Also, as far as a script deleting itself, I believe it still keeps running even though it is removed from inventory. You can then set the running state with llSetScriptState. But from what I recall, it doesnt completety go away (still uses some processing time, etc).

llRemoveInventory(llGetScriptName());

its one of those things that add up you doing a simple math function eh...

you, 600 random scripts 2300 casino machines and 2 sheep bots running away from crazy farmers = dent in cpu cycles

... up to 64 events (per script or per handler, I don't know). Over this limit, events will be silently discarded. So, if you use llMessageLinked to achieve a kind of modularity, which is the case of most projects except the simplest, you have to take care of not overflowing the queue by synchronizing processes.

I'm pretty sure this is incorrect... at least, I've never seen anything like this, and I often write scripts that delete themselves.

Can you give an example test case that shows this, RJ?

Actually, I can't.

My "from what I recall" was what I recalled reading here on the forums or someplace, not what I recall actually seeing. Maybe if the original poster of that info is reading, they could respond. And I'll try to track down my reference otherwise.

Probably a good time to mention a trick for interrupting an event...

If event A is doing something lengthy (like scrolling a settext message), there's no way to get in a byte edgewise within the same script. However, a touch event B to a different script can make a minor change (tweak alpha on a prim face somewhere...) within the object that event A can check for.

In other words, there are crude means of interrupting events.

Events get put into a queue as they occur, and are sent to the script as it completes each preceding one in sequence. Each script has a 64-entry queue; extra events are silently discarded, though the queue full situation is quite rare, unless you have an event handle which takes a LONG time to finish its task and return. There's no way to predict the order that events come in, the order is not significant and can be affected by lag, and there is no prioritization at all.



As has been said, you know an application is ripe for implementation in recursion when a) you understand what it is, and b) by the very nature of the application making it feasible to use as a solution. Generally, recursion is used in some iterative processes where nested state is more efficiently preserved through storing information on the stack via a calling mechanism than trying to manage it manually. In general, recursion is rarely any more efficient than not using it, but it has an aesthetic elegance to it, which makes it attractive for some programmers. It is a wolf in sheep's clothing, though, as it can quickly lead one to stack overflows (in LSL, the dreaded stack/heap collision error) and other nasty problems if not carefully designed.

What is recursion? It is simply a function calling itself or calling another function or set of functions which also call the calling function later at some point. Most often, it is demonstrated through the implementation of hierarchical data structure traversal and processing. Specifically, to build, traverse, and alter tree data structures.



Depends on the complexity of the function, but, in general, no. If the calculation's complexity does not exceed the overhead of a function call plus the math being performed, then you probably can get a small bit more speed from inlining the actual math. In some cases, there are approximations which can be used instead of a full calculation, which will result in faster execution, but with the obvious loss of precision.



As others have said, llRemoveInventory(llGetScriptName()); should work fine. The script stops running not very far beyond that point, usually only a statement or two afterwards, depending on lag.

It's eminently possible someone complained "I did llRemoveInventory(llGetScriptName()); and my particles/hovertext/looped sounds etc. continued so it doesn't work!"

There is a continuing level of misunderstanding of these functions that alter the prim permanently but which are triggered by a script initially.

I have to say I've never seen any issue with llRemoveInventory failing to kill a script and all script functionality stopping just fine.

"Interrupting" is misleading here. If you have to check for, this is polling.

A good example of recursion being useful is when creating fractals in SL. My own crude code does a preliminary run-through of the iterations using a recursive loop that halts when some defined limit is hit (max prims usually), and then spits out the total number of iterations to be used for rezzing the fractal pieces.

Here is a basic outline/pseudo code of how my code looks:

integer x;
integer y;
integer i;
function( float z)
{
    i++;
    x=2*z+34; //whatever kind of equation I'm using for my fractal
    if (x <= y)
    {
        function(x)
    }
    else
    {
        return i;
    }
}

If it can be done with recursion, it can also be done with a loop. So, if you don't know what it is, you have probably never needed it.

An example in pseudo-code

F(T,X):  To search a tree T for element X
{
   If T is the null tree, 
        return FALSE
   return F(left subtree of T, X) or F (right subtree of T, X)
}

You can do this with a loop, but it is easy to do and easy to understand with recursion if you understand recursion if you understand recursion if you understand...oops