Temp Rezzers, ok or bad?

[Jo Yardley]

I haven't seen a temp rezzer in SL for ages, last thing I heard they were very laggy and thus people stopped using them a lot.

I'd like to hear the most recent ideas on these things.

Are they laggy or is there now a no laggy type?

Either way, when used rent meters go ballistic so I reckon we'll have to ban the use in our sim anyway because when I get a message that one of our tenants is 300 prims over limit, I get an heartattack fearing the sim is about to crash ;)

[Marcus Hancroft]

Temp rezzers are a horrible, lag causing mess.  Not long ago, I had a neighbor who found it necessary to put his house in a temp rezzer.  It would disappear for a split second every minute or so and every time it re-rezzed, all activity on the sim stopped.  Just walking across my parcel was a nightmare.

Once, I saw that he was inworld and on his parcel, so I cammed in on him.  He went into his house while it was rezzed, me still cam locked on him.  Of course you know what happened next...his house disappeared and he fell to the sand below.  It then reappeared and there he was...stuck under the floor!  I just about laughed myself into an aneurysm!  Shortly after that, he took away the temp rezzers.

In MY opinion, they need to be banned.

[Knowl Paine]

I owned some land adjacent to a temp rezzing 250 prim Boat. Not exactly sure why the owner set it that way. Every 15 minutes a new boat would appear, after I cached the the boat 1 x, I barely noticed it.

I do not support the use of temp rezzers on shared Mainland Regions, Rental land without consent of the Region owner, Protected Linden Land.

(Private Region Owners are private)

I can see and touch the object, it is there, using resources that would otherwise be Unavailable were it not for a device.

 

[April Looming]

Temp Rezzers = bad.  I used one for a while for bits of my sky box, and if it's not set to create another copy of the item before the last copy times out, then you get a second where there's nothing.  Or maybe the server takes too long to rez the new copy even with an overlap because it's too overloaded.

I think people can AR (create an Abuse Report) on an object on Mainland that is hogging an unfair share of resources.  So if you don't mind having LL come and take your Temp Rezzer, and you don't mind your stuff disappearing every x minutes, then go right ahead!  :matte-motes-wink:

[Amethyst Jetaime]

A big thumbs down to temp rezzers.  They are only a way to cheat the prim count system at the cost of server resources.  The server resources needed to render an object are still used, and used, and used, and used, and used....... over and over again thus creating more lag than just rendering the object once when first rezzed.

Note that holovendors that are not temp rezzers (i.e. rending an object over and over) may be OK, depending on how efficient the scripting is.  These types of vendors display the object and then delete the object after a certain period of time or upon another selection being made, without re-rendering it.

 

[Pussycat Catnap]

Modern temp rezzers are almost completely lag free.

The only issues will arise if someone puts a scripted object inside of one.

Most of the paranoia comes either from that, or from notions of what they were 4 or more years ago.

 

 

[Jenni Darkwatch]

I _think_ it also depends on how primmy the object they rez is... As far as holovendors go... if they rez something new every minute they're not any better than temp rezzers, regardless whether the rezzed item is temp or not. Ideally they shouldn't rez anything unless a customer clicks on a "rez" button.

[Qie Niangao]

If tenants are allowed to use temp-rezzers, they'll almost certainly put scripted stuff in the rezzers, and that will cause lag.

Even if the items are not scripted, the more agents in view of the object being temp-rezzed, the more lag it causes.  (Waves of expensive object-update messages to all those viewers.)   That's a recipe for disaster:  the busier the sim, the laggier it is already, and temp-rezzing adds lag proportional to the lag that's already there.  Very destabilizing.

On the other hand, all alone in a skybox, one can temp-rez a ton of unscripted stuff and convince oneself that all will be well. It won't.

[Phil Deakins]

I'm going to swim against the tide here

When people were down on temp rezzers, a few years ago, the main argument was that the prims that they rezzed were deducted from the sim's 15,000 and, therefore, it was taking prims away from other land owners in the sim, which was true at the time. But that changed so that temp prims are over and above the sim's 15,000, so that particular argument died.

The other main reason to be against them is lag, as everyone has pointed out so far. But I disagree that, because of lag, temp rezzers are bad. To my way of thinking, it depends on what they rez and what the local circumstances are. Everything causes lag, of course, so causing lag isn't an issue. In fact, lag isn't the issue at all. The issue is the degree of lag that temp rezzers can cause if used badly. Imo, temp rezzers can be used without causing any problems, and they can also be used in ways that do cause problems. So, imo, like guns, temp rezzers aren't intrinsically bad, although some uses of them are bad.

[Phil Deakins]

---

Pussycat Catnap wrote:

Modern temp rezzers are almost completely lag free.

---

I don't know how a temp rezzer can be made that is "almost completely lag free". They re-rez objects at approximately one minute intervals, and the sim server deletes those objects at approximately one minute intervals. Everything connected with those operations has to happen, and "modern" temp rezzers can't avoid it. They could stagger the rezzing of objects, so that everything doesn't happen at the same time, but everything still has to happen. I suppose that staggering is bound to be better though.

[PeterCanessa Oh]

---

Amethyst Jetaime wrote:

A big thumbs down to temp rezzers.  They are only a way to cheat the prim count system at the cost of server resources.  The server resources needed to render an object are still used, and used, and used, and used, and used....... over and over again thus creating more lag than just rendering the object once when first rezzed.

Note that holovendors that are not temp rezzers (i.e. rending an object over and over) may be OK, depending on how efficient the scripting is.  These types of vendors display the object and then delete the object after a certain period of time or upon another selection being made, without re-rendering it.

 

---

This.  And Jenni's, Qie's and Phil's (contrary) comments.

The difference between temp- and holo- rezzers is important.  Things set TEMP_ON_REZ are automatically deleted within 1 minute so the re-rez time has to be that or shorter, holo-rezzers are 'more efficient', or at least less laggy, in that they don't re-rezz things all the time.

However, as Phil said, temp-rezzers are a tool that does have a use.  Kept to small, low-prim, preferably unscripted items they are fine.

NB: Anything staying in-world 15 minutes or making prim-count jump 300 is not TEMP, so it isn't a temp-rezzer generating it.

[Qie Niangao]

---

Phil Deakins wrote:

---

Pussycat Catnap wrote:

Modern temp rezzers are almost completely lag free.

---

I don't know how a temp rezzer can be made that is "almost completely lag free". They re-rez objects at approximately one minute intervals, and the sim server deletes those objects at approximately one minute intervals. Everything connected with those operations has to happen, and "modern" temp rezzers can't avoid it. They could stagger the rezzing of objects, so that everything doesn't happen at the same time, but everything still has to happen. I suppose that staggering is bound to be better though.

---

Yeah, I also don't get how older ones could ever have done anything worse than "modern temp rezzers" do.   Grasping at straws, a couple of possibilities: For a year or so, rezzing (and to a lesser extent,  de-rezzing) Mono-scripted objects had a huge performance impact on the sim, and that's fixed now, but it's nothing to do with improvements in the rezzers themselves.

The other thing is that long, long ago, temp-rezzers in certain applications must have included a script in every rezzed object, so those objects could be killed on command (as in a holovendor).  This was before the time of llRemoteLoadScriptPin(), which has been around as long as I can remember, but was a new function at some point. Anyway, even before Mono, rezzing objects containing scripts was laggy, so having to put a script in each rezzed object would have earned such temp-rezzers a very bad reputation, indeed.  But even back then, not every temp-rezzer would have needed that functionality.

[Phil Deakins]

---

Qie Niangao wrote:

---

Phil Deakins wrote:

---

Pussycat Catnap wrote:

Modern temp rezzers are almost completely lag free.

---

I don't know how a temp rezzer can be made that is "almost completely lag free". They re-rez objects at approximately one minute intervals, and the sim server deletes those objects at approximately one minute intervals. Everything connected with those operations has to happen, and "modern" temp rezzers can't avoid it. They could stagger the rezzing of objects, so that everything doesn't happen at the same time, but everything still has to happen. I suppose that staggering is bound to be better though.

---

Yeah, I also don't get how older ones could ever have done anything worse than "modern temp rezzers" do.   Grasping at straws, a couple of possibilities: For a year or so, rezzing (and to a lesser extent,  de-rezzing)

Mono-scripted objects had a huge performance impact on the sim, and that's fixed now

, but it's nothing to do with improvements in the rezzers themselves.

The other thing is that long, long ago, temp-rezzers in certain applications must have included a script in every rezzed object, so those objects could be killed on command (as in a holovendor).  This was before the time of llRemoteLoadScriptPin(), which has been around as long as I can remember, but was a new function at some point. Anyway, even before Mono, rezzing objects containing scripts was laggy, so having to put a script in each rezzed object would have earned such temp-rezzers a very bad reputation, indeed.  But even back then, not every temp-rezzer would have needed that functionality.

---

They fixed the thrashing with Mono scripts? Mono is safe to use now? (I'm out of touch with such things)

 

I made and sold a temp rezzer years ago - temp rezzers were one of my two specialities in forum arguments - the other was bots, of course.  Each temp object did have a script in it that did two things. It killed the object on command (from a Stop button in the rezzer's menu), as you said, and it sent the object's position and rotation to the rezzer. But surely, using llRemoteLoadScriptPin() to create a copy in the rezzed object, and then running the script, would amount to same server workload as rezzing the object with the script already in it, wouldn't it? Plus it would have extra workload for the copying of the script.

I like the idea of staggering the objects

[Phil Deakins]

---

PeterCanessa Oh wrote:

NB: Anything staying in-world 15 minutes or making prim-count jump 300 is not TEMP, so it isn't a temp-rezzer generating it.

---

Temp rezzers do make the prim count jump like that - briefly. It's because the next copy is rezzed before the current copy is auto-deleted, so, once a minute, there are two copies rezzed for a few seconds each minute, and the total number of prims rezzed will jump up like that for a few seconds each minute.

[Wildcat Furse]

using temp rezzers = harassment = permaban *meows*

PS. including the ones that created them ...... :matte-motes-inlove:

[Phil Deakins]

---

Wildcat Furse wrote:

using temp rezzers = harassment = permaban *meows*

PS. including the ones that created them ...... :matte-motes-inlove:

---

Either that's totally untrue, or LL made a rule along the way that I'm not aware of. Which is it?

If they made a rule against temp rezzers, I'm sure that plenty of those who already posted in the thread would have known about it and said so. Also, judging by the search results, there is no such rule.

[Qie Niangao]

---

Phil Deakins wrote:

 But surely, using llRemoteLoadScriptPin() to create a copy in the rezzed object, and then running the script, would amount to same server workload as rezzing the object with the script already in it, wouldn't it? Plus it would have extra workload for the copying of the script.

---

Sure, but it's still a big win if the temp-rezzer will be re-rezzing the same thing hundreds of times before anybody ever presses the Stop button.

And yes, the sim-stall-on-Mono-rezzing bug has been fixed for a few months now.  Mono still presents somewhat more overhead than LSL-compiled scripts when being instantiated on a sim, but it's nothing like the problem when that bug was present.

[Phil Deakins]

---

Qie Niangao wrote:

Sure, but it's still a big win if the temp-rezzer will be re-rezzing the same thing hundreds of times before anybody ever presses the Stop button.

---

How come it's still a big win? I don't disbelieve you, Qie, but I can't see how it can even be a win, let alone a big win, for temp objects that are rezzed every minute.

[Pussycat Catnap]

---

Phil Deakins wrote:

They could stagger the rezzing of objects, so that everything doesn't happen at the same time, but everything still has to happen. I suppose that staggering is bound to be better though.

---

The staggerring is something they do do now.

If a person actually tests one of these things rather than regugitate the anti-hype on them, they can see their impact is non-noticeable when properly used.

 

[Qie Niangao]

Well, because they're rezzed every minute, and the sim automatically sweeps them up after a minute, requiring no script. Suppose that's the normal mode of operation: the same objects getting rezzed and automatically expiring, for hours at a time.  Then somebody tells the rezzer to make them go away, and the rezzer stops rezzing and copies the script into the instance already rezzed.*  That's just one script instantiation for the sim, compared to hundreds -- that's the win.

I'll grant that there's some additional overhead to copying the script into the rezzed object, above the usual cost of rezzing the object with a script inside, but that's negligible if it makes it possible for that to be a rare event.

 

*EDIT: The script can be a one-liner, too: just llDie().  It doesn't have to listen or wait on any other event telling it to die.

[PeterCanessa Oh]

---

Phil Deakins wrote:

---

PeterCanessa Oh wrote:

NB: Anything staying in-world 15 minutes or making prim-count jump 300 is not TEMP, so it isn't a temp-rezzer generating it.

---

Temp rezzers do make the prim count jump like that - briefly....

---

Sorry, I'm conflating things - as TEMP prims are not allocated from the sim's allowance anything that males available prims drop is not TEMP.

@All - Regardless of whether they are inherently good or bad is there anything temp-rezzers are useful for apart from things like bullets, for which the functionality was designed? [Edited: I'm typing very badly today.  Apologies]

[Phil Deakins]

I'm with you now. The script only gets copied to the object if and when it's needed, and not if it isn't.

Such a script isn't essential, as the rezzer can stop rezzing and leave the sim to sweep up. It's not as clean as an llDie() though but it's not essential.

My rezzer needed a script in each rezzed object at all times though, and I guess that other rezzers do too. The reason is so that the owner can adjust the position and rotation of the object at any time, in which case the script reports the new data back to the rezzer. But if the Stop command simply stops rezzing and leaves the sim to clean up in due course, at least it's not essential for those scripts be listening.

[Phil Deakins]

---

Pussycat Catnap wrote:

The staggerring is something they do do now.

---

As I said in a later post to the one you replied to, I like the idea of staggering. It's something that only occured to me as a result of your post, and never at the time I made and sold the temp rezzer.

It doesn't reduce the lag though. It can't do that. It spreads it so that there isn't the spike that there used to be.

[Qie Niangao]

Useful?  Well, only if you're desperately strapped for real prims.

I used to temp-rez fussy, primmy, decorative stuff.  I even had this elaborate script that watched where folks were and started rezzing only those decorations that were near avatars.  Worked like a charm, too -- until I noticed what happened when there were a lot of people viewing the same temp-rezzed stuff.  Making all the stuff phantom helped some, but ultimately ripping out the temp-rezzers easily doubled the avatar capacity.

[Phil Deakins]

---

PeterCanessa Oh wrote:

---

Phil Deakins wrote:

---

PeterCanessa Oh wrote:

NB: Anything staying in-world 15 minutes or making prim-count jump 300 is not TEMP, so it isn't a temp-rezzer generating it.

---

Temp rezzers do make the prim count jump like that - briefly....

---

Sorry, I'm conflating things - as TEMP prims are not allocated from the sim's allowance anything that males

available

 prims drop is not TEMP.

---

Unless LL changed it while I wasn't looking, temp prims do show in the About Land box, if that's what you mean. I don't remember the exact details but I do remember that they show against a person's prims in the About Land box. I think that's what was being referred to earlier in thread - about the temp house - and I think that's what you were replying to. If my vague memory is correct, they aren't added to the parcel's totals though. But they do (or did) make a person's total go up and down.