Event just before teleporting

I would like an event to trigger just before teleporting and/or just before logging out. I suspect that the event I'm looking for is the attach event, but I can't get it to work.

default
{
    attach( key id ) {
        if( id == NULL_KEY ) {
            llSay( 0, (string)id );
        }
    }
}

This doesn't work, however I have seen attachments which seem to do things right before tping or logging out.

Remember this has to happen just before the tp or log out, not on arrival at a new sim.

I think that feature is broken. It was always unpredictable anyway. How much of the script was executed before the object was detached depended on how busy the sim was.

I just tested it myself and it seems to work fine when detaching an object. The attach event gets called and you see your message before the object is finally detached. But for teleporting, I saw nothing. Not before teleporting, not after.

Doctor Spock wont be impressed by this news.

Apparently 1.9 is changing the details of how teleportation works... objects are not re-rezzed after teleport, and it's been reported they don't even get new UUIDs. I assume they're doing direct sim-sim transfers like they do for region crossing, rather than saving them to the asset server and restoring them like they do now.

I hope so, anyway. That'll make teleport a lot quicker and smoother.

Yeah, I took a look at that thread before I posted...

The thing is I've seen attachments which do stuff before logging out and before teleporting. I guess I'll have to track down that creator and see if they are willing to share.

I have a hunch the objects that do things before TP actually work by touch or voice command.


there's a new event flag for the "changed" event coming in 1.9


CHANGED_TELEPORT

woot, roll it on!

I know for a fact that it is automatic. There's no voice command or additional action taken by the user. There is a way to make something happen before a teleport or log out. I just don't know what it is.

The new changed events are very cool but only works on arrival in the sim, the new options can be used in combinations or alone, if you teleport to same sim, only the teleport one is triggered, if you teleport to different sim bothe the region change and teleport are triggered and if you walk across a border only the region one is triggered.

Alot of things in 1.9 are now sim-sim, this is the biggest part of the 1.9 release and many people wont notice it although its quite important for scalibility im's from person to person are now sim-sim instead of going by the space server, inventory transfer between people is the same, region crossing is handled in the same way and is much smoother even when wearing prim heavy av's, teleporting seems to have improved the most, there is no more saving of attachments before teleport teleport is now only takes slightly longer than a teleport to the same sim, the extra time being used to contact region and performing handoff. The upside of this does seem that uuid's of attachments stay the same after teleport, and they are no longer rerezzed (propbably why the on_rez call no longer works)

How do you know?

I hope they'll notice it.

I spent fifteen mintes last night teleporting all over Shiva just enjoying NOT having to re-rez and wait for myself to lose the loading textures after every hop!

It's still multiple seconds to teleport sim-sim, but not 20 to 30 to a minute like it is in Agni.

I think they should not bother showing the progress bar or making the teleport sound until a couple of seconds into the teleport, so that short teleports are no more than a momentary freeze.

Because there is an object that does it. It performs a stop animation on avatars before it leaves the sim. My friend has one, and we tested it last night. The object started animating me, she logged out and just as she poofed, the object stopped animating me. So there must be something happening before a teleport.

It's becoming obvious that the creator who did this found a very clever and not well know solution to this problem. In that case, I don't actually want to find an answer here on the forums. I thought it might be something simple and fairly well known, but if it's a solution that only she has thought of, I don't want help from others to figure it out. It feels too much like I'm enlisting others to crack someone else's code. I'll leave it be and hope that I eventually find a solution on my own.

I've found this thread to investigate my problem.
Huh? Don't be so serious, Keiki, is that just sensoring and stoping thingy? Most of the animation vendors use that because they have customers play their demo just by touching.

OK, then, my turn.
hmm... is this true? Accoriding to the Wiki, CHANGED_TELEPORT is "ADDED IN 1.9.0 The object has been teleported". I'm totaly poor at understanding English, so plz help me. What does this present perfect form mean? Which does the trigger fire when dissapearing or appearing?
Nathan seemed to say that it fired when appearing. But if so, you don't need CHANGED_REGION at all because CHANGED_TELEPORT can work for it. I think CHANGED_TELEPORT should be fired at the point where you disappear. What do you think?

If the object was attached to your friend, then the object exited the world when they did, and the automatic permissions cleanup would have cancelled its animation permission.

If the object was rezzed in the world, it can detect your friend via a sensor or dataserver.

If you really wanted to do an effect on teleport, the easiest way would be to rez a 100% alpha prim that follows you around, detecting you. If it doesn't detect you, it does a dataserver call to see if you're still online. If you aren't, you logged out. If you are, you probably teleported. Either way, the alpha object can throw a particle effect or something similar before killing itself, and the attachment can rez a new one at your new location.

Two things, Yumi. 1) This thread was from before 1.9, so it was before permissions were cleaned up in this way. 2) Secondly, permissions isn't the issue, stopping an animation that was previously played is the issue. So that's a kewl idea if I wanted to do a poofer on exiting a sim, but doesn't provide a workable answer to my problem.

I think Yumi's answer was perfect. Consider what forces you to keep playing animation. It must repeat llStartAnimation again and again by timer. Then if it has gone, there is nothing to force you to play animaton any more. It has long been happend.
I thought the object was left in world, so the trigger of llStopAnimation had to be the time when it undetected the owner by sensor.

I'm not sure I understand you Seagel.

When you call llStartAnimation, it applies a property to the avatar. It doesn't have to keep applying the animation over and over again if it's looped (like a "stuck" pose or a looped dance). Apply it once and your avi will keep doing that animation until that script or another one explicitly tells it to stop. There is no timer that reapplies the animation over and over again. And for it to tell you to stop, you must be in the same sim as the object.

If the object with the script leaves the sim, or the animated avatar leaves the sim, the avatar will keep playing that animation. That's just the way it works.

Aha, timer had not something to do with this, sorry.Is this really happening? I made sure that if you teleported while sitting on the pose ball, the animation would be stuck. But it is the 1.9's bug. hmm... I have to make sure it.

Yeah, applying an animation to an avatar is sort of like adding floating text to a prim. Once the script applies the animation, you can delete the script, the avatar will retain the animation.

I'm now at work and I've not tested it, yet, but if so, don't you think it is an obvious bug?
And before 1.9, it never happened. As Yumi said, it was just a permission issue that someone could stop your animation.
Then, as I hoped, CHANGED_TELEPORT fired just before going, your issue would be also solved.

It's not a bug anymore then when a script changes the color of a prim and then is removed, the prim retains it's color. Animations are properties applied to an avatar. They are not actively played on the server. They are an effect that we see client side only.

Unless the specific animation is removed using llStopAnimation (or the animation is covered up with another animation of equal or higher priority), the avatar will continue to display the animation. That's the way it's been long before 1.9. My inquiry here has little to do with 1.9 actually or with permissions.

I heard, "Teleport to avoid sticking animation". Has my knowledge been outdated, yet? Then, whenever the object that granted permissions to you was deleted by accident, what should you do?
hmm... Were you playing multiple animations at the same time?

Well I used to tp to another sim, but that doesn't work in 1.9. Now your only recourse is a stop-all-animations script or logging out.

What are you talking about?

That has nothing to do with original question... figuring out what if any event fires on an attachment before you leave a sim via tping away or logging out.

---

I'm sorry Seagel, I know you are trying to help, but it's like we aren't in the same conversation.

hmm... I have to agree with you. I'm sorry, too.

I wrote the following script and made sure that even a looping animation stopped just when the object including the aniamtion firing script had gone out of the sim.
:::USAGE:::
1. Create a cube.
2. Put the following script and a looping animation into it.
3. Touch it.
*The object will be lost at 10 seconds after touching. Don't put no copy animation file into it.

default
{
    touch_start(integer total_number)
    {
        llRequestPermissions(llGetOwner(), PERMISSION_TRIGGER_ANIMATION);
    }
    run_time_permissions(integer perm)
    {
        llStartAnimation(llGetInventoryName(INVENTORY_ANIMATION, 0));
        llSetTimerEvent(10);
    }
    timer()
    {
        llDie();
    }
}

I don't think this is the new feature of 1.9.

Hmm... I tried your script and the avi did stop moving when the object was deleted. Which is interesting. I didn't think that was the case. I'm sorry I was insisting a particular behavior that isn't true.

Unfortunately, it doesn't help with my particular problem. I retested what's going on in my script and it's still the case. If the object is attached to one avi and that avi leaves the sim via a tp or log out, the other avis that are being animated continue to be animated. This is the same behavior I've observed for at least 6 months.