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.
Log In
Nexii Malthus
I was curious about the issue and tried reproducing the bug.
Since the issue seemed to do something with the first instance of an object with the sim/physics engine I had a hunch I could use an adjacent region to bypass any issues you might encounter if you try to create the object in the current sim.
Was able to reproduce the bug consistently and recorded it on video:
Additionally discovered a curious characteristic that not ALL collision events were bugged out -- turns out the first instance of a projectile has an inverted collide family logic where it can ONLY collide with own projectiles, and also gives them collision events as well!
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
tracked
Maestro Linden
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.