Have one object talk with another object

[SEMaster Aftermath]

Hello, I am trying to make an Object A (the speaker in my script example below) tell Object B (the listener in my example below) what it's current position is every time it moves. I am not able to get my two objects to communicate with each other though. Please help.

Also, is it possible to have Object A say its new position every time it moves?

//Globals for speaker object (Object A)
vector myLoc;
integer chanSpeak = -68497305; // same large negative random number, so both scripts are communicating on same channel

//Globals for listener object (Object B)
integer Handle;
integer chanListen = -68497305; // large negative random number

//Script for speaking object (Object A)
default
{
    touch_end(integer num_detected)
    {
        myLoc = llGetPos();
        llRegionSay(chanSpeak,(string)myLoc);
    }    
}

//Script for listener object (Object B)
default
{
    state_entry()
    {
        Handle = llListen(chanListen,"","","");
    }
    listen(integer channel, string name, key id, string message)
    {
        llSay(0,"I heard this: " + message); // I was hoping my listening object would read back the vector from the speaking object
    }
}

Thanks for any assistance with this.

[Quistess Alpha]

The script as written seems to work as intended when you split it into the correct parts for each object, so I'm not sure what your problem there is.

As for making it work automatically when the object is moved, since we don't have an event that triggers when an object's position is changed* you have to poll the position periodically and check the change against a global variable.

//Listener
integer gChanChat = -17;
default
{   state_entry()
    {   llListen(gChanChat,"","","");
    }
    listen(integer Channel, string Name, key ID, string Text)
    {   vector pos = (vector)Text;
        if(pos) // script heard a valid vector that wasn't <0,0,0>.
        {   llOwnerSay(Text);
        }
    }
}

 

//moving object
integer gChanChat = -17;
vector gPosOld;
default
{   state_entry()
    {   llSetTimerEvent(0.5);
    }
    timer()
    {   vector posNew = llGetPos();
        if(gPosOld!=posNew)
        {   gPosOld=posNew;
            llSay(gChanChat,(string)posNew);
        }
    }
    touch_start(integer c) // superfluous.
    {   llSay(gChanChat,(string)llGetPos());
    }
}

* moving_end() has inconsistent behavior, I wouldn't recommend relying on it.

[Bugs Larnia]

On little hack I have used (once, I think, but I can't recall for what or when) is using something innocuous like a color change of +/- 0.01 to trigger the changed() event in order to act as trigger for something else. In case of your movement, you can change the scale or color by e.g. 0.01, which will trigger the changed() event. If you change back and forth (-0.01, then +0.01), you can do this every time.

See my demo script below.

integer giSwitch;
integer giFactor = 1; //Factor to switch between positive/negative adjustment

TurnOn()
{
    giSwitch = TRUE;
    llSetTimerEvent(3.0); 
}

TurnOff()
{
    giSwitch = FALSE;
    llSetTimerEvent(0.0); 
}

default
{
    state_entry()
    {
        TurnOff();
    }
    
    touch_start(integer piNum)
    {
        if (giSwitch)
        {
            TurnOff();
        }
        else
        {
            TurnOn();
        }
    }

    timer()
    {        
        vector gvMutation = <0.0, 0.01, 0.0> * giFactor; //Calculate the mutation
        llSetPos(llGetPos() + gvMutation); // Change the position (cannot be detected)
        llSetColor(llGetColor(ALL_SIDES) - gvMutation, ALL_SIDES); //Change the color minutely
        
        giFactor = -giFactor; //Switch the factor for the back and forth change
    }
    
    changed(integer piChange)
    {
        //Test whether the color was changed
        if (piChange & CHANGED_COLOR)
        {
            llOwnerSay((string)llGetPos()); //Send the data that cannot be detected
        }
    }
}

 

[Qie Niangao]

On 7/3/2023 at 2:43 PM, Quistess Alpha said:

* moving_end() has inconsistent behavior, I wouldn't recommend relying on it.

It's extremely unreliable for non-physical motion such as llSetPos or moving in the Build Tool. I don't think I have anything that depends on it, but it seemed to work every time I've tried with physical motion. One thing I haven't tried but sounds pretty promising—maybe even for non-physical motion—is the llTarget/not_on_target workaround Debbie Trilling mentioned in a comment to the jira reporting the event's unreliability.

I'm not sure what kind of motion is contemplated here.

[SEMaster Aftermath]

Thank you everyone, all of this has answered my question.