Script memory loss on drag-copy

[DavidThomas Scorbal]

Checking if this is still The Way Things Are (tm) ...

If I drag-copy a scripted object, the original object (the one still sitting in the same position) has its script memory reset, correct? And the new copy that sits where I end the drag, that one now has the script memory of the original object?

Is there no way for script memory to survive a drag-copy? (other than the obvious of "don't do that")

 

Thanks

[Pamela Galli]

When you make a copy, the script in the copy is reset. Counter intuitively, the original is the one you drag. You can make it so the settings stored in the script are instead stores in a notecard, and the script accesses that on reset.

---

DavidThomas Scorbal wrote:

Checking if this is still The Way Things Are ...

If I drag-copy a scripted object, the original object (the one still sitting in the same position) has its script memory reset, correct? And the new copy that sits where I end the drag, that one now has the script memory of the original object?

Is there no way for script memory to survive a drag-copy? (other than the obvious of "don't do that")

 

Thanks

---

 

[DavidThomas Scorbal]

Can't use a notecard ... the script contains things dynamically generated by using the prim.

Strange that the original is considered the one that you move ... but I guess that makes some sense in the light of how the memory reset ... (err, the memory isn't copied) ... works.

Thanks

[Christhiana]

If you only have to store a little bit of info you can always use the description field of the object.

[DavidThomas Scorbal]

That's true. It's a bit of a hack, but it might be good enough for this usage case. I'll have to look into maybe loading the data from the description line at script startup, if it's there. Thanks

[steph Arnott]

The new script has its own entity. It not a copy. any soft code is atributed only to the memory block that  UUID

[steph Arnott]

"It's a bit of a hack" it is not a hack and never has been, also it is extreemly unreliable.

[Yingzi Xue]

Another reason the drag copy works the way it does...  Since the original is the one that moves when you drag copy, its history stays intact (recent positions, scales and rotations) and can be cycled through via CTRL-Z (undo) and CTRL-Y (redo).  This comes in handy, for instance, when you need to move the prim/object back to its previous position after making a drag copy.  Each prim/object keeps track of its own history, which can be scrolled through using undo and redo keyboard shortcuts.

[ChinRey]

---

DavidThomas Scorbal wrote:

Strange that the original is considered the one that you move ...

---

There is a relatively easy way to work around that: Copy-drag, move the copy out of the way, select original and use ctrl-Z to snap it back into place.