Will execution continue upon re-rezzing an object?

Suppose an object is de-rezzed (deleted, taken back etc) while it is in the middle of executing a script? Later the object is re-rezzed. What happens in the script?

I understand that it would resume back in the same state upon re-rezzing, but would it continue executing where it left off if it was in the middle of something? If it's in the middle of executing a function, will it continue where it left off? Or would that happen to begin with? Where would the script have left off when it was de-rezzed. Would de-rezzing in the middle of a function even be allowed or would it be forced to complete before de-rezzing?

In my experience, the script generally finishes what it was doing, then runs the on_rez() event (if any).

Assuming it was in the middle of a large amount of processing within one event, it is suspended and the state of the script saved so that it will resume exactly where it left off.

If you are trying to synchronize where it gets suspended, that is very hard to do. Most likely, you would have to have some kind of delay (via llSleep) so that the odds of it getting saved during the sleep are significantly higher than any other time. There's no guarantee of that, though, as sim lag can delay the actual state suspension and save operation.

Depends.

If you WEAR or rez an object you can't copy, then yes, I would expect the code to carry on where it left off.

But in most cases, when you rez something from inventory it creates a NEW copy. New object means new copy of scripts, means new run state.

Therefore: Rezzing something you made onto the ground will appear as if your script got reset.

Actually, that is not correct, Rusty.

All script state get saved on Take or Take Copy. That's why the llListen(c,"",llGetOwner(),""; problem is so odious, because that listen gets saved as part of the script state, even in copiable objects.

Try it yourself. Put this script into a prim, touch it, let it run for a few seconds, take it, and then re-rez it. You will see that it continues right where it left off:

default {
touch_start(integer iCount) {
integer i;
for (i=0; i < 1000; ++i) {
llOwnerSay((string)i);
llSleep(1.0);
}
}
}

I stand corrected! Thanks! =)

Very curious that copying an in-world object with "shift-drag" does not mimic that behavior.

In the case of making a copy, even using shift-drag, you are creating new assets including new scripts. They would have to start at state_entry.

A related question. Is there a way of preventing an object from de-rezzing or restricting it to a certain state. If I'm in the middle of a money transaction and waiting for a reply from another object, like a server, I would like to be sure the transaction was fully completed before the object could be taken out. Otherwise there is potential for abuse. I think the answer is no from everything that I've read.

There is NO way at all to prevent your object from being derezzed. None at all.

Which is exactly why I presumed the behavior would occur while rezzing a copy of something from inventory.

Aye. The difference is that a shift-dragged copy doesn't copy states, just the assets. It would be hard for the sim to copy state without going through Inventory first. The way shift-drag copying works is the same as if you built the prims again from scratch, and put the scripts into the contents from Inventory. Basically, the client is "speed-building" it for you; the server doesn't actually do the copying.

With take into / rez from Inventory, the server is handling it, and it saves/restores the state of all scripts as well.

Bizarre.

I haven't looked at the code... but I thought for sure the sim was handling the drag-copy operation, not the client. Anyway, it is the way it is.

Well, I am not 100% certain of that; it is simply what the behavior indicates is happening. Otherwise, I don't see why it wouldn't make a copy of state as well as the rest of the metadata. The only other reason I could think of is if the server has to create a new object from scratch itself since it does not go through inventory.

Don't really understand why anyone that is interested in the answer to this doesn't just make a counting script and try all the different scenario's.

That's what I do when I am not sure about something. Make a simple test script and hit beta. Try it all different ways until I am 100% sure what is going on.

I jumped to a logical, but incorrect, conclusion (in the context of rez-from-inventory, but it was correct in the context of drag-copying).

Once Talarus corrected me I did try a few test cases. Of course, I feel rather foolish now... I deliberately make a point of putting in nearly all my scripts:

on_rez(integer n) { llResetScript(); }

Which, obviously, wouldn't be necessary if rez-from-inventory worked the same as drag-copying. I'd been doing that automatically for so long that, for my scripts, rezzing from inventory DOES behave more like drag-copy effectively... I'd just gotten used to the effect and forgot I'd imposed it.

Don't feel bad. I have the bad habit of forgetting to put that in. 95% of my scripting is strictly for myself, either curious about something or something I need. I of course never notice it myself until one of my freinds can't figure out why my script doesn't work for them.