Hidden in plain sight

I submit the following snip-it of code for your review...

	if (llListFindList (MENU_BLUES, [message]) != -1 & message != "Back to Groups")
		llMessageLinked(LINK_SET, Bouquet_Area, llList2String(UUID_BLUES, llListFindList (MENU_BLUES, [message])),NULL_KEY);

Basically if the value in message is found in a list (MENU_BLUES) and if the value of message is not equal to the text string, "Back to Groups" then I want to send a link message to all prims in the object.

I have verified that value in the variable "message." I have inserted llSay commands just before this condition to display the result of the llListFindList function. The left side of the "AND" is true as is the right side of the "AND." However...

...the llMessageLinked command is not getting executed because in the scripts in the other prims I have llSay commands that display that processing has progressed to the child prims.

I have kept the same condition and replaced the "THEN" part with an llSay just displaying a literal to let me know the condition evaluated as TRUE and that works fine. I just cannot get the llMessageLinked command to execute.

Does anyone have any clues what I'm overlooking? This should be very straightforward and I'm certain I'm just not seeing the obvious so I would definitely appreciate additional sets of eyes verifying what I'm doing.

Thanks!
Bartiloux

http://www.lslwiki.com/lslwiki/wakka.php?wakka=boolean

Notice the value for the AND operator

From what I've been reading in the WIKI, you use '&&' when you are doing Boolean comparisions and '&' when doing bitwise comparisions. I've tried both and neither seems to be working.

...it feels Boolean to me.

Anyhows... so, in the other prims you have something like this?

link_message(integer sender_num, integer num, string str, key id)
{
    llOwnerSay(str);
}

Yes, exactly, and that llSay does not get executed. For what it's worth, when I am at that portion of processing, via a little built-in menu system, I see white dots encircling the prim that contains this code.

If you want to say "if this is true and that is true", use &&.

That is a butt ugly way to code up anything unless you really really have to!!!!!
I assume you think you are saving memory and possibly speed?

You say it works if you put an llSay in?

How would you code it to make it prettier??


But, yes, when you replace the llMessageLinked with a llSay, the llSay does get executed. So it appears something is out of kilter with the llMessageLinked statement?

For starters, don't call llStuff more than you have to.. Also, don't do stuff like [message] a lot as it'll create a new list each time. If you need to use it more than once, create it once and reuse it.

integer position = llListFindList (MENU_BLUES, [message]);
if (position != -1 && message != "Back to Groups")
{
        string bluesStr = llList2String(UUID_BLUES, position);
        llMessageLinked(LINK_SET, Bouquet_Area, bluesStr, NULL_KEY);
}

I'd do it like this

integer selection = llListFindList(MENU_BLUES, [message]);
if( (selection != -1) && (message != "Back to Groups"))
    llMessageLinked(LINK_SET, Bouquet_Area, llList2String(UUID_BLUES, selection),NULL_KEY); 

LOL, Seems like Meade beat me to it.

But I had to edit typos out twice..

Breaking it up and assigning separate variable was going to be my next step. I'm going to see if maybe this makes the difference that will get the llMessageLinked statement executed.

Also, thank you for the feedback related to LSL efficiencies. That type of information is hard to come by and I definitely appreciate it.

Read Strife's Post

Okay... I used Mead's formatting and added an llSay(0,"Inside the IF" within the braces of the "then" part of the condition. I fired up the script and got the display from the llSay inside the IF, but it doesnt' look like it's getting to the child prim because I am not seeing the output from the llSay in the child prim.

Maybe I'm mis-reading something but these two statements sound like they conflict..

Both of those posts are referencing an llSay that I have in the child prims to let me know that control has passed to the child via the llMessageLinked function. Even switching to the easier to read format the child prim is remaining quiet, leading me to believe there's something wrong with the message linking.


I put an llSay inside the IF of the parent prim, in the code that you helped me clean up, and that llSay does indeed get executed. So... the if is trapping the proper condition, the llSay is getting executed, it should be falling to the llMessageLinked command and then executing the llSay in the child prim, but I see no output from the child prim.

I think Meade thought you were saying you saw the white dots circling the child prim...

Ahhh... no. The appear to circle the parent prim for a few seconds.

Could it be something as simple as the script being set to 'not running' in the child prim? Or being in a state that doesn't have a link message handler? Or being stuck in a loop in some other event handler, so it never gets to process new events from the queue? Or sitting in a long llSleep?

Just a few ideas off the top of my head

Hmmm... I like the "set to not running" idea, because that is, indeed, how it appears to be behaving. How do I check this? I don't recall seeing that option anywhere.

When you open up the script, there's a checkbox near the bottom of the window. Also, the main Tools menu has 'set all scripts running/not running' commands.

Okay... one last question and I will quit bothering all you nice people out there in Script Forum Land. What in the world would cause the "RUNNING" check box on a script to get unchecked???

Ziggy's suggestion ended up being the reason the scripts in my child prims were not being executed. The check box on all the child prim scripts was unchecked.

Thank you to each and every one of you that helped me get to the bottom of this. I learned quite a bit all along the way. From the beginning, with my subject line "hidden in plain sight," I knew the answer was going to be something dumb that I probably did. Such is the plight of a newbie, I suppose.

Thanks again. You all are the best!!!

Bartiloux

A compilation or a run time error, or a manual untick will stop scripts from being set running.

I've actually noticed, on a couple of different occasions, that when I add a new script to an object that already has at least one script in it, the new script will be set to "not running" by default. It's happened to me maybe 10 or 12 times, (and is annoying as hell!) but I've never noticed a pattern of when it happens or what I might be doing differently.

I keep trying to notice if/when it happens, to find out a cause - it may be a small bug or it may be something I'm not noticing.

If you drag & drop a script by CTRL drop into a prim rather than dragging it into the object's contents, it ends up "not running".