Parent/Child object Script Communications

[Damus Ember]

I made some mistakes...

So, it works but only the first time you click on the Rezzer.

The second time nothing happen.

The third time it works again, etc...

Why does it act like that ?

Edited May 15, 2020 by Damus Ember
typo

[Mollymews]

2 hours ago, Damus Ember said:

I made some mistakes...

So, it works but only the first time you click on the Rezzer.

The second time nothing happen.

The third time it works again, etc...

Why does it act like that ?

Damus, post the code with your mistakes and we might be able to help you work out what can be done to fix the mistakes

[Damus Ember]

Hello @Mollymews,

The code is still the one given by Linden Lab.

In my previous post, i said it didn't work because of some mistakes i made...

Now that it works, I just want to understand why nothing happen on the second click on the Rezzer.

The first time I click on the rezzer it works correctly but nothing happen on the second clik.

What should be changed to make the rezzer works every time you click on it ?

 

Edited May 15, 2020 by Damus Ember

[Mollymews]

Damus, the Linden script in the blog post does work as expected. It does rez a new Rezzee box each time the Rezzer box is touched

what can happen sometimes is that there can be a server side delay for the script listen event to be handled. (which is not caused by the script as wrote)

suggest that you try it on another region and see what happens

[Damus Ember]

No, I can assure you it's more than a server side delay...

It works correctly one time out of two.

It's not a delay because sometimes you can wait indefinitly and nothing will be rezzed.

Until you reclick on it.

It's like if some touch events (one time out of two) aren't taken into account.

[Wulfie Reanimator]

I'll back up what @Damus Ember said. Simply left-clicking on the object sometimes fails to rez anything. Right-clicking and selecting "Touch" seems to work always.

However. This script, which is straight from the blog post with only the addition of llSetColor to visualize what state the script is in, gets stuck in the wrong state because of failed communication when used in a sim with 40-60% scripts run.

////////////////////////
// Rezzer script.
//  Rez' an object from inventory, establishes a communication channel and
//  gives the rezzed object inventory.

integer COM_CHANNEL=-17974594; // chat channel used to coordinate between rezzer and rezzee
string  REZZEE_NAME="Rezzee";

string CMD_REZZEE_READY = "REZZEE_READY";
string CMD_REZZER_DONE = "REZZER_DONE";

key             rezzee_key;

default
{
    state_entry()
    {
        llSetColor(<1,1,1>, ALL_SIDES);
    }

    //...
    touch_start(integer count)
    {
        llSetColor(<0,1,0>, ALL_SIDES);
        state configure_child;
    }
    //...
}

// rez and configure a child
state configure_child
{
    state_entry()
    {
        llSetColor(<1,0,0>, ALL_SIDES);
        // where to rez
        vector position = llGetPos() + <0.0, 0.0, 1.0>;
        // establish rezzer's listen on the command channel
        llListen( COM_CHANNEL, "", "", "" );
        // rez the object from inventory.  Note that we are passing the
        // communication channel as the rez parameter.
        llRezObject(REZZEE_NAME, position, ZERO_VECTOR, ZERO_ROTATION, COM_CHANNEL);
    }

    object_rez(key id)
    {   // the object has been rezzed in world.  It may not have successfully
        // established its communication yet or done anything that it needs to
        // in order to be ready for config. Don't do anything till we get the signal
        rezzee_key = id;
    }

    listen(integer channel, string name, key id, string message)
    {
        if (message == CMD_REZZEE_READY)
        {   // the rezzee has told us that they are ready to be configured.
            // we can sanity check id == rezzee_id, but in this trivial case that is
            // not necessary.
            integer count = llGetInventoryNumber(INVENTORY_NOTECARD);
            // give all note cards in our inventory to the rezzee (we could
            // do scripts, objects, or animations here too)
            while(count)
            {
                string name = llGetInventoryName(INVENTORY_NOTECARD, --count);
                llGiveInventory(id, name);
            }
            // And now tell the rezzee that we have finished giving it everything.
            llRegionSayTo(id, COM_CHANNEL, CMD_REZZER_DONE);
            // And we can leave configure child mode.
            state default;
        }
    }
}

It just demonstrably doesn't work because it fails to handshake. White = default, green = touched (not really visible), red = waiting for handshake.

https://puu.sh/FKNQd/10756ae09d.mp4

Edit: After some retesting, I'm not actually sure why it kept failing in that video. I checked at the time of testing (and went back to find that object) to make sure that the rezzee script was running. It definitely was. It's working as expected now too.

But I find this way of handshaking very slow and cumbersome and not at all suitable for certain high-priority use-cases like bullets of "kill prims" which are meant to rez near the owner, receive a target, and track that target with the intention of touching them with llDamage(100). I would definitely recommend @Sei Lisa's method of establishing the listen before taking the object into inventry and placing it in the rezzer. Having a static communication channel is not a problem as long as everything is correctly filtered out.

Edited May 16, 2020 by Wulfie Reanimator

[Damus Ember]

@Wulfie Reanimator:

Thanks for your test !

I've the exact same behaviors than you.

The touch from the right-click menu seems to work everytimes !

[Mollymews]

based on the feedback from Damus and Wulfie

i can only assume that the issue is with touch_start (which causes problems in other coded combinations as well when the server is under heavy load).  Try changing the code to use touch_end(integer count) rather than touch_start(integer count)

Edited May 15, 2020 by Mollymews
load

[Damus Ember]

Thank you @Mollymews

It seems to be better with touch_end but that doesn't make any sense.

I take that as a temporary fix.

There's no reason for "touch_start" to be less accurate than "touch_end"...

[Mollymews]

Just now, Damus Ember said:

Thank you @Mollymews

It seems to be better with touch_end but that doesn't make any sense.

I take that as a temporary fix.

There's no reason for "touch_start" to be less accurate than "touch_end"...

you are right, touch_start should work as expected

the issue of something going wonky with touch_start in different coded settings/combinations has been around for a while now. This being the latest instance of it showing up

[NaomiLocket]

Forgetting about explicit code for a bit or even thinking of touch events as being distinct events. It would feel that touch start would have a chance to not happen in the presence of event chance, but touch end would require a touch start or touch to pre-exist. Just thinking out loud tonight.

[Mollymews]

31 minutes ago, NaomiLocket said:

Forgetting about explicit code for a bit or even thinking of touch events as being distinct events. It would feel that touch start would have a chance to not happen in the presence of event chance, but touch end would require a touch start or touch to pre-exist. Just thinking out loud tonight.

from the cases where it does show up, typically when rezzing and attaching, mouse_down (touch_start) just seems to get missed

normally in event driven systems then out-of-the-box: mouse_down, mouse_over, mouse_hold, and mouse_up are independent

like mouse_down on one object (and holding down the mouse button) sends mouse_down, mouse_over and mouse_hold to the object.  Move the mouse off the object while holding down the mouse button then releasing the button and  the object doesn't receive the mouse_up event. The new object the mouse is over doesn't receive the mouse_down event. It receives mouse_over, mouse_hold and mouse_up

and I think it is this latter where the issue may be.  Somewhere in the script server engine when under load, the mouse_down message is not interpreted as coming from the object.  Also, I think right_click Touch works because it sends mouse_up (touch_end)

edit add. Is designed this way so that drag drop can work. In some systems mouse_hold and mouse_over are exclusive. Mouse_over when the button is not pressed. Mouse_hold when it is

Edited May 16, 2020 by Mollymews
drag drop

[Damus Ember]

😅

I didn't see this in the wiki: http://wiki.secondlife.com/wiki/Touch_start

And here: http://wiki.secondlife.com/wiki/Touch_end

 

Quote

The best advice is NOT to do state changes from within touch_start. Use touch_end and do the state change there. Changing state from within touch_start can cause the next occurrence of THAT touch_start code to be missed.

So, not only "touch_end" is the right fix, but Linden Lab doesn't take their own advices into account 🙃

[Qie Niangao]

4 hours ago, Damus Ember said:

So, not only "touch_end" is the right fix, but Linden Lab doesn't take their own advices into account 🙃

Yeah, this is a really ancient bug. It used to be even worse, where even resetting the script didn't restore sanity.

It's quaint, but not charming.