Inconsistency in copying running scripts

I have a script which depends upon its state (global variable values, lsl state, ...) being copied when an object it is running on is copied. Under the circumstances I tested (e. g. copying an object from inventory, copying and pasting the object back into inventory), this worked fine. But then a user discovered that when copying an object in Edit mode using shift drag, the script was copied along with the object but the script on the original object was reset, losing its state.

Is this simply a bug, as it seems to me it is? Or is there actually some rationale for it being this way?

When shift-dragging, the object moves and rezzes a copy of itself in place, so the script in the "left behind" copy is reset.

Yes. But that doesn't address the question of whether it is a bug. It seems like a bug to me because rezzing a copy of the same object from inventory doesn't reset either script. Nor does any other copy method I have tried.

It's not a bug. The copy in-wold methid generates a fresh instance of the prim and task, where copy from inventory restarts a task from th e last saved state. I'm under the imrpression this is to provide us the tool nessesary to generate new instances while still being able to start and stop a task without new instances.

Jillian,

Given my understading of what a "task" is, I would say that both methods create a new task, in bothe cases with the copied script state initialized from the original script state. The difference is that in the in-world case, the original script is then reset, while when copying from inventory, the original state is retained.

But even if you don't care for my wording as to what is going on inside, the result for the user is that scripts that can be copied are going to be flaky if they retain script state. I find it hard to believe that the Lindens purposely designed it that way. Would you actually argue that it is a good design decision?

I'm not arguing anything. I wasn't aware you were interested in persuing a debate. I'm just stating what information I have - however accurate or innacurate it may be - nothing more and nothing less.

It is important to be able to distinguish between maintianing the current state of a task in a copy and creating a total new instance of a task. When you 'Take' or 'Take Copy' of a an object with a running script, or a 'task' in SL lingo, the current state of that task is suspended and preserved. This includes both variable values and state status. Rezing the object, either directly from your own inventory, or with the llRezObject command, creates a copy of the original instance in the state of the original. This is an important and necessary functionality for the SL world.

As you noticed, creating a copy with the editor creates an entirely new instance with all values reset, or set to defaults. This is the only clean way to make a brand new, freash copy of anything, which is important to have when that's what you need.

Both types of copying are necessary. The first is a copy of an instances of a task. It preserves and maintaines persistance. The second form of copy creates a new instance of the task when you need to start freash.

Whether or not it's a good decision it IS consistent. For example if you have mod rights to another person's properties and you shift-drag to copy then the one you move is theirs, the one you leave behind is yours. Setting that to the default state for scripts then seems more sensible to me.

SL does have a few quirky design features, but we have to work with them mostly, and it's very unlikely this one will get changed because of the potential transfer of ownership problem I suspect.

Eloise, thank you for the thoughtful response.

It sounds like there is an overall acceptance of the way it works now, so I should probably just drop it. But let me explain where I am coming from. I'm interested in the ability to write scripts that have a robust behaviour. By that, I mean they act in ways that are intuitively reasonable to people who have no idea how scripting works. When I say the current situation wrt copying is inconsistent, I mean that the resultant behaviour of copying an object with a running script depends on the method used to copy it. Thats not something I want to try to explain to a user who doesn't understand scipting.

I'm pretty new here, so maybe I just haven't internalized the ethos of the SL universe yet. But if the goal is to build a robust world for non-technical as well as technical people, this seems like one small example of a design decision that should be re-examined.

I appreciate what you're saying. I remember being really confused the first time I realised that when I shift-dragged something I moved the old and left the new behind.

But actually once you get that the scripting thing does make sense. The thing you've moved carries it's current information, as you might expect. The one you've just made starts from new, it's a new object and a new script, so it's not that hard to explain to someone.

I do agree it's not the only solution, it's probably not the most intuitive model either although I suspect thinking more deeply about it, it makes sense when combined with no transfer objects where you shift-drag them and get a rude message about not being able to make a copy because of transfer rights but you do drag the original still.

But going back to the shift-drag vs rezzing from inventory - they're different things and I think everyone (at least after some time) in SL regards them as different. That said many scripts have an on_rez() reset type event... But if you think of it as "here's my tape recorder, with some recordings that I've got out of the cupboard" vs "here's a new tape recorder, same as the first one from the shop" it's not a hard concept to explain to most people.

The tape recorder is a good analogy for explaining the different results achieved by different ways of copying. Thank you. But does it explain why there should be a difference in the first place? Or which result you should expect when doing a copy/paste in inventory?

I know Tommy felt that it was necessary to have two flavors of copy, because sometimes one wants the copy to be in the original "unrecorded" state. But that is what script reset is for. Is there really a need to entangle resetting with copying?

BTW, if we accept as given that shift-drag is not a true copy, I have no strong feelings about which one should be the intact original and which should be the reset copy. The fact that they are different is what seems like a bad design decision.

Just to throw a sabo into the gears of this debate, when LL moves to Mono they are planning to recompile ever script. Ever script will loose it's state. (Don't like this? Comment on Mono here.)

So if script state is important, save the script state into prim attribute that is read/write. Like object description.


What we are discussing here are copies vs clones.