Owner of object rezzed by an object

Has anyone encountered this?

The following lines of code exist in a script inside an attachment:

collision_start(integer num_detected)
{
key shooter=llGetOwnerKey(llDetectedKey(0));
llOwnerSay("shooter is " + (string)shooter + " " + llKey2Name(shooter));
}

This is part of a larger script which is handling hits from bullets, so they are often coming in very quickly. The purpose is to detect who the person is that is shooting the wearer of the attachment.

Unfortunately, it doesn't return the actual owner key, but apparently the keys of the bullets.

There is a JIRA entry which I've commented on related to this, but it could be it's simply something I am doing wrong. I've tried it the above way, and also tried it by looping through num detected as follows:

integer x;
do {
key shooter=llGetOwnerKey(llDetectedKey(x));
llOwnerSay("shooter is " + (string)shooter + " " + llKey2Name(shooter));
++x;
}
while (x < num_detected);

Either method returns the same result: a list of seemingly random keys, none of which resolve to the name of the shooting avatar.

This is the relevant JIRA entry:

http://jira.secondlife.com/browse/SVC-3799

so it looks like from what everyone is saying, that if you purchase an item, then wear it without first having rezzed it unattached, the bullet in inventory is essentially showing no owner? that'd be a bad bug, for a few reasons I can think of...

the code is right, and pehaps it's just that with the speed of the bullets from rez to impact and die, the sim just just doesn't get enough time to plug in the bullets owner, or it's dying before the script can ask for an owner (the sim is responding back with just the key since the object no longer exists so it can't have an owner, and must own itself) which might explain why one gun seems to register (it's bullets don't llDie)

you could try speeding up the detection by inlining it all, but I doubt it'll help but it's worth a try...

collision_start( integer vIntTotal ){
  llOwnerSay( llGetOwnerKey( llDetectedKey( 0 ) ) );
}

that's about the fastest detection you can get... to do fast loop checking you could us an @if-jump loop and run it backwards using the count from collision start like so

collision_start( integer vIntTotal ){
  @Loop;
    llOwnerSay( llGetOwnerKey( llDetectedKey( --vIntTotal ) ) );
  if (vIntTotal) jump Loop;
}

I changed it to use llDetectedOwner(0) instead and I'm getting 100% correct detection now. So yeah, I think you are right about the bullet dying before it has time to detect it. My problem's fixed, but that still seems like a bug to me.

it sort of is... avs info is kept by the sim after they exit, you'd think objects would be similar. but once they are off the sim, they are cleared from the reference list (or so it would seem)

(I forgot about using detected owner, doh.)

Yeah, use the llDetected*() functions directly whenever you can. llGetOwnerKey() will simply return its argument if the object cannot be found for some reason (is in another sim, or perhaps has already died because it is temporary or calls llDie() immediately on collision). You could also check that the value of the final key you use results in a llGetAgentSize() that is not ZERO_VECTOR as a sanity check (though again it will have an issue if the owner is not in the current sim; to be REALLY thorough you'd have to hit the data server with something like llRequestAgentData() and a time-out).

In this case speed is more important to me than 100% thoroughness.. if I miss a few its okay, but if I lag a combat script to double check and verify .... hmmm no....

In any event, thanks! Working this project has been a real education

the reason detected owner works isn't actually because of speed, it's because that info is transmitted in whole to the collision event, and the detected functions just access the parts they need. (and I'll update and drop the priority of the jira, it'll probably be closed as expected behavior but I'll leave that to someone else)

Right. But hitting the dataserver and waiting for the reply WOULD probably have an impact on performance. It might not be a huge one unless it is being done incredibly often, but if it's not necessary, it'd be good to avoid it. I think that's what that comment was aimed at, and I'd have to agree with the conclusion.