RegionSay going to public channel

[Pedlar Decosta]

Hi, I'm doing a script at the moment and I'm trying to design code that allows 2 unlinked prims that are some distance away, but in the same sim to pair off for intra sim TPs. Basically I guess I'm making them 'handshake' and confirm their pairing. I'm using llRegionSay() on a big negative number and the  problem I am having is during the handshake llRegionSay() is reverting to channel 0. I thought perhaps it was because it was throttled and I tried putting a llSleep() in to fix it. But it doesn't. The channel is a global integer and even when I change it to say llRegionSay(-9563426,"communicate"); it continues to be heard by the other object on the public channel. I am saving the details for reference, but have removed them for this post. I'm hoping someone can explain what is going on ? Thanks in advance

Oh, and interestingly there is no error in the debug window, so it may not actually be being sent on 0 (?), although (and I don't think this is related) sometimes when I reset the scripts it does have an debug error about regionsay on 0.

integer CHANNEL = -9678543;
key mssg2;
default
{
    state_entry()
    {
        llListen( CHANNEL, "",NULL_KEY , "");
        llRegionSay(CHANNEL,"hello");
    }
    listen(integer channel,string name,key id, string message) // event triggered by above listens
    {

    list list1 = llParseString2List(message, [","],[]);
    string mssg = llList2String(list1,0);
    mssg2 = llList2Key(list1,1);

        if(channel == CHANNEL)
        {
            if(message == "hello")
            {
                llRegionSay(CHANNEL,"pair,"+(string)id);  // THIS IS HEARD ON CORRECT CHANNEL
            }
            if(mssg == "pair" && mssg2 == llGetKey())
            {
                llOwnerSay("accepting");
                llRegionSay(CHANNEL,"accept,"+ (string)id); // THIS IS HEARD ON CORRECT CHANNEL
            }
            if(mssg == "accept" && (key)mssg2 == llGetKey())
            {
                list info = llGetObjectDetails(id, [OBJECT_NAME,OBJECT_POS]);

               // Saving the above details
                llRegionSay(CHANNEL,"confirmed,"+(string)id); // THIS SEEMS TO BE SENT ON CHANNEL 0
            }
            if(mssg == "confirmed" && (key)mssg2 == llGetKey())       //THIS IS WHERE IT IS HEARD ON PUBLIC CHANNEL
            {
                list info = llGetObjectDetails(id, [OBJECT_NAME,OBJECT_POS]);

               // Saving the above details
            }
        }
    }
}

Edited July 18, 2019 by Pedlar Decosta

[Pedlar Decosta]

Nevermind lol. I figured out it wasn't being sent on the public channel at all. It was my feedback, which isn't in the code above. Duh.  But it still leaves me with a question.

Why do you sometimes get a debug error about RegionSay on channel 0 when you reset a script, when it is clearly given another channel than 0 ?

 

[Lucia Nightfire]

Since you're listening on an open channel, you might want to verify that the object heard is at least owned by yourself.

listen(integer i, string name, key k, string message)
{
    if (llGetOwnerKey(k) == llGetOwner())
    {
    }
}

Otherwise anyone can script an object to send regionsays in the region to interfere.

[Pedlar Decosta]

Thanks Lucia. Yes I have verified it is my own object. The problem I had was actually feedback through llOwnerSay() that said the channel it was heard on was 0. However it was impossible as firstly I didn't have a llListen() operating on 0 and secondly, when I used a separate object to listen, it was actually on the correct channel. Also it still happened even when I put the number directly in the RegionSay function. I assume It is a problem caused by my own coding. However the question I belatedly posed was one which I encounter now and at other times, when  the debug box (?) would show an error that llRegionSay() couldn't use the public channel, even though I set the channel as a global integer and/or in the actual RegionSay(). I am at a loss why this would happen, I have looked at the function in lsl portal and it doesn't mention it. It only happens when I manually reset the scripts, or sometimes when rezzing the object.

[Pedlar Decosta]

I thought it was about time I figured out why the RegionSay would give the error I explained above. I identified it as one in a listen event. What the real question is though is why a global variable  integer "CHANNEL", that is declared as a specific negative number at the top of a script (eg. integer CHANNEL = - 9488473;), would sometimes not be represented correctly further down in the script ? There are no other mentions of CHANNEL except as a llRegionSay(CHANNEL,"something"). So why would you need to reiterate the channel ? Anyone able to shed some light on this ?

Edited July 19, 2019 by Pedlar Decosta

[Mollymews]

the only thing I can think of that might have an effect is that in state entry, the listen is set up then immediately followed by a RegionSay. There may be creation timing and/or synching issue here caused when the script server is lagging

[Pedlar Decosta]

16 minutes ago, Mollymews said:

the only thing I can think of that might have an effect is that in state entry, the listen is set up then immediately followed by a RegionSay. There may be creation timing and/or synching issue here caused when the script server is lagging

I think you must be right Molly as it only happens when a script is reseting, which often covers the rezzing as well. I'll start adding sleeps either after a listen is initiated or prior to the regionsay. Any guess as to how long would be enough ?

[Mollymews]

am not a fan of adding sleeps to scripts when there might be alternatives. Before exploring what the alternatives might be then I would in the first instance suggest adding some debug/surety code. Example:

listen(integer channel, string name, key id, string message) // event triggered by above listens
{
    if (channel != CHANNEL)
    {
      llOwnerSay(0, "Hmmm! we heard this '" + message + "' on " + (string)channel); 
      return;
    }

    list list1 ...
}