Transfer Problems With Swordfighting Script

Hello everyone. I'm designing a set of retractable hand claws, using a modified version of Cory Linden's Swordfighting script that I took from the freebie "Street Fighter" attachment.

The problem I'm coming across is that when I give a copy to someone else, they can't attack, but I have no such problem when using them myself.

Here are some pertinent details of their design:

- The claws are Mod/No Copy/Transfer and the script is No Mod/Copy/Transfer. (I don't want anyone blowing the llPushObject power out of control.)

- The claws use two scripts, one being the Swordfighting script, and the other for the extraction/retraction of the claws. Both of these reside in the same prim in a linked set.

- The claws are attachments, of course. One set of linked prims.

- The extraction/retraction script uses a listen to take commands from the owner.

This problem has been driving me absolutely crazy. Is there some kind of permissions problem? Does the Swordfighting script need to be in a seperate prim? I've already had problems with the Swordfighting script, in that if I mod it at all, it stops working. Maybe some sort of attachment issue that I'm unaware of?

Are there any listens involved?

If so, and the llGetOwner test is in the llListen, take it out of there and put it as a conditional in listen(). If you do llListen(0,"",llGetOwner(),""; and don't reset the script when you give it to a new owner, it'll still be listening to you.

But I doubt that's the problem.

Yeah, already had that problem with the retraction script. I didn't change the listen, but instead opted to put it in the on_rez event.

This problem is with a completely different script in the same object.

Just on_rez reset all the scripts involved. Done.

I already tried that with the Swordfighting script and it ceases to function.

Wait- you just put the llListen in the on_rez?

That's a bad idea. You're going to keep stacking listens and eventually it'll catch up with you.

If you don't have any saved variables (like wether it is on, off, etc.) then just do like already suggested and add llResetScript() to the on_rez. For simple items that do not require between rez variables to be saved it is the best way to fix this problem and by far the easiest.

You can also continue to put your listen in the onrez just fine with this method without stacking as well since the reset will remove previous listeners, owners, everything. Just make sure the reset script is at the top of the on_rez and not the bottom. heh.

Well, I ended up just replacing the attack script, and all is well now. Guess the first one I tried was bugged.

Lance, I'm not really sure what you mean by stacking listens. The claws are attachments, so wouldn't the listen die when they're de-attached?

Failing that, instead of resetting the entire script, couldn't I just assign the listen to a handle and executing a listen remove on rez, before the listen is established?

No, because scripts don't reset their memory state when they go into inventory; rather, they get it saved and then start where they left off upon being re-rezzed.
Yup, that's what I'd do.