Parent-Child relationship vs Listeners

I'm trying to create a forcefield door for sale, with one prim being the door control and another being the field.

Now, after wasting time with a free "out of the box" pair of scripts that wouldn't work and annoyed everyone else in the sandbox (llOwnerSay? Never heard of it before), I'm considering whether it would be easier and less laggy to have the objects merged together so that the controller 'parent' alters the field 'child''s properties, toggling between solid/opaque "on" and phantom/near-invisible "off".

Is this approach any advantage over using listeners? After all, there are other uses I can think of... light fittings and window tinters to name a pair.

I've always preferred using llMessageLinked() and link_message() when possible.

You can avoid the (usually trivial) lag associated with eternal listeners.

And from a "problem avoidance" point of view... if you have two objects that interact, then you have to deal with situations where one goes missing. If it's all one linked object, it's all there, or it's all missing... which can simplify the number of possibile situations your scripts will have to deal with.

Good point. I think I've got some simple scripts that might work, but maybe not.

Anyway, the root/controller has:

default {
	state closed;
}

open {

	state_entry() {
		llMessageLinked(LINK_ALL_OTHERS, 0, "OPEN", 0);
	}

	touch(int i) {
		if touch on root (control) {
			//send "close" message to kid/s
			llMessageLinked(LINK_ALL_OTHERS, 0, "CLOSE", 0);
		}
		state closed;
	}
}

closed {

	state_entry() {
		llMessageLinked(LINK_ALL_OTHERS, 0, "CLOSE", 0);
	}

	touch(int i) {
		if touch on root (control) {
			//send "close" message to kid/s
			llMessageLinked(LINK_ALL_OTHERS, 0, "OPEN", 0);
		}
		state open;
	}
}

Finished laughing? Here's round two for the child/forcefield:

default {
	state closed;
}

open {

	state_entry() {
		llSetAlpha(0, ALL_SIDES);
		llSetStatus(STATUS_PHANTOM, TRUE);
	}

	link_message(LINK_ROOT, 0, "CLOSE", 0) {
		llSetAlpha(1, ALL_SIDES);
		llSetStatus(STATUS_PHANTOM, FALSE);
		state closed;
	}
}

closed {

	state_entry() {
		llSetAlpha(1, ALL_SIDES);
		llSetStatus(STATUS_PHANTOM, FALSE);
	}

	link_message(LINK_ROOT, 0, "OPEN", 0) {
		llSetAlpha(0, ALL_SIDES);
		llSetStatus(STATUS_PHANTOM, TRUE);
		state closed;
	}
}

Who will be first to play Rocky to my Bulwinkle?

if you are using linked messages then DONT use strings for the messages unless you need to send txtual data. In this case you dont so use integer constants instead.

integer OPEN = 1000;
integer CLOSE = 9999;

llMessageLinked(LINK_ALL_OTHERS, OPEN, "", 0); 

Then in the link_message event

    link_message(integer sender_num, integer num, string str, key id)
    {
        if(OPEN == num)
        {
             llSetAlpha(0, ALL_SIDES); 
             llSetStatus(STATUS_PHANTOM, TRUE); 
             state closed; 
       }
    }

Newgy, since you raise the issue, can you please explain for me why not send strings in linked messages if you can help it? I assume it has something to do with memory/lag/performance, but can you explain a little the reason behind it?

Still trying to get my brain "behind" LSL to make more "responsible" scripts

Baron

String compares are far slower than integer ones. Since the OP only wanted to send an on or an off then tehre was no need for a string.

Also as you rightly summised, the less data you push around the better.

I strongly prefer touch_start() to touch(), mostly for superstitious reasons at the moment.

In the past, touch(integer n) { llInstantMessage( llDetectedKey(0), "message..." ); } would, in some rare cases, get stuck... and never forget the person that clicked on the object. Any new person that came along and clicked the object would cause a message to be sent to the original person... over and over...

I've converted over to using touch_start() in all my cases that rely on touch events to avoid the problem.