Queued messages

[Innula Zenovka]

I'm making a texture and colour changer to control several large (as in lots of prims) and complex pieces of body jewelry at once.  The basic mechanism is that you select -- e.g.. -- a gem texture from a menu in the main piece (which probably the most complex one) and the script looks up the appropriate parameters for that gem, tells all the other attachments what they are and that they should apply them to all the gem prims, using llSetLinkPrimitiveParamsFast, and then applies them to the gem prims it contains.   

Same for the metals, fabrics and so on.  

This is all working well.   However, I've been asked to include some presets, so you select a style and then it changes all the gems, all the metals and all the fabrics to an appropriate combination, and I'm a bit worried.  

What I'd like to do is look up the gem textures, tell the other pieces to change their gems, change the gems in the main piece, then when I've finished that, look up the metals, and do the same thing.   Then when I've changed all the metals in the main piece, look up the fabrics and change those.

However, I'm slightly concerned about what happens if one of the component pieces receives a chat message that it's got to turn into something it can use for fabric parameters while it's only half-way-through changing the metals.   Does the message get queued for the script to deal with once it's finished what it's doing, or do I have to find some other way to do it (maybe tell the component scripts to wait till they've received all the sets of parameters and then process them)?

[Darkie Minotaur]

As far as I know - and my experiences point in the same direction - there is an event queue that can hold up to 64 events - if it's full, the other events are silently lost.

[Rolig Loon]

It's not just th lngth of the queue that would concern me.  We all know how chat lag can scramble the order in which things are heard.  If you have commands that depend on the order in which they are received, it's probably smart to build in some validation scheme to verify that your early messages have actually been received before you need the information from them.  Perhaps wait for validation before changing states and moving to step #2 of the process?

[Qie Niangao]

One thing to watch is that event queues are cleared when changing to a new state.  If the script is not using states, then this obviously isn't a concern.

[Void Singer]

assuming those other pieces are not exiting their respective events while running their other code, then yes your messages will queue (out of order chat is only a viewer side effect of lazy LIFO queuing).

what you may need to watch out for is stuffing your queue.... if you have a changed event in your script, then it gets queued whenever you change something even if you don't parse that... and I'm not sure of how it stacks... I know the different change types will fold into a single event, but I've never checked how multiple change of the same types behave I think they fold into one (for instance one changed color event even if you changed 50 while it was queued) but check to make sure if you use that event at all

 

you can send the whole set of changes at once, by compacting your changes into bit flags, and using a master change set (I'm assuming all options like textures are prerecorded in each script)... then each item can read all the options it needs to set from a single number. you could have 32 different options in each single number

in addition to the state change clearing the queue, resetting the script will also

[Innula Zenovka]

Thanks, everyone.. that's clarified things for me a lot.   I think I'm on safe ground, though I will test more thoroughly.  I'm not changing states while I do this stuff, and the chat messages start by telling the reciever script what they are, so the receiver knows which group of prims it needs to change.

I've been playing with a prototype and it seems to hold up, though I think I'll take to a very laggy club and see what happens there.