Best way to handle inter-script communications

[Zaphod Bartavelle]

Hello,

I am working on a set of scripts where I need the scripts to communicate back and forth with one another (within a single object).  There are numerous ways to handle inter-script communication, but I am looking to find the most appropriate method.

llSay(...) has the advantage of using channel numbers

llMessageLinked(...) has the advantage of multiple parameters being passed.

Both functions would be viable solutions to what I am trying to accomplish (with slightly different internal processing), but can someone advise if there are any other factors that I should be considering when choosing the proper method of communications besides what I have listed above.

Thank you

Zaphod

[Vegro Solari]

You want llMessageLinked() for your purposes. Definitely.

It is quicker-responding and has significantly less impact on sim resource use.

Additionally, frees you from worrying about what channel all your objects are talking on, they can be "self contained" linksets.

[Zaphod Bartavelle]

That was the way I went with when I first started working on the script, however I did want to verify that and am glad to hear about the lighter resource usage as well.  The only downside is the lack of channel capabilities, which can be easily worked around of course with one of the parameters passed to the event.  Thank you for the clarification/confirmation.

[Ciaran Laval]

llRegionSayTo would be an option if you really want to use channels and it is a more efficient method that llSay but it is restricted to the objects being in the same region.

llMessageLinked is probably the better option though.

[Dora Gustafson]

By all means llMeassageLinked is what you will use within a link set for the reasons you already know
Just remember that a script will hear what it is saying unlike communication on chat channels
It is up to you to prevent recursion

:smileysurprised::smileyvery-happy:

[Nova Convair]

One detail: all link_message events in all scripts fire if a message is sent and need to check if they are adressed or not. If there are many scripts that has probably alot more impact than single listen events firing.

Of course you can send link messages to a specific prim but you need to keep track of the link # then unless it's the root or it's a communication between scripts in the same prim.

So whats best for a certain contruct - depends. In most cases link messages will be the best solution but not all cases.

Keep in mind. A script sending a link message can hear itself. But a chat message can not be heared by all scripts in the same prim.

[LepreKhaun]

Actually, a script sending a link message can hear itself if and only if it addresses the prim it resides in.

[LepreKhaun]

A simple design decision addresses all your concerns regarding using llLinkMessage, But first, let me state the main reason one should avoid any of the llSay variants for communication within a single object: Overhead.

Each Listen event within all the scripts entail the following actions (excerpted from http://wiki.secondlife.com/wiki/LlListen )

1. Chat that is said gets added to a history.
2. A script that is running and has a listen event will ask the history for a chat message during its slice of run time.
3. When the script asks the history for a chat message the checks are done in this order:

• channel
• self chat (prims can't hear themselves)
• distance/RegionSay
• key
• name
• message

If a message is found then a listen event is added to the event queue.
The key/name/message checks only happen at all if those are specified of course.

 

Now, Number 1 happens in due course, all chat is being added to the chat history, regardless. It's only #2 and #3 that gets called into play for open listens. And that overhead happens whether the event is added or not to the script's queue to be processed. So, if one had (say) 10 scripts communicating with listens, that would be a minimum of 10 listen overhead calls, with more in play if a menu dialog is opened or you have a script waiting for the owner to chat a command.

But wait! Look at that second check being done in #3- where "prims can't hear themselves", that tells us that if the object consists of only 1 prim, one can't even consider using a variant of llSay, llLinkMessage is the only option possible.

So, let's say you do have a task that requires 10 scripts to coordinate/communicate with each other and only one prim for them to work within. The question then becomes how to most efficiently to do this with no chance of error. That's where the design decision comes into it all. It's both simple and scalable; one makes the decision to use the integer num (the second parameter in both the llLinkMessage function (the transmitter) and the link_message event (the receiver)) as a Channel IDentifier. Then it becomes a matter of addressing a specific script by its Channel ID
and each link_message event wraps its code within a test to see if it is being addressed or not.

However, the test within link_message can't be a simple "if (num == myChannelID)". Though that would work, when a script had to address all the others it would require (in the case of having 10 scripts) nine separate calls to llLinkMessage to broadcast it. No very efficient at all! The solution is to assign the Channel IDs using the Power of Twos (2^0, 2^1, 2^2, ...): One script would use a ChannelID of 1, the next 2, then 4, 8, 16, 32, etc. So, the code each script would have is:

 

// Defined globally as a constantinteger myChannelID = [the script's unique Power of Two integer goes here];
default
}
	link_message( integer sender_num, integer num, string str, key id )	{ 		if (num & myChannelID) 		{		// coding block to process message (which may consist of both str and id!)		}	}
}

 

The "&" is a bit operator- one of the fastest and most efficient in programming ( http://lslwiki.net/lslwiki/wakka.php?wakka=bitwise ). If it fails, everything within the following braces gets skipped and the code immediately "falls through" the event. If it evaluates to TRUE, then (and only then) does it enter the coding block. No chat history comparisons with layered masking comes into play.

So, all that remains to be done is to implement the transmitting of messages. To send a message to a specific script is trivial, one just uses "llMessageLinked( link, specificChannelID, str, id );" where specificChannelID is as we've defined it for each script. But, since we've chosen to use Powers of Two for the ChannelIDs, broadcasting to multiple scripts becomes much more powerful than llSay could ever be.

Using one prim with ten scripts, you'd have assigned ChannelIDs from 1 (2^0) to 512 (2^9). Right? So, to address them all, you'd broadcast to a ChannelID of 1023 (2^10 - 1 = 0b1111111111). But this would evaluate to TRUE within all your scripts' link_message events, including the sender. So, to avoid that, we'd send to "integer broadcastChannelAllButMe = 1023 - myChannelID;", which is better written as "integer broadcastChannelAllButMe = 1023 ^ myChannelID;", using the XOR bit operator instead of the (much slower) arithmetic operation.

But wait there's more! Using this design decision, one can address specific groupings of scripts within that set and no others. Prior to transmission, one just has a line to define the broadcast grouping, such as: "integer groupChannelID = aChannelID | bChannelID | fChannelID | jChannelID;" This statement OR's the ChannelIDs (which are defined earlier as integer constants) of the scripts we wish to address (in this case, scripts a, b, f and j). Using "llMessageLinked( link, groupChannelID, str, id );" , only scripts a, b. f and j will have their code blocks within their link_message events evaluated.

Bottom line is, there is no reason to ever feel a variant of llSay is appropriate for communicating within an object. Correct usage of llLinkMessage will win out every time. And, keeping in mind Murphy's Law, one will never have to contend with a channel conflict with another object.

[Nova Convair]

---

LepreKhaun wrote:

Actually, a script sending a link message can hear itself if and only if it addresses the prim it resides in.

---

Yes, a link message is "heared" in the prims that are adresssed by the sender. But thats trivial.