Nine script questions

Hi,

Thought it might be best to bundle several LSL questions I'd built up if that's ok.

STATE RELATED QUESTIONS

[1] Do I need an onRez() event in each STATE of a script to make sure I pick up this fact? (e.g. if the script needs to get the latest prim Uuid for example) That is, does a script always go into the default state after it's prim rezzes, irrespective of whether it had just been in another STATE prior to being TAKEN and re-rezzed?

[2] Do messages to a script (e.g. LINK messages or CHAT messages which the script listens for) get queued until the script is in an appropriate STATE to pick these up? That is a state which has the appropriate LINK or CHAT listen type events. (I'm assuming no)

[3] Following on from [2] if a script remains in a STATE with the appropriate listen type events (for LINK or CHAT messages) does it queue requests up, noting scripts are non-reentrant I believe. I assume the answer here is yes.

[4] Is there a way to get the current STATE of a script as a STRING, so this could be included in the standard LOG method?

[5] Is there a need (or is it a good idea) to have a ONEXIT event which closes all TIMERS, SENSORS etc, or will these naturally be closed if one moves to a new STATE which doesn't use these?

GENERAL

[6] Can a "sensor" search for a wildcard name? (e.g. object name matching "gate*"

[7] Do comments count towards the script memory usage? (i.e. can we put in as many comments as we want without affecting things)

[8] Whats the best function for time comparison? Based on time based ll* functions the script time (llResetTime, llGetTime) is easiest to use? i.e. llGetTimestamp would be good but it requires string interpretation as opposed to providing something like "seconds since 1970)

[9] How big are the buffers for script listens (for CHAT / LINK messages) - This follows on from [3] to some extent. For example if 10 link messages that the script will normally pick up get sent in close succession, but the capture event sends an email out, how many LINK events can build up for the script?

Thanks
PS Let me know if I need to clarify anything

[1] Yes, only the on_rez() in the current state will be triggered, if any. When an object is taken into inventory, it's current position is stored, and picks up exactly where it left of, triggering the on_rez() after any event handler that it may have been in the middle of when taken.

[2]link_message() or listen() event handlers will only be triggered if in the current state, othewise the event is ignored.

[3] Yes, every link_message or listen will be acted on, assuming the script does not switch states, which clears the buffer out.

[4]AFAIK, you can't get the current state of a script, unless you send it a link_message asking which state it's in and have it respond differently for each state.

[5]listeners are cleared on state changes, but timers do stay across state changes, not sure about llSensorRepeat.

[6] No, sensor filters have to be exact.

[7]Not for the run time code, but I have heard there is a limit to the length the editor will take, but it should be more than enough.

[8]llGetTime is not completely reliable, it could be reset for multiple reasons. Haven't done much with time comparisons.

[9]There is a maximum event queue of 64, any more than that total (not just link_message or listens) will be dropped.

Hopefully that answered all your questions

excellent thanks

BTW - Re [9] "maximum event queue of 64" - was that per script?

From my experience...

[9] This is per object, ie: primset, all scripts existing on a single rezzed object will share the queue. Be advised that events which block (such as llEmail and its 20 second pause) will take up space in the queue until they clear.

llGetWallclock and llGetGMTclock return times since different midnights in seconds as a float and work perfectly well for many time comparing functions, depending on exactly what you're trying to do. If you're going to use llGetDate as well for longer time runs, remember to use the GMT clock as llGetDate returns UTC date.

2 things I guess:
i) time differences in a defined short period (< 1hour) - so I was going to use llResetTime, llGetTime
ii) log/audit events (readable) - so I was going to use llGetTimestamp

I've never used llGetTime - the warnings look way too scary! But seriously, since llGetWallclock gives you times in floats to a fixed standard I can't see that it's hard to use and will give you something more reliable than llGetTime - which could easily be messed up by sim resets etc. which may or may not be critical to your application.

with llGetWallclock (just had a look at the wiki) wouldn't you then need to put checks and balances around this for (a) crossing the 24:00 point, i.e. changing days adn (b) daylight time savings changes?

Thanks for pointing out the probs with getTime sim resets. With all the above in mind I'm thinking llGetTimestamp may be the most solid, but just requiring some string processing to transform it into a "seconds since 1970" type of approach before comparison.

another script can get the state that the script is in altho it returns a number

http://secondlife.com/badgeo/wakka.php?wakka=llGetScriptState

llGetTime also resets at midnight pst.

All llGetScriptState() does is return TRUE if the other script it running, not what state it's in.