Inter-script communication

Hello,
I got some excellent advice here last time I was stuck, so I thought I'd try again...
I have an object where I like to split the scripting on several scripts, having a master script that sends commands to the slave scripts.

The way I do this is to send instructions to the master script over channel CHANNEL, which are then interpreted by the "listen" event in the master script. Where necessary the master script then do a llWhisper(INTERCHANNEL,"command" for a slave script (tried also llRegionSay), but this does not trigger an event in the slave script. I never see the line "listen event".

This is even more fishy as things work just as intended if I do explicitly /INTERCHANNEL <command> on the chat line, and adress the slave script directly.

Perhaps it's not recommendable to trigger a listen event from another listen eventhandler? Possibly this will only queue the request?
Or am I completely misusing the event handling system of LSL?

Any good advice is most welcome!


Master script (valid snippets):
listen(integer channel, string name, key id, string message)
// Decode command string
{
if( id==llGetOwner() )
{
command = llParseString2List( llToLower( llStringTrim(message,STRING_TRIM) ),[" "],["."]);
integer i = 0;

while ( i<llGetListLength(command) )
{
if( llList2String( command,i ) == "myObject"
// Level 1
{
++i;
if( llList2String( command,i ) == "status" )
// Level 2
{
llWhisper(INTERCHANNEL,"status:";
}



Slave script (valid snippets):
state_entry()
{
llListen(INTERCHANNEL, "", NULL_KEY, "";
llListen(0, "", NULL_KEY, "";
}


listen(integer channel, string name, key id, string message)
// Decode command string
{
llOwnerSay("listen event";
if( id==llGetOwner() & channel==INTERCHANNEL )
{
commandLine = message;
state decode;
}

I suggest you remove the id==llGetOwner() from your slave listen event. The way it is now I think it will only listen to YOU, not to your master script.

Hello,

Your point is valid, but it is not the root cause. Consider:

listen(integer channel, string name, key id, string message)
// Decode command string
{
llOwnerSay("listen event";
if( id==llGetOwner() & channel==INTERCHANNEL )

I never see the llOwnerSay output either, so there is no event at all. Removing the id check just to verify confirms this, the main problem is that I never arrive at the listen eventhandler.
So while I thank you for pointing out a subsequent bug, the original problem remain.

Are these scripts in the same object? A object will not "hear" itself in this fashion. Instead use llMessageLinked() and link_message.

P.S. If you are only using one channel, it is not necessary to explicitly check the channel in your code, since the only listen events you will receive will be on that channel.

If you're trying to send messages from one script to another in the same prim through chat, it won't work. Prims never hear their own chat messages. Use linkmessages instead. They're faster (no script delay) and don't use an open listener, so they're less laggy as well.

The scripts are indeed in the same object, so this sounds like a very probable explanation. I will read up on the subject and be back when I tried it out. Thanks!

Yes, that was it!
Using llMessageLinked() the whole system works like clockwork.
Thanks indeed for directing me right, this aspect was never touched in the book I bought.

Book?! There are books about LSL? Wow.

You might want to try one of the wikis. I like http://www.lslwiki.net/lslwiki/

I use something along the lines of:

if(id == llGetOwner() || llGetOwnerKey(id) == llGetOwner())

Keep in mind that an object can't listen to itself, instead for scripts contained within the same object use llMessageLinked. and the link_message event.

http://rpgstats.com/wiki/index.php?title=LlMessageLinked
http://rpgstats.com/wiki/index.php?title=Link_message

For some reason you CAN communicate to other scripts in the same object with chat, just not in the same PRIM. I could SWEAR it used to be different (where you couldn't hear chats from different prims in the same object), and I think this has broken some of my old systems (fortunately none that ever made it out into the wide world). I could be wrong. Maybe I tried using them recently under different circumstances than in the original development.

Anyway, I think if you know the scripts will always be in the same object, it is better to try to use link messages (though linik messages have a harsher event queue limitation than chats). I'm guessing chats can be heard from different prims in the same link set to facilitate taking independent objects and linking them into a larger single-object build (e.g. taking a set of chairs and a table and linking them into one object without changing scripts).

Thank You all for clarifying the issue to its full extent!

A few of them, I don't really recommend them for the same reason I don't recommend books about PHP coding, they tend to teach some very sloppy coding habits. Do a search for "Second Life" on Amazon for a list.

Interesting observation Hewee, and you are correct I just tested it as follows:

default
{
	state_entry()
	{
		llListen(-10,"","","");
	}
	touch_start(integer total_number)
	{
		llSay(-10, "Touched: "+(string)total_number);
	}
	listen(integer channel, string name, key id, string message)
	{
		llOwnerSay(name+" : "+message);
	}
}

I placed the above code in a cube called prim1
Touched the prim and as expected got no response.
I then copied the prim and called it Prim 2 with the following expected result:

[2:43] Prim1: Prim2 : Touched: 1

and touched Prim1
[2:43] Prim2: Prim1 : Touched: 1

I then linked the 2 prims with the following unexpected result

[2:43] Prim2: Prim1 : Touched: 1
[2:43] Prim1: Prim2 : Touched: 1

I wonder if it will be safe to use this, or if it will revert to the old behaviour at some later date?

safe? probably...

effecient? not likely...

says whispers, and shouts can and do arrive out of order, link messages are more reliable within linked prims

Besides not having the sim overhead of a listen in each prim.

I was thinking more along the lines of a whisper in each prim and a single listen in the root.
Void has a good point though, chat lag is a pain and in my test I did find it a lot slower than Linked messages (but easier to implement). As all I need to know is which prim was touched I guess I should stop being lazy and go back to studying Link Messages

If all you need to know is what prim is touched, it's even easier than that: llDetectedLinkNumber(), and either no touch-related events in the child prims or llPassTouches(TRUE).

Thanks Hewee, that just saved me a lot of time
I really should learn to ask specific questions, but then learning the hard way is sometimes more productive in that the lesson sinks in.

This is not the first time I've run across this consideration and I find it quite curious. How is llListen() and llSay() with a listen event easier than llMessageLinked() and a link_message event? It's interesting that there seems to be this idea out there.

(I'm not knocking you -- just curious where this idea comes from.)

I agree, I use link messages much more then chat. Wth link messages I can pass an integer and two strings at the same time and not worry about chat scanners or chat lag. And, link messages require less code to write, much simpler.

Well I can’t speak for others that made that statement, but in my case, I find that the Wiki entries and the example given to be very uninformative relative to most functions, almost assuming an “if you intend to use this function, then any beginner type explanation will be bellow your level” type feeling. A search for more detailed info is difficult and tends to lead one to the advanced uses rather than the basics. On the other hand Listen and Say are extensively documented and used frequently by 99% of scripts. Even trying to decipher scripts, that are using Link Messages, is a nightmare for most newcomers to LSL as they tend to be the more complex scripts. I remember being scared off the first few times I tried to use them, as I ended up with infinite loops or dropped communications, not to mention the difficulties of Identifying which prim is which. At least with a listen you know the channel and can add a sniffer script to relay the debug info on Ownersay. After a few months experience and the warm fuzzy feeling one gets after realising the other scripter’s will help, if you try, and not just bite your head off, I have started to use them myself, but I still fear them.

llMessageLinked is your friend in this case

the curse of LSL is that even the more verbose wiki's like lslwiki, assume some level of scripting or coding knowledge and familiarity. LSL Portal reads more like a MS function description, which has the downside of being example usage poor (more wiki editors to add examples would be nice) and doesn't dissect what it's used for (or common abuses).

Well as a hint to the newer users of link messages like myself, I think I have now found that the link order as seen by the link messages is the inverse of the order they are selected in.

What happens when you link a linked object to another linked object is beyond me though

I did find that I can save a lot of frustration and time by linking the objects then dropping this script in to each prim.

// say link
default
{
	touch_start(integer total_number)
	{
		llOwnerSay((string)llGetLinkNumber());
	}
}

Just remember to delete it from each prim after you have written down your link list

If any seasoned users of Link Messages would care to add hints and tips, I for one would appreciate it.

IIRC when linking in other object, the entire link set is copied in just after the root of the last selected object, for multiples I'm not 100% sure of the entire order, but for two objects ABC and 123 (selected and linked in that order) it would be 1ABC23, sitting avatars are always the exception, they get appended to the end of linksets

to expand Very's script to self delete...

default{
  touch_start( integer vNull ){
    llOwnerSay((string)llGetLinkNumber());
    llRemoveInventory( llGetScriptName() );
  }
}