cburton400

Dora, I guess you're right. I'll just have to accept that in SL it's a scripting language and any limitations that implies. I've been using OpenSim to get around this (I can add threads to the compiler since the source code is available) but OpenSim doesn't have all the people SL does and it gets a bit lonely... Ela, Getting around the 10m limit is rather straight forward: make a list of co-ordinates between the start and end points at 10m intervals and use llSetPrimitiveParams to move. It's been a while since I've looked at some of this, but I thought that events get queued and when your code finishes and returns control to whatever called it, the system would take an event off the queue and re-calls your script, meaning that your code isn't called until you relenquish control. An interrupt stops everything and runs it's code and then returns control. Anyway, thank you both for your responses. I'll just have to live with it.

I've been scripting for a couple of months now and find that it can be painful. It's not the language or library, but how doing certain things require you to "split" up your routines. Things like doing a scan, getting a message, or reading a notecard. For example, I was writing a script to scan a region. I wanted to move, sensor scan, move, sensor scan, etc. Normally I would do something like: for(y=0;y<ymax;y=y+inc){ for(x=0;x<xmax;x=x+inc){ llSetPos(<x,y,z>); //do sensor scan //wait for the results //process results } } The only way I've been able to do this in LSL is to split the logic up into separate pieces and handle the looping myself. Add additional complexity if you also use a scan elsewhere in your script. So, my questions are: 1) Is there some way around the need to split up the routine? Am I just completely missing something? 2) It seems that threads would help this. Is there any reason scripts shouldn't support threads (though I don't have much hope SL will add this feature)?