Temporary on Rez lifespan

As Andrew Linden mentions in this SL Answers thread, there have been some changes to the way the temporary-on-rez object property works. There's long been some misconceptions and flat-out incorrect information about this on the LSL wiki, so it's good to get some of this straightened out as we move to a new formula.

One thing that wasn't mentioned, however, was the time element involved in the cleanup cycle. Previously, it's been any one of several fixed periods, possibly a sim-wide sweep on a regular timer, and lately, a variable lifespan ranging up to two minutes.

Most recently, I observed temporary prims lasting for a consistent 58 seconds each in several sims. Is this behavior we can expect, or was this coincidental? If so, is it like the number of temporary prims we're allowed, and relative to the parcel capacity?

I think it was a coincidence. There is a range of holovendors on the roof at ONE. They rez temp_on_rez models and autoadvance after a minute because of the about 90s rule...

Certainly the last time I was there looking (Monday) there wasn't a blank spot on any of the 8 vendors in any of the visible vendors. Now it's possible the timers weren't that good and rather than 60s they were all running fast, but it seems unlikely. If anyone wants to experiment it's a nice place from that point of view, lots of data to be collected quickly!

Yes, the old system was a sliding scan, one parcel a second until done and the scan started one minute after the last scan. The minimum lifetime of a temp object was supposed to 60 seconds, so with phasing of the scan the typical lifespan was actually about two minutes.

The current system is a per-frame (1/45th of a second) tally correction for any parcel that has gained or lost objects. If the parcel is over its temp limit then it aggresively deletes older temp objects until it is within its limit. Otherwise, if it has any temp objects at all that parcel is scanned for old ( > 60 seconds) temp objects every 10 seconds.

Which is why I'm suprised that you would measure 58 seconds for the typical lifespan. I would expect it to range between 60 and 70 seconds.

While on the subject of temp_on_rezz items ^^; previously, if avatar was attached to temp on rezz object it'd delay destruction of that object until avatar stood up. It was a very handy behaviour, as it allowed to create vehicles that'd auto-clean themselves if split into pieces thanks to physics glitches, sim crossing etc.

Currently the temp_on_rezz objects are deleted no matter what, literally disappearing from under avatar's behind if sat upon... is that intended change (can't really see reason for it as prims attached to avatar don't count vs parcel limit anyway) ... or a bug that will hopefully get fixed? ^^;;

So whats our guaranteed minimum lifetime now? It sounds like things should last at least 60 seconds, which is fairly ideal for all scripting uses I can think of.

I'm planning on making some more adjustments to the temporary objects system.

The first change would be done in the hope of recovering some of the lost functionality of Starax's wand for most situations.To that end, I'll probably change the temp limit formula. Currently the formula is:

temp_limit = 0.5 * prim_limit + 20, or 500 whichever is smaller

My plan is to change it to:

temp_limit = (prim_limit - prim_count) + 0.5 * prim_count + 128

No, that 'prim_count' factor in the second term is not a typo. The second term expands from 0 when the parcel is empty, to (0.5 * prim_limit) when it is full.

This change would enable the larger pieces of Starax's wand in all but the smallest parcels, or smallish parcels (~512 m^2) that are already full.

Hrm... it occurs to me I might be able to add a fourth term that looks something like max((256 - global_temp_count), 0) which would allow people with very small parcels to tap into more temp prims if no one else is using temp objects at that time. Since I'm not currently counting the global temp prim count it isn't clear to me how expensive (in CPU cycles) that fourth term would be.


Another change I'll probably make to the temp object system is to allow amnesty to objects being used as vehicles or seats, which would really be a change back to the way things were.

How about not killing temp on rez objects while they are being worked on?

That is, if I'm working on something and set it to temp on rez before taking it into inventory I don't want it to immediately vanish. If there was a guaranteed 60 sec delay that would be OK, or if it wouldn't die if it was being edited, etc.

Nope, you're right, it was actually 60 seconds per prim, and I just didn't take into account script delay. What can I say? It was a very late night.

Anyway, thanks for your help, Andrew. This was very enlightening.

Thanks Andrew!

That new formula is much more reasonable.

Looks like the magic formula!

Thank you!

I wonder if it'd be possible to get a temp_on_rez checkbox added to the object properties panel accessed by right-clicking an inventory object? This would allow an object to be set to temp_on_rez either way... after it's already in-world, or before it's dragged out of inventory.

Maybe the same property could be set to objects already inside another object's contents... without having to delete from contents, set to temp, take to inventory, then add back into the parent's contents.

Howdy, well I don't know all the formulas and the times.... the one thing I do know is that I have teleport units that us a temp rez beam to click on and 90% of the time it does stay rezzed long enough or doesn't rezz at all.... pretty much kills me using my teleport units to get around my place (tiring clicking 10+ times to get a stable beam to use), among other things that just don't seem to work right. And what effect is a laggy sim have on temp rezz items??? If I understand right... sounds like the timer starts before the object even appears.... and if the sim is lagg'in bad... then you might not even see the object???

Would be nice to see it working like it use to....

wow good to be a starax and have the system conform to you!
-LW

You know what would be useful? Some way to detect prim limits by script. My tram system is now ultra-sensitive to passing through parcels which are near their prim limits, and is returned to me quite a bit - also, the re-rezzer object which rezzes a new tram if the old one was lost occasionally runs out of prims too and starts spamming me.

If I could detect whether there were sufficient prims somewhere, I could have the tram avoid or skip over areas which were short of prims, and stop the rezzer from continually trying to rez things when it can't.

Ha! Oh how I wish!

I'm pretty sure that Andrew is considering the owners of an expensive item, rather than the creator.

I know it sonds personal, but "Starax's wand" is the name of the product. If it had been called "That Dork's wand", then Andrew would gladly have used that name instead.

Whilst it would be nice to be Starax (how I wish I could sculpt like that) and/or have the system conform to my wishes (like focus working properly and not having been borked and so on)...

This is more a case of a (not unreasonable) change to the code suddenly breaking a well established product. Actually, it also breaks a number of vehicles that run on routes as well in a slightly different but related tweak.

While LL aren't always good at it, their QA department does say "no breaking existing content" and they do tend to be good at (eventually) sorting out something that lets the existing content continue to work as it used to. Not perfect, but good. Andrew is one of the best at inadvertently breaking stuff, explaining why, being understood and appreciated AND sorting it out to a reasonable compromise that has everyone (except the griefers) happy enough with the situation to move forward.

Would be very handy... in the meantime, you could perhaps use something like libsecondlife to have permanent 'driver' AV attached to the tram, so it doesn't count vs parcel items? o.O;

or heck, maybe it could be turned into some sort of first even Caledon public job wor some freshly started people ^^; dance pad tram, so to speak ^^;;

wow very creative Joannah "dance pad tram" make it usefull in more than one way
i like that
-LW