Second Life Forums Archive - Teleport and on_rez

Iron Perth

Registered User

Join date: 9 Mar 2005

Posts: 802

02-19-2006 21:22

Hey Phoenix, thanks for talking to the community about this, it is very much appreciated.

I think the definition of what things should do in 1.9 is what they do in 1.8 unless it's a reported bug against 1.8.

I know how this sounds, but I can't really think of any scenarios where behaviour should change unless it's currently breaking something or causing significant pain.

Keep up the great work!

Ben Bacon

Registered User

Join date: 14 Jul 2005

Posts: 809

02-20-2006 03:41

From: Zepp Zaftig

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.

Agreed.

LL should indeed try to keep official, LL-intentional behaviour unbroken - but we as developers should also accept the risk that if we use "undocumented behaviour" (included in that is behaviour document by us, rather than LL

) it may well break in the future. Anyone out there still using "if (1) state XXX;" in functions - beware Mono!

on_rez and key changes on teleport currently make sense - but only as an implementation side-effect. It just so happens that at the moment TP is implemented similar to a derez/rez cycle, but as sim2sim comms is improved (as LL have already started doing) it should become more and more similar to a sim crossing than a re-rez. At that point it would not make sense to fire on_rez and receive a new key.

Phoenix - as Iron said, thanks vm for asking us

My vote is to introduce teleport events ASAP, but to also continue with the current behaviour for at least a few more point releases to give us a chance to adapt. At some point in the future (IMO) - kill the old ways, and we'll take the knock.

Argent Stonecutter

Emergency Mustelid

Join date: 20 Sep 2005

Posts: 20,263

02-20-2006 05:01

From: Val Fardel

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...

There is code posted in this thread for distinguishing between them.

Ordinal Malaprop

really very ordinary

Join date: 9 Sep 2005

Posts: 4,607

02-20-2006 06:07

From: Val Fardel

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've been noticing this recently and it's an absolute pain in the behind. I'm trying to make wearable objects pair and unpair with HUDs automatically and half the time they don't, let alone all of the times when you detach a gun and are left standing there holding an imaginary one.

Mack Echegaray

Registered Snoozer

Join date: 15 Dec 2005

Posts: 145

02-21-2006 07:35

The way I'd handle this is to introduce an on_initial_rez() or on_rez2() event that does what it should conceptually do, and keep the old behaviour for on_rez. Make sure it's well documented and that's that bug marked "RESOLVED FIXED"

I don't think it'd be a good idea to break scripts, ever. There's no reason to do so beyond a sense of aesthetics and it has a tangile economic cost.

Platforms evolve and get warts as time goes by, that's just unavoidable.

Alternatively, do what we did for autopackage and have scripts declare what version of the language they wish to target, for instance at the top:

#target 1.0

If the target tag is missing assume it's 1.0. The old (wrong) behaviour is retained for such scripts, and people can opt into new behaviours as time goes by by adding #target 2 etc at the top.

So there are a bunch of ways to manage versioning, no need to break anything ...

Iron Perth

Registered User

Join date: 9 Mar 2005

Posts: 802

02-21-2006 10:51

From: Ben Bacon

Phoenix - as Iron said, thanks vm for asking us

My vote is to introduce teleport events ASAP, but to also continue with the current behaviour for at least a few more point releases to give us a chance to adapt. At some point in the future (IMO) - kill the old ways, and we'll take the knock.

Yes, in the few rare instances it seems vitally necessary to change behaviour, a deprecation migration path is the way to go as Ben describes..

Teleport and on_rez
Iron Perth Registered User Join date: 9 Mar 2005 Posts: 802	02-19-2006 21:22 Hey Phoenix, thanks for talking to the community about this, it is very much appreciated. I think the definition of what things should do in 1.9 is what they do in 1.8 unless it's a reported bug against 1.8. I know how this sounds, but I can't really think of any scenarios where behaviour should change unless it's currently breaking something or causing significant pain. Keep up the great work!
Ben Bacon Registered User Join date: 14 Jul 2005 Posts: 809	02-20-2006 03:41 From: Zepp Zaftig 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. Agreed. LL should indeed try to keep official, LL-intentional behaviour unbroken - but we as developers should also accept the risk that if we use "undocumented behaviour" (included in that is behaviour document by us, rather than LL ) it may well break in the future. Anyone out there still using "if (1) state XXX;" in functions - beware Mono! on_rez and key changes on teleport currently make sense - but only as an implementation side-effect. It just so happens that at the moment TP is implemented similar to a derez/rez cycle, but as sim2sim comms is improved (as LL have already started doing) it should become more and more similar to a sim crossing than a re-rez. At that point it would not make sense to fire on_rez and receive a new key. Phoenix - as Iron said, thanks vm for asking us My vote is to introduce teleport events ASAP, but to also continue with the current behaviour for at least a few more point releases to give us a chance to adapt. At some point in the future (IMO) - kill the old ways, and we'll take the knock.
Argent Stonecutter Emergency Mustelid Join date: 20 Sep 2005 Posts: 20,263	02-20-2006 05:01 From: Val Fardel 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... There is code posted in this thread for distinguishing between them.
Ordinal Malaprop really very ordinary Join date: 9 Sep 2005 Posts: 4,607	02-20-2006 06:07 From: Val Fardel 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've been noticing this recently and it's an absolute pain in the behind. I'm trying to make wearable objects pair and unpair with HUDs automatically and half the time they don't, let alone all of the times when you detach a gun and are left standing there holding an imaginary one.
Mack Echegaray Registered Snoozer Join date: 15 Dec 2005 Posts: 145	02-21-2006 07:35 The way I'd handle this is to introduce an on_initial_rez() or on_rez2() event that does what it should conceptually do, and keep the old behaviour for on_rez. Make sure it's well documented and that's that bug marked "RESOLVED FIXED" I don't think it'd be a good idea to break scripts, ever. There's no reason to do so beyond a sense of aesthetics and it has a tangile economic cost. Platforms evolve and get warts as time goes by, that's just unavoidable. Alternatively, do what we did for autopackage and have scripts declare what version of the language they wish to target, for instance at the top: #target 1.0 If the target tag is missing assume it's 1.0. The old (wrong) behaviour is retained for such scripts, and people can opt into new behaviours as time goes by by adding #target 2 etc at the top. So there are a bunch of ways to manage versioning, no need to break anything ...
Iron Perth Registered User Join date: 9 Mar 2005 Posts: 802	02-21-2006 10:51 From: Ben Bacon Phoenix - as Iron said, thanks vm for asking us My vote is to introduce teleport events ASAP, but to also continue with the current behaviour for at least a few more point releases to give us a chance to adapt. At some point in the future (IMO) - kill the old ways, and we'll take the knock. Yes, in the few rare instances it seems vitally necessary to change behaviour, a deprecation migration path is the way to go as Ben describes..

Welcome to the Second Life Forums Archive

Teleport and on_rez