Killing script rezzed objects at world edge

A proposal has been floated to kill script rezzed objects that hit the edge of the world, go too far underground, go too high, parcel cleanup or would otherwise be returned to your lost and found folder.

The only downside I see is if you were using a script to rez a unique object and it went off the world, but that seems like a lot less of a problem than the current "return 8 billion bullets to my inventory" issue.

Comments?

Don't other request for LSL features take higher priority than this? The rest of us are "waiting" for scores of features, and could care less whether or not somebody who fires a gun gets an extra item in their lost and found, or not.

Isn't this what llSetStatus( STATUS_DIE_AT_EDGE, TRUE) is for?

It seems to follow that any who sets this flag doesn't want this item returned, and those who don't do want their things returned?

There are so many issues out there to be fixed, finished, completed, worked on in LSL....who cares if somebody has an extra bullet or 9 million added to somebody's inventory!

LL, focus!

The proposed fix for this bug should be the scripted bullet creator's responsibility, not SL's, I would rather see efforts towards the feature requests for things like archival data storage llWriteNotecard, Object based teleport requests, and llIntantMessage of non-player objects (this last one I've heard 1 rumor that it was possible, but this is untested). Along with Havok 2 and XML-RPC outbound.

Hee, someone beat me to the punch on my response, fair enough.

DITTO!



DITTO!

Stop worrying about "little" things like Returned Vs. Deleted or llSitTarget teleportation removal (which STILL has not been explained WHY the Lindens are trying to limit it. Theories from vocal SL residents have been put forth, but LL has not yet commented, AFAIK), and start working on features that have been asked for for months or even YEARS.

(That said, I'd like to take this opportunity to bring up a different 'Return Vs. Delete' topic I brought up a few months back, in that no person should have the right to delete another person's objects, and land-owners' only option should be to return other people's objects. I don't know if this was ever changed, but if it hasn't, THAT should be looked at. But only after LSL features are added in.)

List of features I've been waiting on for a while now:

Land stats. (Size, prim counts, flags, names, keys.)

Persistant IN WORLD data storage.

"RPC"-like calls that can be made from object to object in world without having to use an outside server. (Or reduced/no 20sec limitation on *.secondlife.com email addresses made with llEmail.)

I'm sure others have other such lists, and I hate to try to derail this thread from it's intended purpose, but honestly, how much time is spent on these minor details when bigger things have been asked for and are needed more?

And as an aside, I DID warn that saying RPC calls would be in a later build of 1.4 was like saying it wouldn't be in for another several build numbers, probably until 1.7. I was told I was right in that similar things had happened in the past, but that "this time would be different".

What if you don't want to put a script in the object?

I think that temporary-on-rez objects should have an implied STATUS_DIE_AT_EDGE, though.

Simple. Put the script in, then remove it. The status remains.

That said, anyone know if STATUS_DIE_AT_EDGE also affects object returns from plot timers? If it doesn't, we need another flag. (But does anyone really expect LL to add in LSL features for another year or two? *sigh*)

*insert re-itteration of STATUS_DIE_AT_EDGE*

no thx; i like the 4k ceiling. It wouldn't be cool to have objects returned that exceeded some lower limit. There is little point in allowing people to go beyond the ceiling which objects are allowed to exist. (the object ceiling is 4k; the edit-tools ceiling is 768; rez ceiling is 4k). (just because no ones built a castle in the sky at 3k doesn't mean you can't; i just haven't had time)

so...
could you please, please work on the functions we ask for

You ask a question and then IGNORE our response? BLATENTLY ignore it?! What the HELL is the point of asking whether or not dying at the edge of a world is a good idea when you're going to IGNORE the responses you get and go ahead with it anyway?

If I don't want to know whether or not my objects are fouling up somehow, I'll code in the DIE_AT_EDGE thingy. Otherwise, I WANT to know when they're crossing into the void.

(However, I do notice the distinct lack of llSitTarget changes... at least in the release notes. I commend you for listening to us on THAT at least.)

soooo can we have a set status flag for STATUS_DONT_FREAKING_DIE_AT_EDGE_DANGIT?

You are correct that LSL has several features to support the creation of objects that aren't returned when they die (DIE_AT_EDGE and Temporary on Rez) however the problem is that the vast majority of people who build guns don't use them. Machine guns that fire bullets off the edge of the world, or on to full parcels, cause a lot of extra load on the system -- both due to the derez vice delete and the subsequent larger inventory downloads -- which impacts everyone, not just the individual who now has a huge inventory.

As for prioritization, 1.5 was designed to primarily be a bug fix release, so we didn't take on as many big, new features as we normally do. This included LSL, where we tried to hammer down the bug list as much as possible, while still adding some new features.

Then why ask the question?

So you're saying that before 1.5 goes live, you're going to have a STATUS_RETURN_AT_EDGE? Because it's a bug that it's missing.

BTW, can we have a STATUS_RETURN sort of thing or a STATUS_DIE sort of thing for the auto-return-timer? Or does DIE/RETURN_AT_EDGE do that?

It just occured to me - on Krittania, there are some public-use jetskis that are script rezzed.

What is the behaviour of a script-rezzed vehicle that hits a world-edge with this new feature? Will you still bounce off the edge of the world as per usual?

Is there a way to declare explicitly that you don't want to die on edge? Say,

on_rez( integer code ) {
   llSetStatus( DIE_AT_EDGE, FALSE );
}

Added a "STATUS_RETURN_AT_EDGE" (deemed easier to type than "STATUS_DONT_FREAKING_DIE_AT_EDGE_DANGIT" that trumps STATUS_DIE_AT_EDGE if it is set. Also, to echo something I posted elsewhere, if you are sitting on the script rezzed object, it will bounce at the edge of the world normally.

Also, to clarify slightly, this change only applies to edge of the world derezes or too high (> 4km) or too low (< -100m or 2 times your max dimension below ground level). After asking around, the risk of killing off script rezzed building sections seemed too high to have this apply to parcel derezzes.

Yaaaaaay!



Ok. What about a status flag that kills an object rather than returns it when hit with the timer? Something that has to be set with llSetStatus?

Why not just do an implicit llSetStatus(STATUS_DIE_AT_EDGE, TRUE) for script rez'ed objects. This means that if anyone is script-rez'ing objects that they specifically do not want to die at edge, they have to turn this status off, and that's all. Problem solved, nothing existing breaks, everyone is happy, everyone showers Wednesday with rose petals and candy!

Ehe, okay, I have to go with the thread after talking with people about it, (the mentioning of Watermellon guns made this decision possible) the 1.5 addition of this feature was actually good now that I've seen an example where it is useful, I've also been informed that it can be turned off for my self rezzing projects, so there's no concern there.

I'm satisfied.

How about RETURN objects that are no-copy, and DELETE objects that aren't.

Allow the DIE_AT_EDGE to override the base settings. Perhaps add a RETURN_AT_EDGE to do the same.

Edit: Okay, you HAVE added RETURN_AT_EDGE. But I still think the default behavior should be based on the copy/no-copy flag.

That wouldn't make sense, because that would still require a 'change' to be made to make an object die automatically, which is what the whole point was.

See, in order to make an object die under the 'copy flag' thing, you'd have to turn on the copy flag. That doesn't exactly scream "Turning this on will make objects die when they go over the edge" so someone might get confused. It also is just as unlikely to happen as a gun maker putting such a thing on bullets.

1000 bullets being returned == lag.

1000 bullets being deleted == not as much lag.

The idea was to make objects die by default.

Bullets, by their very nature, would be copy-ok, since many need to be created from one inventory item. They would just die.

A car that gets away from it's driver that is set no-copy, is returned.

A car that that is set copy-ok is deleted, since when the owner rezed it, by default it still remains in the inventorty.

Anything that is still owned by the creator has, for certain, full copy rights. So anything still owned by the creator will be deleted. UNLESS the STATUS_RETURN_AT_EDGE flag is set.

If someone made a gun that used limited ammo, so that more had to be bought to continue using the gun, the bullets would be no-copy and therefore would be returned. UNLESS the STATUS_DIE_AT_EDGE flag is set.


I think that this default behavior covers almost all cases naturally, without the use of the status flags. But for those cases that need it, the two flags cover the remainder.

The basis for this idea is that, if something purchased is no-copy, then the owner will want it back. Whereas if it was copy-ok, they most likely have it still in their inventory, so deleting it is preferable.