Detecting if a rezzed object is copied?

[jak Scribe]

HI,  I have an object that is copy, mod, no transfer but contains scripts that are copy, no mod, no transfer.

Every time the object is rezzed by the new owner it asks for a key number that can be used to call up the menu of the object.

My problem is that when the rezzed object is copied with drag-shift both objects contain the same key number, meaning both open their menu when called from the chat line. 

Can I detect that an object has been copied with drag-shift? Is there another way of solving this problem?

Happy for any decent suggestions.

[Miranda Umino]

Nope . It s the copied script who has got the same key . It s because  , without new compilation , the mono code is shared for efficiency .

In its memory , the sim needs only to load one time the bytecode of the script  , even if they are multiple  :

 

From http://wiki.secondlife.com/wiki/Mono :

"Indeed, Mono can do what's called bytecode sharing. Suppose you have a region which uses many instances of the same script, like XYText or Puppeteer, for example. As long as all the instances share the same asset id, the bytecode will only be added to memory once, and shared by all the copies. Key to making this work is ensuring that you simply copy the scripts (or the objects the scripts are within) after they have been saved for the final time. If you have purchased a script that is used many times, ask the creator for a Mono version, and then copy that version into the objects. It's important that you copy the scripts, so that the asset id is the same. If you recompile each instance separately, they will get different asset ids and the engine won't be able to share the bytecode."

 

Run this script to compare and understand :

default{    state_entry()    {        llSay(0, "Key of object="+(string)llGetKey());         llSay(0, "Key of script="+(string)llGetInventoryKey(llGetScriptName( ) ));    }} 

 

Result :

[15:26] Object: Key of object=a94c1925-6c8c-0497-ee61-d41e2eebed69

[15:26] Object: Key of script=41536914-9885-d89a-7c86-b9e75e8ee9a5

After shift drag

[15:26] Object: Key of object=221e84a2-ca03-a3f6-2651-2e491371ce49

[15:26] Object: Key of script=41536914-9885-d89a-7c86-b9e75e8ee9a5

After select all and recompile

[15:28] Object: Key of object=a94c1925-6c8c-0497-ee61-d41e2eebed69

[15:28] Object: Key of script=af5c0090-a220-5089-1a3a-594c39a532c1

[15:29] Object: Key of object=221e84a2-ca03-a3f6-2651-2e491371ce49

[15:29] Object: Key of script=fe7823af-054e-8d78-0ba0-c8bb5bbabd3f

 

Avoid to have different keys for your script ( for better performances ) and to recompile .In your script test with UUID of the prim and not of the script

 

I think it s the same with content  inside your prim  (as waves , animations notecarsd other objetcs etc .. ). If you shift drag , the content has got the same keys 

[Innula Zenovka]

I'm a bit confused.   You that each time it's rezzed it asks for a key number -- is this something the owner chooses or what? Since when you drag copy something, that resets the script in the new copy, why not do in the state_entry event for state_default whatever it is you're presently doing in the on_rez event?

[Void Singer]

for your case, if you cannot modify the script, then you can't do anything to change the behavior. there are multiple ways to detect that an object is not the original one the script was in, checking it's key as mentioned is the simplest, but most error prone (it'll also detect the prim as new if moved to a new object, or in some cases if it's simply rerezzed).... setting and checking prim properties that get wiped out upon shift-drag is a bit more reliable in the case of rerezzing.

[Innula Zenovka]

---

Void Singer wrote:

setting and checking prim properties that get wiped out upon shift-drag is a bit more reliable in the case of rerezzing.

---

Do we have an up-to-date list, though, of what those are, at least the readable ones?  The main channel server deploy of 11-08-15 lists among its bug fixes a "Fix to make shift copying copy all prim properties."   Sit targets certain seem to survive drag copying now, though I don't think texture animation does, at least not in the cases I've tried, so I'm a bit unclear now what survives and what doesn't.

[Darrius Gothly]

I believe that when an object is Shift-Drag copied, the one that moves is the original and the one that stays in the same place is the new copy. I also believe that the new copy will execute the on_rez event whereas the original object (that moved as it was dragged) will not execute that event.

Keep in mind that I'm basing that on memory only and can't log in just now to test it, but I believe that is correct.

I would suggest you use the on_rez event to generate the new key instead of something "fancier". After all, when an object is rezzed (or a new copy created by a shift-drag operation) then that's the exactly right time to generate a new key anyway.

[Void Singer]

der, forgot about the update.... hover text? sit text? omega?

[Innula Zenovka]

Hover text survives.  TargetOmega doesn't.  I'll check on PINs for llRemoteLoadScriptPin() when I get in.

[Void Singer]

PINs shouldn't, but the only way to check is to actually load another script... I don't think they'll ever provide a way to directly read a PIN for security reasons.

[jak Scribe]

Thank you for all the replies.

I was checking the script UUID but as  Miranda Umino mentions, the Prim UUID changes when the object is copied by dragging so I can check if this UUID das changed and request a new key.

@ Innula Zenovka: Sorry, maybe I didn't explain clearly:  Every rezzed object must have a different key, once the owner has entered a key via Dialog Menu then it will not be asked again (The owner can change it if required), and the key stays in the script even when the object is returned to Inventory and rezzed again.  The script is not reset when copied by dragging, therefore there exists two objects with the same key, making it impossibly to address only one of the objects.

Someone told me that they have objects that they can copy from Inventory but not copy by dragging.  I am looking into how that is done.

[Innula Zenovka]

I don't understand the problem -- when you drag copy something, the script in the new item resets itself.   Try this example to prove it.   Put it in a prim, set a number as the key, and then drag copy the prim and watch what happens.

 

integer my_key;integer handle;integer dialog_channel;list numbers =["1","2","3","4","5","6","7","8","9","10"];list order_buttons(list buttons){    return llList2List(buttons, -3, -1) + llList2List(buttons, -6, -4) +        llList2List(buttons, -9, -7) + llList2List(buttons, -12, -10);}default{    state_entry()    {        if (my_key == 0){            llSetColor(<1.0,0.0,0.0>,ALL_SIDES);            llOwnerSay("please touch me to change my key");            dialog_channel = ((integer)("0x"+llGetSubString((string)llGetKey(),-8,-1)) & 0x3FFFFFFF) ^ 0xBFFFFFFF;        }    }    touch_start(integer total_number)    {        key av = llDetectedKey(0);        if(av ==llGetOwner()){            if(my_key ==0){                llSetTimerEvent(20.0);                handle = llListen(dialog_channel,"",av,"");                llDialog(av,"Please choose a number",order_buttons(numbers),dialog_channel);            }            else{                llOwnerSay("the key is set to number "+(string)my_key);            }        }    }    timer()    {        llListenRemove(handle);        llSetTimerEvent(0.0);    }    listen(integer channel, string name, key id, string message)    {        llListenRemove(handle);        llSetTimerEvent(0.0);        my_key = (integer)message;        llSetColor(<0.0,0.0,1.0>,ALL_SIDES);    }}

 

[Void Singer]

llGetTime resets for the copy but not the original... so if it's under a certain value when the script starts that would be one way. it does not reset when rezzed normally. only useful if you aren't resetting it in the script though.