Pls help: link communication affects two independent objects

Hello everybody,

I had my first hands on prim communication, but obviously I seem to do something wrong.
Pretty sure someone can point me to the right way.

The setup: I want to make a box made of 5 siding prims, having the sides react to commands from the root prim.
The commands are light on/off and color change to change the color of the box' inner side, so issuing the color change is meant to change the color of one face of the sub prim.
Therefore I made 2 scripts, one (lightColorSwitch) to be placed in the root prim providing the menu, and the second (subPrimListen) to be placed in each siding prim listening to the commands and change the color or light respectively.
The color change is communicated by llMessageLinked(), the color vector transmitted as string to the sub prim.
I made the prims, linked them together to a box, put the scripts in and: Ok - it works, so far, so good.

But: When put two boxes side by side (not linked to each other), _both_ boxes react to the commands I issue from either box.
So the communications seems not to be limited to the own link set but also affects an object standing next to it, reacting to the same commands.

Can anyone please help me to understand what's going on and how to transmit the information keeping it in the box so that two boxes side by side can be controlled to have different colors?

Many thanks in advance
Cathy


Here's the code:

// --- lightColorSwitch
// --- Coloring / Light menu


integer menuChannel = 94;
integer linkChannel = 96;
integer index = 0;
list MENU_MAIN = ["Light on", "Light off", "Color..."];

list MENU_COLOR = ["White", "Red", "Orange", "Yellow", "Green", "Mint", "Blue", "Purple", "Pink"];
list COLORS = [<1.0,1.0,1.0>,<1.0,0.0,0.0>,<1.0,0.5,0.0>,<1.0,1.0,0.0>,<0.0,1.0,0.0>,<0.0,1.0,0.5>,<0.0,0.0,1.0>,<0.5,0.0,1.0>,<1.0,0.0,0.5>];

string vecString = "<0.0,0.0,0.0>";
vector colorVector;

default
{
	state_entry()
	{
		llListen(menuChannel, "", NULL_KEY, ""); // listen for dialog answers (from multiple users)

	}

	touch_start(integer total_number)
	{
		llDialog(llDetectedKey(0), "Select options", MENU_MAIN, menuChannel); // present dialog on click
	}

	listen(integer channel, string name, key id, string message)
	{
		if (channel == menuChannel)
		{
			if (llListFindList(MENU_MAIN + MENU_COLOR, [message]) != -1)  // verify dialog choice
			{
				if (message == "Light on")
				{
					llMessageLinked(LINK_SET,linkChannel,"light_on",NULL_KEY);
				}
				else if (message == "Light off")
				{
					llMessageLinked(LINK_SET,linkChannel,"light_off",NULL_KEY);
				}
				else if (message == "Color...")
				{
					llDialog(id, "Select lighting color", MENU_COLOR, menuChannel);
				}
				else
				{
					index = llListFindList(MENU_COLOR, [message]);
					colorVector = llList2Vector(COLORS, index);
					vecString = (string) colorVector;
					llMessageLinked(LINK_SET,linkChannel,vecString,NULL_KEY);
				}
			}
		}
	}
}

// --- subPrimListen
// --- listen for lighting/color messages

integer myFace = 1;
integer light_on = FALSE;
vector color;

setLight()
{
	llSetPrimitiveParams([PRIM_POINT_LIGHT, light_on, color, 1.0, 10.0, 0.75, PRIM_FULLBRIGHT, myFace, light_on]);
	llSetColor(color, myFace);
}

default
{
	state_entry()
	{
		light_on = FALSE;
		color = llList2Vector(llGetPrimitiveParams([PRIM_POINT_LIGHT]),1);
		setLight();
	}

	link_message(integer sender_num, integer num, string str, key id)
	{
		if (sender_num == 1)		// root-Prim
		{
			if (str == "light_on")
			{
				light_on = TRUE;
				setLight();
				return;
			}
			else if (str == "light_off")
			{
				light_on = FALSE;
				setLight();
				return;
			}
			else
			{
				color = (vector) str;
				setLight();
			}
		}
	}
}

Hi Cathy

If am understand the problem correctly..."When put two boxes side by side (not linked to each other), _both_ boxes react to the commands I issue from either box"...

Then there are two of the same product, right? Both using the same script?
If so, and if I have undrstood it correctly, then the problem is almost certainly because both products are operating off the same Listen channels.

If this is indeed the case then all you need do is change the values for menuChannel in one of the scripts so that both products operate from different channels.

Hope that helps a little

Yes Debbie, you understood right - and I already thought in that direction.
But: isn't the link message mechanism not meant to limit the communication to the current link set, no matter which channel it is on?

Sorry Cathy...I meant that the problem is likely in setting variable "menuChannel = 94" in both scripts. That is, it is the *Dialog* box which is transmitting the selected options to both products, rather than the internal communication provided by llMessageLinked()

Both products are listening for instructions on channel 94. When you select an option from the dialog menu from one of the products it is being broadcast on channel 94 and therefore *both* products react to that broadcast.

Understand that clicking a Dialog button which is labelled (for example) "Red" is the same as typing "/94Red" in the chat box. As such, *any* object within chat range that has an open listen on channel 94 will receive this instruction. Any of these same objects that have processing in the script for the word "Red" will react to that instruction.

As an aside, you have also set a global variable "linkChannel = 96" but you actually do not need to do this, and certainly this value is not being used by the receiving script.

you could even leave the menu channel alone, and just trigger llListen when they are touched like

//--delete the state entry

//-- in your touch event
llDialog( dialog stuff );
llListen(menuChannel, "", llDetectedKey( 0 ), "" );
llSetTimerEvent( 30.0 ); //-- so we don't leave an open listen

//-- in your listen event
//-- do stuff per commands
llSetTimerEvent( .01 ); //-- immediately go to our listen killer

//-- add a timer
timer(){
  llResetScript();
  //-- or if you were still doing something in your default state entry, 
  //--you'd use timerEvent( .0 ) (because timers run across states)
  //-- & flip to another state and back to kill all listens
}

Thanks Debbie and Void - the obvious things are often harder to see
Didn't keep the menu in mind ... I think setting that channel to a random number should solve the problem indeed, and setting up the listen on demand is a good idea.
As I never did the link messages before, I thought the problem was there........
Stupid Iam, willing to learn, and grateful for such formidable helpful people around

we all start somewhere, you're doing fine, just keep at it