Teleport and on_rez

A bug report landed in my lap from the 1.9 preview indicating that scripts do not get an on_rez() event after teleport while they do get the event on the 1.8 grid. This surprised me since scripts should not be getting an on_rez() notification except when rezzed -- such as when dragged from object/agent inventory to the world or when llRezObject() is called.

The current behavior is conceptually a bug since the object is being reconstituted as the same object and not really rezzed. Who relies on this current behavior, and how is it being used?

Most particle poofers/teleport effects do, and a great many scripts rely on this to reset themselves after a teleport.

It's a bug that's been present for so long, it's a feature.

Ditto.

Thirded.

I use the attach event myself I think. That is suppose to fire on teleport isn't it?

Personally I think it should be fixed, I always wondered about this behaviour and it's caused me indigestion in the past and extra code so that things set on_rez aren't reset on teleport. (not to mention I hate poofers anyways)

=Riz

I've got several freebie teleport effects that rely in this wandering around. I also rely on it for certain attachment tools that behave better and take fewer resources if it doesn't have to costantly check to see if it's in the same sim as it was (in combo with moving_start()).

Please let us keep that!

I use it the way it is now, and while it wouldn't be a *major* hassle for me, since I don't sell any products based on it, I would as soon it not be changed.

I use this in products I sell. One of them it probably wouldn't break a whole lot, one of them I'm pretty sure I'm going to have to re-write some of the logic if this changes.

Is there an easy way to determine in an on_rez event whether the event was triggered because of a teleport? If so, leaving it as is might be okay. If not, you could add another event that works properly, but keep the behavior of the current event. The bug with rotations for child prims was solved like this, though I don't remember the exact functions and I can't find the link to the LSL wiki (why isn't linked from the public site somewhere?).

How would we go about detecting whether a user teleported to a destination without on_rez? Is not the user's avatar "rezzed" at the new destination?
As p2p teleport now allows one to teleport to a location less then 1 meter away from ones previous location, the only way to check for this condition would be to schedule a timer event that checks for continuous movement position to position. In order for this to be reasonably accurate, the timer must execute at a quick interval - less then 1 second between events, an obvious contributer to lag. The moving_start/end events cannot be used to detect teleport, as the teleport itself does not trigger them.

Dont take functionality away from us. If you correct this "bug", add a new on_teleport() event.
==Chris

I agree that there should be an on_teleport call for LSL and would help everyone out, though cause some minor rewrites.

I have seen it used but never currently liked the on_rez triggered on teleport. For things such as usage command triggers for certain stuff I moved it from on rez that triggered it to on attatch and that way it tiggered on login I think too, but otherwise only when worn.

As for poofers, since particle effects stay on a prim once set, would it still need the script to trigger on_rez to poof? I thought that once set, anytime the prim "rezzed" so to speak with the avatar it would still trigger until removed. (I just woke up and thought I would add some thoughts to this subject so my facts may be a little off)

I guess its true, so many people have used it as a feature for so long that without a backup solution, it will be considered a bug that it no longer works on teleport with the update.

I believe attach is the correct event to use. It should fire when teleporting.

integer was_dettached = TRUE;

default
{
    attach(key id)
    {
        if (id != NULL_KEY) {
            if (was_dettached) {    // Go ahead and do your attach stuff, it wasn't a teleport.
                was_dettached = FALSE;

            } else {
                // Oops, this thing wasn't dettached, this must be a teleport.
            }
        } else {
            was_dettached = TRUE;

            // Do your dettached stuff here.  Dettached isnt fired on teleport.
        }
    }
}

You probably want to check with the Gorean sims, they have a lot of gadgets that have to keep track of attachment and detachment, and may be using workarounds for teleports that would run into problems...

I'd say Rickard's code is the right way to do things (thanks) but you might want to go slow on this fix... even to the point of having on_rez fire for existing scripts until they're recompiled.

So, conceptually, if an object isn't re-rezzed when you materialize after a teleport, why is it re-attached? Seems to me that the attach event firing is another "that's just the way it happens" thing, just like the on_rez event. Or is there a logical reason why an object should get a new attach event after a teleport and not an on_rez event?

The best solution is probably an on_teleport event. Failing that, everything else seems about equally hacky to me. I'm happy to code using the attach instead of the on_rez, if there is any guarantee that that won't change some time in the future too

And if it isn't rerezzed why does it get a new key each time?

Having on_rez() triggered after teleport makes perfect sense to me. When you teleport, you and your attachments do indeed de-rez from the world for a brief moment before being rezzed anew in the destination sim.

Oooh, I think that's the smoking prim there. Do we need to move all the code to reset stuff that might depend on the object key so it's called on attach as well as on_rez?

yes. And the reason the key changes on teleport and sim crossing is because objects are serialized (converted to a flat data stream) and sent between simulators. When they get where they are going they are deserialized and assigned a new local uuid on that server.

If they get serialised (to inventory format?) and recreated from scratch on the new server, then shouldn't they get on_rez events?

What about teleports within the same sim?

I don't remember objects changing keys on sim crossings

Same as Cid - keys change on tp, not on crossing sim borders in the virtual flesh.

LOL,

You all just realized that there is currently no way to tell the difference between an on_rez event (or an attach event) from:

1. An actual rez or attachement from inventory,
2. Login and
3. A teleport?

Sure would be nice to know how to distinguish between those three...

And, yeah, it's extremely annoying that you get new keys for attachments during a TP.

I hope you realize that the amount of CPU time your script gets on a detach event is pretty minimal and is at least partly affected by server load. There is NO guarantee that any code in a detach event will have time to execute. This got particularly worse after 1.7.

I think the best solution would be to make two new events. teleport_start and teleport_end, where teleport_start would fire on teleport and teleport_end would fire on arrival.