Norton Burns commented at 2014-05-08T08:33:42Z, updated at 2014-05-08T08:35:32Z

I've been testing this further with Warwick today.

What appears to be happening is that the fired prim does actually visibly disappear at roughly the correct point each time [allowing for the vagaries of life-span on such short-lived objects] yet the physics engine is still tracking their apparent position for some time after, giving the prim an invisible 5m+ range & fooling the meter into thinking it was collided with by a prim that isn't actually there.

The 'fix' is simple - add llSetPrimitiveParams([PRIM_PHYSICS, FALSE]); right before the llDie(); & the prims behave as they should. This leads me to believe that the llDie alone is no longer reliably triggering the physics engine as it used to.

However, SpellFire is a very old legacy combat system, a lot of 3rd party weapons & manufacturers are using a slew of untraceable old weapons & the nightmare of updating even the thousands of current users on 3rd party scripted versions reliably, let alone users of the original versions, which will/can never be updated, makes the process non-viable.

Of course, as it's advantageous to the fighter to have this bug, many wouldn't update even if they could, making policing the combat system even harder.

If anyone at LL needs copies of test setups, please give me a shout.

Maestro Linden commented at 2014-05-08T21:42:34Z

Hi Warwick and Norton, I tried this out in a simple case, but can't reproduce it in Second Life Server 14.04.16.289178. I made an object similar to what you describe, and placed it in the Library popgun. It seems that whether the rezzed prim is physical or non-physical, it quickly derezzes and doesn't cause collisions after disappearing.

1. Rez a default box, place the below script in it, then take it into inventory
2. Wear the "Popgun (drag onto yourself)"
3. Delete 'bullet' from the popgun inventory, and place the 'bullet' from (1) into the popgun
4. Edit the 'popgun' script and set the rez speed to 0 (I figure this is how a bladed weapon would be in SL?)
   • float SPEED = 0.0;
5. Fire the popgun a few times by mouse clicking while in mouselook

In my testing, the rezzed boxes derez almost immediately after appearing. I can't detect any collisions with them afterwards, either (to test that, I fired against a large wall a few times, then observed whether my avatar appeared to collide with any physical objects as I walked into the wall). I tried the nonphysical case too, as I know that's commonly used for melee weapon collisions.

default
{
    state_entry()
    {
        llSetObjectName("bullet");
        // because Norton suggested setting physics to false as a workaround,
        // I suppose the prim should be physical initially?
        llSetStatus(STATUS_PHYSICS, TRUE);
    }

    on_rez(integer reznum)
    {
        if(reznum)
        {
            // medium delay before derezzing?
            llSetTimerEvent(0.14);
        }
    }
    
    timer()
    {
        llDie();
    }
}

Can you please provide similar steps which show how one can make the bug occur?

Warwick Falconer commented at 2014-05-08T22:29:47Z

Hi Maestro,

Either Norton or I can provide a test setup to demonstrate clearly. However, you could also do the following:

1. Make a wall 3 meters from where the avatar will fire the weapon. Script the wall to report a collision event.
2. Create your damage prim as above, setting the timer to 0.07 (our most extreme issue). Under previous normal conditions (rezzed with velocity of 9) the prim would die before hitting the wall. Under present conditions, the prim will vanish, but still the wall will register a collision (out to about 3.7 meters!).
3. Then, add llSetStatus(STATUS_PHYSICS, FALSE)just before the llDie() function, and retest. The prim is stopped at the timer (at about 2 meters), and does not hit the wall this time, indicating in the previous test the physics engine is still seeing a prim afer the llDie() function.

Norton Burns commented at 2014-05-09T06:35:46Z, updated at 2014-05-09T06:55:45Z

The SF damage prims are actually set to rez at about 10m/s from the avi root, with a short die timer, as Warwick says.
Something it took me a while to discover on these is that you have to set physical/temp on the ground, rather than by script as they're fired. You usually set them back to non-phys/phantom on impact, but not usually at the die timer; instead relying on the die itself to cover all bases.

Not sure whether this is also relevant, but the scripts are usually LSO, the originals because mono wasn't available, but more recent ones because they appear to init & respond faster than mono, for very short-lived objects, preventing unwanted bounce.

I'll send you one of the problem weapons inworld, & my tester stand. The fired prims are invisible, so you just need show invis to visually inspect. (weapon needs setting to SF on the HUD too)

EDIT - test kit sent.

Maestro Linden commented at 2014-05-10T00:01:15Z

Hi Norton, I set up the dagger and target a bit and have taken some swings. The transparent objects that show up when I swing the blade are the prims that would collide with the target to trigger a 'hit', right?

I'm having some trouble with the setup right now, I think - using the 'Angel's Revenge - bloodbone, dagger RH' in 'SF' mode, I can only seem to trigger a 'hit' on the target (making it flash red) when I'm either standing on the pedestal prim or approach the target even more closely. My understanding is that the target should be counting quite a few collisions (reported as hits) when the bug triggers - so far I haven't seen this.

I also made up a mock target with this script, in a <3, 0.5, 3> scaled box:

default
{
    collision_start(integer detected)
    {
        llSay(0, "collision_start with "+llDetectedName(0) + " "
            + (string)llDetectedKey(0));
    }
}

So far, it seems to report one collision_start event per dagger (or zero when I miss :-P ), which seems correct.

Norton Burns commented at 2014-05-10T06:58:54Z

I made a quick video of the effect - https://www.youtube.com/watch?v=nhRRnzADMao
First part done with the regular SF prim, from the standard tester distance of 2.5m, from which the dagger should not be able to hit the target. Visibly it doesn't, but the reporter registers every one as a hit.
Second part done with a modified prim, adding physics off before the llDie. These no longer register on the target.

Maestro Linden commented at 2014-05-12T20:38:52Z

Okay, I see what you mean in that video. I added some debug logging, with llGetEnv("frame_number") reported by both the rezzed blade after it calls llDie() and in the target, and in the target prim as soon as the collision_start() event is triggered. I see that in the collision detected is often (always?) delayed from the time of the bullet's llDie() call. Sometimes the delay is 1 frame (22ms), though sometimes it's much longer; in the below case, the collision event is delayed by 7 frames (~154ms):

[13:25] 02sfcsdtmk_Dagger: Die at 16167032
[13:25] A&D Weapons Tester v1.8: Hit 02sfcsdtmk_Dagger at 16167039

The delay is expected, to some degree; when a script calls llDie(), the object simply gets marked for deletion in the near future. I would recommend using llCastRay() if you need synchronous results; this would also be better for performance in general, as you wouldn't need to rez any objects.

We may be able to change the behavior so that collision_start() events don't trigger for objects which have this 'pending delete' flag set, but we will have to be careful that it doesn't break other content (such as bullets which llDie() upon detected collision not generating collision events in the target they hit).

Warwick Falconer commented at 2014-05-12T22:55:50Z

Thanks for the effort on triaging this. I think a key point to keep in mind is, this is a RECENT bug introduction. This approach to weapons, although perhaps not too efficient, has been working fine for many years now. It is only recently that this behavior has been introduced. I might also point out, there are many thousands of these type of weapons that have been sold over the years. We currently support over 100 active sims using this weapon system, and without a solution for the bug they will be forced to abandon a huge amount of real $$ investment. Was your triage indicating you WOULD attempt to set collision events so they don't trigger for objects which have a pending-delete flag set? For the huge number of folks out there who have spent good money for their 'stuff', the issue isn't all that trivial. :-) Thanks in advance.

Alexa Linden commented at 2014-08-14T16:30:07Z

For those who are opening dups of this jira.. Please do not. This jira has been imported and is being investigated. Filing duplicates of the same issue with actually waste our time and thus delay our time triaging dups instead of working on the bug.

Warwick Falconer commented at 2014-08-14T23:31:52Z

Alexa, you know, a little communication would go a long way here. Are you working on this? Are you listening? To the contrary, your inactions waste OUR time...and we pay the bills. When Maestro Linden wrote " I would recommend using llCastRay() if you need synchronous results...", he clearly had zero clue as to what that recommendation meant, and clearly had no understanding of the community here. I know, we aren't a sex club so we don't rate high on your priority lists, but this community is quite large and deserves considerably better service from you.

And by the way, Maestro's recommendation is absolutely wrong...llCastRay() is pathetically inadequate in registering avatars.