RegionSay vis Email: which makes for the best neighbour

Have a bunch of child prims, all in same sim, that need to communicate back and forth with main prim.

Any opinion on what is better / least worse?

(a) child items listening [on an obscure channel, of course;

(b) child items checking every 5 seconds or so for email constantly.

considering the fact that llEmail has a hefty 20 second penalty which causes the script to sleep for 20s after sending email....

use llRegionSay.

If you mean child prims as in in a link set, then use llMessageLinked().

If you just mean they're clinets/slaves to a master prim the llRegionSay() is dandy.

Though, if you can, http and xml-rpc via an outside web server is fun, keen and efficient.

Hi Squirrel, Jillian, thanks for your thoughts.

Yeah, by child prims I meant slaves. Dunno why I just hate using that word.

In fact, to be precise, they are elevator buttons. Each button has two scripts in it. One emails a request to the elevator cab / car. The other script checks for email (to avoid that 20 second delay, Squirrel.) They aren't linked in any way. 1 button may be on the ground floor; one may be on 18th floor. They will be in the same sim though.

Communication with the actual elevator happens under three circumstances:

(1) At startup, button emails a request to the elevator to pls send it config info. Such info is centrally maintained, and I like it that way, easier to keep updated.

(2) When a person pushes a button on a wall to call an elevator, the button emails info about the person to the elevator. It checks for a response emailed back which might say, tell the person to bug off, etc.

(3) From time to time, an administrator of the elevator may centrally change the language of operation, the floor counting method, or the look and feel (textures) of the whole get-up. If this happens, then the elevator emails the new info to the button. So the button has to be checking for these emails.

I use timers of course to regulate how often the button should be checking from email -- from let's say every 3 seconds when someone has pressed it and waiting to hear back if the elevator will come for them or not -- to say every 60 seconds just when idle, to check for config changes such as in scenario 3.

I deliberately used email because:

(1) I didn't trip over llRegionSay until a day or two ago, and didn't want to count on the buttons being close enough to the elevator to hear the limited 100 metre range of llShout (18 floors x 10 metres = out of range); and

(2) One is generally invited to believe that llListens are universally evil.

So, I went to all extra work of using email.

But the penny's just dropped in my mind, that all these email scripts are not just sitting there idly flipping through Reader's Digest: they are constantly polling for email.

And so it's occured to me to wonder, if that constant polling truly is any better than having them listen, say, on channel - 1898767, for a say of some sort.

I own land, but not a sim, so sadly don't really have access to the kind of monitoring tools that a sim owner does. So I turn to the court of opinion.

>> Jillian say:
Though, if you can, http and xml-rpc via an outside web server is fun, keen and efficient

yeah, sounds like fun, but it also commits me to maintaining those web services off world, grin.

That's just it, a listen IS constanly polling, really. The big difference is a listen adds a bit of lag through the "filter" process in the sim, only cycling your scripts process when there's something to deliver to it.

Mail, on the other hand, means polling on the sim to see if it's time to kick over the timer event, then the script process is started, then a check with the mail queue.

If you've only one script waiting on a trigger, then the difference between the methods will be fairly small, but if you've quite a few, I'd go for listens any day.

Just keep those listens down to the barest minimum nessesary with the strangest, largest, least likely to be used by anyone else channel number to minimize firing your listen event by accident.

You can manage your elevator buttons' impact: They poll, hear the answer, then kill the listen 'till it next needs it, for instance.

Which is to say that listens aren't evil; unessesary, busy listens are.

Aye, there's the rub. If a central setup change is done and being sent to them, they won't know to listen for unless they are listening to be told they need to listen :}

Thanks very much for the feedback, much appreciated!