Prepare yourself for llRegionSay()

this is now in Beta

Release Notes for Second Life 1.16.0(1) May 15, 2007
...

LSL Changes:
* New function: llRegionSay()
** Allows object to communicate region-wide
** Does not allow communication on channel 0
** This is intended to reduce simulator load by eliminating the need for relay objects

...

This will be a nice tool. No more relays

I've waited for this for years!

I wonder if this will work like llOwnerSay, where you can hear it even if you are a child agent to the sim (ie, in a sim adjacent to where the object is).

Yes, definitely a nice addition.

Sweet!

WOOT! You mean region to region?! So can drop emailing soon?! Please let it be true!

Or does region-wide mean chat within the same region? Neat of course but not what I hoped for. But gotta be happy for any improvement to LSL.

I'm very happy about llRegionSay() It's great benefit! Sure...it doesn't take down the need for cross-region llEmail...but perhaps something along those lines is coming sometime??? It would be nice for, say, an object to have a receive-instant-message event...

It's as welcome as a pint of ale (or six) after a hard day's graft.

Are we 1st of April? (checking my calendar)

I'm so happy I couldn't beleive it. llRegionSay + llRemoteLoadScriptPin = region-wide, fully upgradable network. No more routing. Hurry, Jeff, hurry! Complete this Boot Server Protocol...

i was about to have a hissyfit, but no communications on channel 0 made me instantly feel better

this will be a good improvement and i cant wait

I really wish they would include the ability to target a key within the same region - for objects. If could even be handled as a linked message, with a "DISTANT" link number constant.

Somethng like: llRegionSay(integer ch, string msg, key target)
Target would be optional, if not specified, a general broadcast.

But now that I think about it, maybe it's no more efficient to use this method to communicate with 20 hi-rise skyboxes, than it would be to use 20 discrete-channel listens. Or would it?

thank Seifert Surface and Lex Neva for inspiring this new addition to our library.

This is a godsend. I can't wait for it to be on the main grid!

*preens*

It won't work like that, because you can't use llRegionSay to chat on channel 0 (which, I think, is a good idea).

You can set up a multi-region network simply by stationing a pair of repeaters at a sim border that relay across the border using llSay() and then switch back to llRegionSay(). This seems like it may be a little kludgy, but I think it should be much more reliable and speedy than any option we currently have.

Yeah, I was aware of that. The mistake was in forgetting that objects can never be "child agents" of an adjacent sim, and that no private chat ever gets sent to the client (well, except for the Debug channel).



Oh, definitely. I still am waiting for something like named pipes between objects, though. Get rid of using llEmail once and for all for inter-object communications.

If you are lucky enough to own two adjacent parcels over a region border, you can even have your bridge cross region boundary and use llMessageLinked. NOW, we have an intelligent use of these 16sqm parcels

Clever! I wonder if that actually works... I'm not sure whether the child prim would be considered to be in the neighboring region when it chats the link message it receives from the parent prim. Worth a try, though.

Well, I don't think that would work, because a linked object is either in one sim or the other, depending on where the root prim is, regardless of where the child prims are. There's no case I know of where a linked object has running scripts which span more than one region.

Testing seems to confirm this, too.

I suspect the same, although placing two relay objects on the border and having them whisper to one another will work fine and still only use one listen.

Combine this with the XTEA encryption and it would make a good secure method of instant communication others would find hard to intercept within a region.
would not matter much any more even if people had listening devices and found the communication channel.

Looking for 'real' encryption? Start here.

LSL XTEA is far too slow for real-time message communication. 15-30 seconds at best for 100-character messages means you might as well use llEmail.

That may be so. However it is useful when you need to protect messages from being intercepted.... and now its possible to use it to communicate outside SL to a Webserver using PHP.

llEmail prevents messages from being intercepted, too. There's simply no way for them to be intercepted as long as they are object->object.

Already was a way to use XTEA to communicate outside SL to a PHP webserver. Well, for me, anyway.

If you want to secure your llRegionSay() calls easy and with little effort, convert your data to Base64 [ llStringToBase64() ] and use a Base64 encoded password to combine both Base64 strings via llXorBase64StringsCorrect().

Then send the data.

The receiver decodes with the same Base64 encoded password using llXorBase64StringsCorrect() and decodes the result with Base64ToString() to get the actual data content.

Remark: To ensure the decoded received message is yours, you might want to implement some magic at some certain position within the message to ensure that the text is decoded and correct, just in case you hear some message that was not yours and has unknown content. In such case you might wish to change the channel at some random new value automatically.

Your Password may be any kind of random ascii-string in any usefull length.
If you need to keep the passowrd secret but the script modifiable, put it the whole stuff into a second script and send your data to it for encoding and decoding via llMessageLinked() to become this way some kind of encryption black-box into your hand.

The whole procedures security is dependend on the medium length of your encoded data and password. While short phrases and data tend to be easily brute forced, long password phrases combined with long data sequences tend to be infinite secure when data and phrase have infinite length with random data in the password phrase.

If you only send short data sequences, a solution is to have a number of password phrases, that you use in a certain fashion but not round robin in an incremental sequence.
The length of each password should be at least as long as the expected average length of the encoded data sequence in such a scenario to provide security.

Example: Use the password number { 1,5,8,3,4,3,6,2,1,7,1,3,8,4,5,7 } when you have 8 passwords stored for encoding.