link_message receiving data from a llMessageLinked in a non-linked script!

[jak Scribe]

Hi,  I have created two huds, one is the Controller (Hud 1) and the other is the one being controlled (hud2).

Hud 1 and Hud 2 I pass messages using llRegionSayTo and listen on a negative channel.

Hud 1 and Hud 2 have more than one script in them.

Hud 1 and Hud 2 also the same "Dialog Script" in them to communicate with the Users.

Now my problem:

When the "Dialog Script" in Hud 1 sends a reply using llMessageLinked to another script,

    then Hud2 receives them also ??  (Debug() is a function I can turn on or off from showing debug messages)

Here is a shortened version of the script that is having this problem:

JS_Dialog( string dMode, string dTitle, list dData )
{   llMessageLinked( LINK_THIS, DLG_TIMEOUT, llDumpList2String(dData,"|"),"JS:"+dMode+"|"+dTitle);
}

default
{   state_entry()
    { //Debug( "state ready" );
      integer listener = llListen( COMM, "", "", "" );
    }
    listen(integer channel,string name,key id,string message)
    { if (channel == COMM)
    {   if ( message == "READY" )
        {       JS_Dialog( "want_something", "Would you like to do it?", ["Yes", "No"] );
        }
    }
    link_message( integer sender,  integer num, string str, key id)
    {   if  ( (string)id == "want_something")
        {   Debug( (string)id+" "+str );       //<----showing me other messages using a different id than "want_something" ???
        }
    }
}

I would be grateful for any constructive ideas before all of my hair turns grey!

 

Regards Mac aka Jak Scribe

[Rolig Loon]

You're right, each HUD should only hear a message aimed at it with llRegionSayTo.  

You are wearing both HUDs.  Therefore, if you send a llRegionSayTo message to your avatar, it will be received by you and then routed to any attachment listening on that channel (in this case, by both HUDs). It sounds like that's what's happening here, even you said that you are sending it to a HUD's UUID, not your own. It's not supposed to do that.

Try sending a message that is coded for a specific HUD ( like "1~Message" or "2~Message") and then letting each HUD parse the message to figure out whether it is intended for that HUD or should be ignored.

[jak Scribe]

The problem is only occuring with the llMessageLinked to link_message.  The messaging using llRegionSayTo are working fine.

Hud2 receives llMessageLinked sent from its own Dialog Script correctly.

"Try sending a message that is coded for a specific HUD ( like "1~Message" or "2~Message") and then letting each HUD parse the message to figure out whether it is intended for that HUD or should be ignored. "

I am sending the Dialog script a coded text ("want_something") in the variable id which it sends it back with the reply the user selected in the Dialog

and although I am catching and checking that coded text in the link_message, the variable str contains  data from the non-linked prim and script.

 

It was working perfectly until I started to find ways to reduce the memory usage LOL

[Rolig Loon]

28 minutes ago, jak Scribe said:

It was working perfectly until I started to find ways to reduce the memory usage LOL

Hmmm.. You've heard the saying, "No good deed goes unpunished"?

OK, I misunderstood.  Try a variation on what I was recommending.  You are passing another variable, DLG_TIMEOUT, in that llMessageLinked statement.  You didn't say what that is or how crucial it is here, but do you have some flexibility with it?  Could you perhaps let that parameter be, say, HUD_NUMBER + DLG_TIMEOUT, where HUD_ NUMBER is either 1000 or 2000?  Then  if DLG_TIMEOUT is, say, 12, the parameter will be 1012 if intended for HUD #1 or 2012 if intended for HUD#2.  Then parse the variable's value when received, to be sure that a HUD only pays attention if it sees its own value of HUD_NUMBER.

BTW, don't fret about gray hair. Embrace it. You will earn every last bit.

Edited November 4, 2022 by Rolig Loon
typos. as always.

[jak Scribe]

DLG_TIMEOUT is just the timeout time that the Dialog should wait until it returns to the calling script.  I will try what you suggest (I am always flexible in my coding LOL) and get back to you after my steak is done and eaten MMMM

[Wulfie Reanimator]

Unless I'm blind, the comment you have here is impossible:

5 hours ago, jak Scribe said:

link_message(integer sender,  integer num, string str, key id)
{
    if ((string)id == "want_something")
    {
       Debug( (string)id+" "+str ); //<----showing me other messages using a different id than "want_something" ???
    }
}

There's some vital information missing, and I suspect your problem isn't link_message but the listen event, since that's where the llMessageLinked calls are happening.

If you have multiple objects listening to the same channel, they're likely just reacting to the same message. And if you're actually using llDialog to display buttons for the avatar, those button labels are actually spoken by the avatar, so any scripts listening to the avatar could react.

[jak Scribe]

I totally agree that it "should be" impossible...

HUD1: Dialog script

1. This script uses a negative random channel number based on owners UUID and is only used inside this script.

2. The script receives the users input over this random channel and passes it on to the Main script using llMessageLinked( LINK_THIS,  timeout, reply, mode )
 
- time: a integer variable telling how long the Dialog script should wait before giving up and returning a timeout code.
- reply: a string variable containing the text of the button clicked apon
- mode: a string variable that was sent to the Dialog using a llMessageLinked( LINK_THIS, timeout, buttons, mode+"|"+Title )

HUD1: Main script

1. This script (in the same prim) catches the reply using link_message(integer sender, integer num, string str, key id)

2. It checks that the mode is the same one that it sent to the Dialog script, all others are ignored.

3. It displays (for test purpose) the contents of the variable str (reply) and variable id (mode).

4. It shows the expected mode id (mode) but the str (reply) contains data from the Dialog being used in HUD2 that I am using at the same time!

Q:  Do multiple Huds loaded at the same time in my viewer "act" as if they are linked?

PS. I did the test suggested by Rolig Loon and I got the expected HUD_NUMBER but still with the wrong replies.
(This test is, IMO, not much different from me checking the id variable)

[jak Scribe]

Just to clarify:

 

my Dialog script is using llDialog( llGetOwner(), title, buttons), DLGCHAN );

where DLGCHAN = (integer)("0xF" + llGetSubString(llGetOwner(),0,6));

Q: Can it have something to do with both HUDs using trhe same DLGCHAN  ??

If yes, I will have to ensure that each Dialog script uses a different channel (adding a random number to the one already calculated)

[Rolig Loon]

So, when you say

5 minutes ago, jak Scribe said:

This script uses a negative random channel number based on owners UUID and is only used inside this script.

you mean that the dialog script in HUD 2 uses a different random channel number from the one in HUD 1, but both are derived from the user's UUID?  Just for the heck of it, try deriving those channel numbers from something else, like the UUID of the HUD itself:

iChan = (integer) ("0XF" + llGetSubString(llGetKey(), 0, 6));

[jak Scribe]

doing it right now....will get back to you 🙂

[Rolig Loon]

3 minutes ago, jak Scribe said:

Q: Can it have something to do with both HUDs using trhe same DLGCHAN  ??

If yes, I will have to ensure that each Dialog script uses a different channel (adding a random number to the one already calculated)

Yes!  That's exactly what Wulfie was saying yesterday in her response.

[jak Scribe]

Yes I see that NOW....."Can't see the forest for the trees" 🤪

I made the Dialog script create REALLY random and individual channel number, using your suggestion, and it is working fine now.

 

Thank you both sooo much Rolig and Wulfie 😀

<----- back to more testing and testing and tes.........