on_rez

* on_rez() is no longer called on scripts after a teleport.

That one gone destroy for many if it dont get trigerd on TP..
i dont use it my self cus i know how to use attach but i know many that use that to triger tings.
So way destroy somting that already working?

I TOTALY AGREE!!!!!!!!! Poof's that "poof" on teleport will no longer work......its dumb to remove something that wasn't causing a problem or even broken in the first place!

Yes, I agree .. if this doesn't need to be changed, don't change it.

Fixing something that isn't broken is a very unfortunate thing to do.

Poof's are going to stop working?
This is a bad thing?

It was replaced with Changed_Teleport change event

I'd be less concerned about the fact that poofs will stop working (which is basically no loss at all as far as I'm concerned) and more concerned about whether this means that objects are no longer destroyed and recreated on teleport.

That's what it sounds like. I think the idea is that certain things just don't work right with the current on_rez system. Like for christmas I made some mistletoe that hovered above my head, but which I could hide on command. After teleporting though it would be visible again and I'd have to hide it again. Or I'd have to have it hidden by default which I didn't want!

However, a better solution IMO would be to have an llSetRezMode() function, allowing you to set it to destroy/recreate on rez, or remain as is.

This way existing things needn't be broken, while new objects that want to retain state during a teleport can switch this off and use CHANGED_TELEPORT instead.

It may also be a drain on system resources to have objects doing that, especially as people wear more and more scripted attachments which are affected by this. If they can do some intuitive way of keeping objects running then it will require no such load, and open up more options for attachments.

I would guess that its probably because the item is no longer destroyed and created (re-rezzed) after teleport, from all my tests any attachment worn retains the same key both on border crossing and after teleport.

Oh, now that's nice!

Nathan, have you had a chance to test whether scripts retain their assigned XML-RPC channels on TPs and/or border crossings?

-- ddg

Unfortunately, no, it doesn't mean that. If your object needs to (for example) do something like notifying a server when its UUID changes you still need to do that on_teleport, because (according to a Linden) if you're teleporting to another sim the object can still get a new UUID just as if it was being re-rezzed.

They should continue to call on_rez in that case, even if they don't call it on intra-sim teleports.

Unfortuently residents cant perform outside comms, so havent been able to test that. The teleport part of the test was 10 teleports to non ajoining sim including mainland and islands, and after which the scripted object retained the same key

I do not particularly like particle poofs and I do not have anything relies on on_rez behaving as it does.

However - I am pretty sure that LL is going to change something arbitrarily that I do rely on that no one else (except for me) cares about in the future.

This is simply unacceptable behaviour from a platform designer.

Tools, such as options and deprecations, are at their disposal. If they feel something is vital to the integrity of SecondLife that they need to immediately fix it, then by all means communicate this requirement in the announcements / MOTD and make everyone aware that their code and items they have purchased is about to be broken.

Simply writing some quiet entry in a release note that does not get a lot of visibility is extremely shoddy behaviour on the part of LL's release process.

well i am now done making shure my script wud work after somting like this wud happen.
But i still hope they wud not change it on live versjon.
Cus i feel many that sell scripted object not gone repear them at first. and many that buy products from them gone get upset and stuff.

Its like sombody having a bet how many they can piss off by changing somting that do work.

I think if you follow the wiki and the functions intended usage you will be pretty safe, sometimes an lsl function gives some nice sideeffects which arent official but people know they happen, of you read the on_rez state description on the wiki you'll see

"Triggered in an object whenever it is rezzed from inventory or by another object."

The only mention of it working after teleports is in the user added comments.

I agree, Nathan. Using "undocumented" functionality has always been a risk that even RL developers must choose to either take or avoid.

I would have preferred a slightly longer deprecation period, but at least LL did give us a valid, legal alternative, rather than just stripping it out completely.

Do you honestly believe that LL will listen to anyone if they consider this to be a bug (and according to Linden posts elsewhere I believe they do)? As they proved with both the ResMod system and the removal of Joints - they'll already have decided what they're going to do about this, prior to letting any of us know, and regardless of how much people shout about it they'll follow their decision through.

Sorry and all that, but it's just not worth struggling against it

While I agree with you and lately it does seem that way, there have been times, especially with technical issues like this (as opposed to more sweeping social and financial changes) that they have listened to developer input and backed off of modified proposed changes. I don't think it is futile to raise genuine issues like this.

Linden Lab I think is in a difficult position at this point, as some of the stuff we have come to rely upon is contributing to the instability of the platform. Given the sheer number of attachments that many people wear, I can imagine that cutting down on on_rez firing for each of those attachments across the entire userbase every time someone teleports (an already resource intensive event) would definitely have a noticeable effect. Giving up backward compatability is sometimes a painful choice that has to be made for future progress.

I have been doing some testing, since the object doesn't rerez on teleport I thought maybe animations should persist after teleport, and this is "somewhat" the case. Here is the behavior I see:

I start an animation in one sim, I fly to the next sim and the animation keeps playing. That works as expected.

I start an animation in one sim, I teleport to another sim and the animation stops. Not what I expected. I teleport back to the original sim and the animation is playing again.

The animations stopping after teleport has been an issue that I have previously dealt with by resetting the variables or script on_rez() (detecting the teleport). All of the current scripts that do this will break in 1.9 in this regard, unless LL fixes it so that animations persist after teleport or leave the on_rez() event firing after a teleport.

LL please help!

Amethyst

Use the new changed function to detect a teleport

default
{
    changed(integer change)
    {
    if (change & CHANGED_TELEPORT)
        {
            //Insert function here
        }        
    }
}

I know how to detect the teleport now, but it breaks existing scripts!!!! My comments were ways to stop huge amounts of breakage.

It seems to me that they are intending teleporting to be basically the same as crossing a sim boundary, but this is not the case from testing. It is sometimes hard to tell what the people at LL are thinking but clearly they do not work the same. Whether this difference in behavior is a bug or by design the issues remain. I would like to know if this is considered a bug and will be fixed, or if they are making things difficult for a reason. I sincerely hope it is a bug and hope it will be fixed so existing scripts don't break horribly!

Instead of changing on_rez() why couldn't they have made something else that did what on_rez() was origionally supposed to do? That way they could maintain backwards compatability with the many 1000s of objects that make use of the "bug" and yet have something that works "right"?

That would be nice, or at least letting both the new event and the old work for a version to let people update their scripts and transition. Instead of doing everything at once causing mayhem.

Thank you LL!!

I just tested in the latest preview... the animation state is now preserved after a teleport! So most of my scripts will work without modification now. *hugs and kisses!*

Amethyst

Another alternative would be to announce very vocally that these changes are occuring.

If they need to take the dramatic course of breaking existing content, then they need to loudly and clearly inform the developer community that they are doing this.

What they are doing here is tip toeing around it .. I have yet to see any announcements regarding this issue.

It's all "ask for forgiveness and not permission" all the time, I guess.