llRezObjectWithParams flag REZ_FLAG_NO_COLLIDE_FAMILY causes first instance of rezzed object to receive no collision_start events at all | Voters

llRezObjectWithParams flag REZ_FLAG_NO_COLLIDE_FAMILY causes first instance of rezzed object to receive no collision_start events at all

tracked

Judy Hynes

Using the flag REZ_FLAG_NO_COLLIDE_FAMILY with llRezObjectWithParams() causes the first object rezzed not to receive any collision_start events at all no matter how many collisions it has. All subsequent rezzes of the same object do receive collision_start events as expected. This problem seems to be subject to a "caching effect" such that it only happens the first time the object is rezzed on a given sim.

It has been difficult to characterize the behavior exactly since it only happens once per sim per some very long time (sim seems to "remember" the object and not have the issue for some number of hours). However, it does seem like the "memory" works across different owners' instances of the same rezzed object, e.g. agent A uses laucher to rez projectile, which exhibits the failure, then agent B uses same launcher the same way and does not experience the issue. I also did not attempt to investigate collision and collision_end events, but I strongly suspect these have the same issue.

I have created a minimal example to replicate the issue. You can use these scripts to reproduce it, or contact me in world and I will give you my example object.

Launcher script

default
{
    touch_start(integer num_detected)
    {
        rotation my_rot = llGetRot();
        vector rez_pos = llGetPos() + <5.0, 0.0, 0.0> * my_rot;
        vector velocity = llRot2Fwd(my_rot) * 200.0;
        list params =
        [
            REZ_FLAGS, REZ_FLAG_TEMP | REZ_FLAG_PHYSICAL | REZ_FLAG_NO_COLLIDE_FAMILY,
            REZ_LOCK_AXES, <1.0, 1.0, 1.0>,
            REZ_POS, rez_pos, FALSE, FALSE,
            REZ_ROT, my_rot, FALSE,
            REZ_VEL, velocity, FALSE, FALSE
        ];
        llRezObjectWithParams("projectile", params);
    }
}

Projectile script

default
{
    on_rez(integer param)
    {
        llOwnerSay("on_rez  param="+(string)param);
    }
    collision_start(integer num_detected)
    {
        llOwnerSay("Collided with: "+llDetectedName(0));
        llSetTimerEvent(4.0);
    }
    timer()
    {
        llDie();
    }
}

You can see a video of the behavior here: https://gyazo.com/41bf8753ec3d82243109df5db86a8acc

Notice in the lower left chat text how the first projectile reports only its on_rez event, then the second one reports on_rez and collision_start. In fact, if you look closely you can see both projectiles bounce back and forth a few times hitting an object out of frame to the left. The first one gets none of the collision_start events while the second gets them all.

March 26, 2024

Maestro Linden

Hi Judy Hynes I appreciate the feedback. I tried again with my own setup (with a bit more verbosity in the output of the rezzzer and projectile) in a series of regions. In 4 regions, the rez call included REZ_FLAG_NO_COLLIDE_FAMILY , and in 4 regions the flag was disabled. I had a 100% repro on the REZ_FLAG_NO_COLLIDE_FAMILY regions, and 0% on the other set - so you're absolutely correct.

On the regions in which the bug reproduced, the projectile's script was actively running, and printed both on_rez chat and updated its color every second. But for some reason it wasn't triggering any collision_start events for either of the barriers, or when my agent bumped into it. I don't believe the barriers I rezzed and my agent should be in the same 'family' as the rezzed object, so something is wrong.

Maestro Linden

marked this post as

tracked

Maestro Linden

marked this post as

needs info

Maestro Linden

Hi Judy, thanks for the report. I've tried to reproduce this in Second Life Server 2024-02-21.7995320426, but have had verify limited success. I've seen it perhaps once out of dozens of attempts.

My setup is:

- Rezzer is phantom

- Projectile as a default 50cm box

- 2 thick barriers set up, offset approximately +-20m from the rezzer in the X direction. The projectile bounces between these 2 barriers and reports collision events with them. These are important to have because the object would otherwise exit the sim

very

quickly, given its 200m/s rez velocity

- Projectile script slightly modified to be more visible: contains a particle system that goes to the owner, and also updates its color every second so that you can see that it's running

- Rezzer script updated to report the projectile's key and show its position + velocity in floating text. Announces in chat when a projectile appears and disappears

- Parameters for llRezObjectWithParams unchanged

- Got rid of the llDie() call in the projectile, lest the timer() event trigger before collision_start(). The projectile is still temp-on-rez.

Are you seeing this consistently? If so, how do you define "first instance"? Is it the first rez event from the script after a sim restart, first rez event from a given rezzer object, or something else? I'm not able to readily reproduce this bug after either a sim restart or after rezzing a new copy of the rezzer.

Rezzer script:

key rezzed = NULL_KEY;
reportPos()
{
    if(rezzed == NULL_KEY)
    {
        return;
    }
    
    list details = llGetObjectDetails(rezzed, [OBJECT_POS, OBJECT_VELOCITY]);
    
    if(details)
    {
        
        llSetText(llGetTimestamp() + "\n" + (string)rezzed + "\nPos: " + llList2String(details, 0)
            + "\nVel: " + llList2String(details, 1), <1,1,1>, 1);
    }
    else
    {
        llOwnerSay(llGetTimestamp() + ": Object " + (string)rezzed + " is no longer here.");
        rezzed = NULL_KEY;
    }
}
default
{
    state_entry()
    {
        llSetTimerEvent(0.1);
    }
    
    touch_start(integer num_detected)
    {
        rotation my_rot = llGetRot();
        vector rez_pos = llGetPos() + <5.0, 0.0, 0.0> * my_rot;
        vector velocity = llRot2Fwd(my_rot) * 200.0;
        list params =
        [
            REZ_FLAGS, REZ_FLAG_TEMP | REZ_FLAG_PHYSICAL | REZ_FLAG_NO_COLLIDE_FAMILY,
            REZ_LOCK_AXES, <1.0, 1.0, 1.0>,
            REZ_POS, rez_pos, FALSE, FALSE,
            REZ_ROT, my_rot, FALSE,
            REZ_VEL, velocity, FALSE, FALSE
        ];
        llRezObjectWithParams("projectile", params);
    }
    
    object_rez(key id)
    {
        llOwnerSay(llGetTimestamp() + ": Rezzed " + (string)id);
        rezzed = id;
        reportPos();
    }
    
    timer()
    {
        reportPos();
    }
}

Projectile script:

default
{
    state_entry()
    {
        llParticleSystem( [
            PSYS_PART_FLAGS,       PSYS_PART_EMISSIVE_MASK | PSYS_PART_RIBBON_MASK | PSYS_PART_TARGET_LINEAR_MASK,
            PSYS_SRC_PATTERN,      PSYS_SRC_PATTERN_EXPLODE,
            PSYS_SRC_TARGET_KEY, llGetOwner(),
            PSYS_PART_START_COLOR, <1.0, 0.0, 0.0>,
            PSYS_SRC_BURST_SPEED_MIN, 20
        ] );
    }
    on_rez(integer param)
    {
        llOwnerSay("on_rez " + (string)llGetKey() + " param="+(string)param);
        llSetTimerEvent(1);
    }
    collision_start(integer num_detected)
    {
        llOwnerSay("Collided with: "+llDetectedName(0));
    }
    timer()
    {
        // invert color
        llSetColor(<1,1,1> - llGetColor(ALL_SIDES), ALL_SIDES);
    }
}

Judy Hynes

Maestro Linden
Yes, this is the difficult part of the issue, as you only get one shot at seeing it per sim per <some long period of time>.
I don't think any of the modifications you made should interfere with replication, but I tried to keep things as simple as possible to demonstrate the issue.  FWIW, I think travel speed is irrelevant, so you could slow it down if that helps.
Since I filed this report, I have replicated it many times and confirmed that having the flag REZ_FLAG_NO_COLLIDE_FAMILY allows the issue to happen and removing it never allows replication, so I am pretty confident the root cause is related to this flag.
Here is how I replicated it reliably.  Bear in mind I did it this way because I can't restart sims at will, and I'm surprised to hear you say that restarting did nothing to help replicate, but maybe we have a misunderstanding of what to look for.
Enter a sim where you can rez things. It MUST be a sim you have not performed the test on recently.  I'm not sure how long one has to wait, but it's hours at least.  I hopped around many sandbox sims first thing this morning so I knew I was testing in places I hadn't tested in for at least 24 hours.
Place a wall (or several) thick enough for projectile to collide reliably.  I used 15x15x15 arbitrarily.
Place launcher with positive x-axis aimed at wall.
Touch launcher once only.  The projectile will fire, report output from on_rez event, but will not report output from collision_start event regardless of how many collisions it has or how long you wait.
Touch launcher again.  This time you will see output from each collision_start event as you would normally expect.  Every projectile hereafter will behave as expected (i.e. no issue observed).
The current sim you are on is now "used up".  You must go to a different sim to replicate again, or wait for some unknown period between 1 and 24 hours.
It may be possible to use a different object with the same script (but a separate object as far as the sim is concerned) and reproduce for that object the first time it's rezzed on the same sim.  I think it would have to be the projectile, not the launcher, that is "unique" as far as the sim is concerned.  I have not explored this avenue since I was concerned that creating the object on the sim just to set it up might taint the experiment.  It has been more reliable for me simply to go to a new sim and have no doubt about the experimental conditions.