detecting click-drag copying

Is there a way to detect that an object has been copied using click-drag? The way I understand it doing so re-starts all scripts, whereas dragging a copy from inventory maintains the scripts' states. The implication is that if you have a script that does nothing but start a texture animation, you can't delete the script because the animation will stop for copies made with click-drag.

What I'd like to do is detect that a copy was made using click-drag and tell the user that the copy won't work, and they should instead drag a copy from their inventory. That'd allow me to delete a bunch of scripts.

You can make a separate script just to check if the item is shift-copied. In the default state entry to check if it belongs to you (just for debug sake), then if it's not it will die. Every time the script will be at OK state when it transfer to the next owner.

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
default
{
state_entry()
{
if (llGetOwner() == "your_key" state OK;
else
{
llOwnerSay(" shift-copy is not available. To make copy of the current item > Right Click > Take Copy.";
llDie();
}
}
}

state OK
{
state_entry()
{

}
}
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

It'd have to detect shift-drag copying without ownership transfer, and it'd have to survive a reset without triggering the warning. The idea isn't to prevent copying.

Texture animations persist when an object is copied from inventory, but not when copied using click-drag. To survive click-drag, the scripts that start the animations need to be present. Seems like a weak reason to keep scripts around. I'd rather just discourage click-drag, but I also don't want to confuse users with warnings that don't apply.

Tell me please, is it not obvious if the texture animation has stopped (by looking at the prim)?
I do appreciate you want to get rid of the script, but it is a bit hard to script a solution for this without having a script

Yes, but the purpose isn't to tell the user the obvious. The purpose is to give the user a solution so he doesn't have to contact me.



If I could delete the animation scripts I'd have 14 fewer scripts in the object. The detection would go in one of the scripts that remain. All the detection script has to do is inform the user how to resolve the problem.

In that case, how about my adaptation of Klug's script:

default
{
    state_entry()
    {
        llSay(0, "If you are reading this and wondering why the texture animations aren't working, it probably means you've copied me by using drag-copy instead of making another copy by dragging it from your inventory.");
        state running;
    }

}
state running
{
    state_entry()
    {
    }
}

same concept applies to automatically enabling those animations without wasting script overhead (at least in mono compiled scripts)

it seems mono compiled scripts only activate the current states code (at least that was Strifes guess, some form of JIT compiling, explaining why state changes are slower in mono) so putting that code into a primer state that excutes the animation, then forwards to a working state 'should' eliminate the overhead for the animations, while maintaining your working code (and removing an extra script), also good for just about anything that configures once, then runs indefinately.

of course that might not help with cases where the animation is the only script running in that prim... although forwarding to an empty state might help some.

remoteloadscriptpin might also work in cases where you just want to delete the animation script after running, although i'm not sure if the pin is a prim property or not, or if it survives shift drags, you'd have to test. assuming so, you could differentiate animation settings based on prim name, description, number, or start param, to only have one (inactive) script to give to multiple prims.

Thanks, but I don't want to display a warning when it doesn't apply. No matter how I word it people will wonder, "did I just break it? the animations look alright. What should they be doing that they aren't? So, I'd want the detection script to give its warning only when the item has been click-dragged. I don't want it displaying any warnings on reset, or ownership transfer. I was hoping there was something I could test for that only happens on click-drag copying.

The animation start is one line of code, two if I make the changes I'm about to describe. I suspect adding a state to the script, even if empty, won't save anything. I wish there was a way to monitor script server resource usage that closely.



I think the overhead of obtaining UUIDs would outway the benefits of deleting the tiny anim scripts. That, and the user doesn't have mod perms.



This I think will work. Right now all 14 scripts are unique, but only because they have unique framerates. If I calculated the framerate from a number in the prim name then I could take advantage of mono's code sharing. I'd have three unique scripts instead of 14. This, I believe, is a good compromise.

Thanks!

There isn't a way for a script in the root to check the animation state of child prims, is there? If there were you could give a warning only if the animation did, in fact, stop.

I'm assuming you made the item, then without ownership transfer, the item will be owned by you always. Then why does it require any warning msg when it is hardcoded by you? Unless someone has permission to shift-copy your object and warning msg goes to him/her or llOwnerSay() to you?

I'm a bit confused and correct me if i'm wrong...

Someone buys the object. There is an ownership transfer. The script resets. I don't want a warning.

They rez the item in-world. They click-drag a copy. I want a warning.

They reset the item. I don't want a warning.

unfortunately manual and dragged resets of the script look the same to the script... now assuming there is only one of these in a give area rezzed, you could have it look for a copy of itself on script reset, it it's found, reinitialize the texture animations. you'd get reinitializations when there were more than one object in the area, but it'd be a small cost.

could bear looking into, I believe there are a few prim properties that won't survive dragging, and you could try checking those. it's been awhile so I'm not sure if I'm remembering right, or even if I am that those properties are readable (might only be settable). perhaps some of the status' (like axis locking), or maybe even material type.

The script won't reset while it changes ownership unless you made it in a change event, or they press the reset button on the script. So the script will be in the OK state mentioned earlier.


Now it's shift-copied and the script resets thus the warning comes out.


ditto

oh, also if you'd like to have some "reset", you could do it from a menu response etc. Instead of reset the script, you could re-initialize variables, do the texture anim etc...