Scripting Questions

Hello,

I am a new scripter and had a couple questions I was hoping to toss out to the community:

1. When a script executes a linked message call is it handled synchronously or asynchronously. In other words can I rely on the code being processed by the linked message to complete before the next line of the main script is executed? The scripting Wiki states that you can put IM function calls into a separate script accessed through linked messages to avoid the 2 second delay on your main script implying that linked messages are asynch. Is this true?

It is my understanding that an object retains state whenever it is put into inventory. Therefore I typically transition my objects back into "default" when an on_rezz event is detected. This allows me to always start from a known states. What I'm not sure of is

2. What is the state of an object upon server reset. When the server crashed last night or when it is restarted today what will be the state of my objects when the grid is brought back online. Will it be reset to default? Wil it be in the state it was in when the server went down? ALso ...

3. Is there any way to know when an object is going away as part of a controlled shutdown so that I can persist my log files via email, ie is there an on_die event? SOme of my objects are gaming related and I am concerned that people can lose money they have deposited prior to a system/object crash since I have no way of tracking this data outside of the object.

Any feedback is appreciated.

Thanks, -JP

Wow, lots of new scripters lately Welcome !

1) link messages are asynchronous. You can expect them to get processed about 0.1 second after being sent out (provided the targetted script isn't running any code at that moment).

I reset my scripts to default state on rezzing in non-default states too

2) scripts happily continue executing as if nothing happened. That's how "sim crashes detector" can work, by detecting discrepencies in the server's paramters (the simulated time of day, usually) upon server crash / reset.

3) unfortunately, no You'll have to keep your logs updated in real-time I'm afraid...

Thanks for the info and the welcome, being able to create items in a multiplayer environment is addicting.

You mention that "scripts happily continue executing as if nothing happened" when the system crashes or is restarted. I am assuming that you mean the object is brught back to life in the state it was in upon death. However, all variables (local and global) will be reset and the on_rezz event will be executed first. Is this true?

- JP

Nope, the variables keep their values and no on_rez event is triggered (although it might roll back to before setting some variables ? It never happened to me). BUT if you parked your pirate ship the wrong way it might unlink *grmble grmble*

sorry to belabor the point but does this mean the script continues exactly where it left off (or thereabout) or does it resume at the start of the state_entry event for its state?

It resumes at roughly where it was last, AFAIK.

I agree with Jesrad. The script essential 'blanks out' the down time and carries on just as it was before. You probably lose a fraction of a second of processing completed (it might go back to the start of processing the last event called for example although I've never actually tested that) but that's about it.

Not necessarily. Lets say you're using a seperate script to call llEmail. When your main script (script A) triggers the link_message event in the llEmail-calling script (script B), script B will be delayed for 20 seconds upon calling llEmail. If script A triggers script B again, during the 20 second wait, a link_message event is posted on script B's queue, and executed only after the first email's 20 second delay is over. Each script is one thread - only one event can run at a time, others are queued until that event has completed executing. Your object still cant send emails faster then 1 every 20 seconds, but with a second script doing the emailing, your main script wont be held up for it. Be careful with this - the event queue has a cap and once that limit has been reached the queue will simply drop new events.
==Chris

thanks for the details. I am leveraging that capability in my scripting today. I have separated tasks like IM and email into separate communication utility scripts that I link to for faster processing. However, I was never sure if the time delay would be imposed prior to processing the return value (if there was one) or prior to executing the next event in the queue. In the cases I mentioned there is no return value to be processed but I was curious for other purposes.

I am also most comfortable with an OO approach to coding so I was considering breaking my code into several scripts. However, if every linked message works as a separate thread this can make things more difficult when I have dependencies.

- JP

Hi, JP!

Have you seen the thread about the SciTE-ez kit for LSL yet?

If you're doing a lot of modular scripting, this'll give you a pretty nice offline editor. And it also gives you the benefit of C++ -ish preprocessing...#define and #include to your heart's content

-- jj