Temp Rezzers circumventing prim limits

I have received a complaint from someone that one of my tenant's is using a temp rezzer and circumventing prim limits, the complaint is that this is hitting region performance. Performance in this sim seems ok to me, but I do see the problem, my parcel there does have more prims than should be physically possible.

My tenant sells buildings and they are rezzed via a temp rezzer so people can view them, there's nothing deliberately malicious about the way my tenant is using their temp rezzer (as in they aren't doing this to be gits) but how are they able to rez more prims than the parcel supports? I only have one parcel in this sim so the prim limits are hard set for this parcel.

I always thought that other prims would be returned when something like this happened rather than being allowed to rez extra prims and circumvent limits, I'm sure that this will be causing performance issues at some point.

Put a lag meter down and watch it.

These things have no noticeable impact on Sim performance. Especially one that doesn't auto-rerezz. The one you describe sounds like it is just rezzing objects when people ask it to - to demo a build for example.

That kind of rezzer is going to be particularly low on demand.

The complaint is coming from someone who is just following paranoia rather than actually monitoring what is causing sim lag. The 'bling shoes' of a single frankenbarbie entering the Sim will have a much worse effect.

Or maybe from the scripts needed to run the drooling, knuckle dragging, eye popping, wolf howling animations some guys use in reaction to Frankenbarbie entering said sim?

LOL

Although, on balance, I think it's more likely to be the blingy shoes.

I hate blingy shoes.

If they are using more prims than allowed, they have to be auto-rerezzing if someone wants enough time to look at the building (they have to be temp prims). A holo rezzer is okay to rez a building to look at, but it needs to be under the parcel limit and rezzing regular prims that are in turn killed so the next building can be rezzed.

Even the auto-re-rezzers are very low on lag if the script is one of the ones written in the last few years.

Set one down, and set a stack of meters near it. The meters will create more lag than the rezzer.

The best way to see this is to visit the shop '1-Prim things' - which is full of these, as that's what she sells - pre-built items stuffed into a rezzer.

I thought bling was client side like all other particles.

That will lag everyone's client around them. And some of the bling scripts are said to be pretty over the top complex if they're cycling in effects, gestures, spam, and so on...

The rezzers just tend to rez things, and do it staggered to reduce their 'impact'.

Er.. You sure about that?

If anything, I think rezzing has become even more expensive lately. If it's got scripts, it's worse. If it's got mono scripts, it's worse again...

I'm just concerned as to how people can rez more prims than is possible, surely this means someone else is gonna have trouble eventually?

/me points!

edit:

A parcel will never, EVER have more prims than it can contain - don't worry about that. The sim has a pool of 'extra' prims that it uses for vehicles, temp stuff, attachemnts and &c. If the sim wants to rez something and it can't find space for the prims, it will either delete/return some existing ones or deny creation of new ones. Be more concerned about the cost of re-rezzing something every minute, every day.

Sindy you're giving me a Maths Link on a Saturday night? Football + Beer means Ciaran's already cross eyed, and I haven't even got visiting Xstreet as an excuse!

Thanks I'll bookmark it and read it properly when my brain is working properly.

The SL scripting system has the concept of a "temporary prim". The accounting for these prims are handled differently from the regular accounting for prims permitted on a particular parcel. It's not a question of rezzing more priims that possible, it's a matter of rezzing more prims than permitted by the quota that's been allocated to you.

Temporary prims have legitimate uses, the most obvious being for things like bullets when used in a combat sim. They don't present much of a problem when used that way, although they might if the sim were very crowded with combatants.

In this case, it's common for people who sell complex objects such as houses to use temp rezzers so that people can see the homes before buying them. Otherwise it becomes cost-prohibitive for a builder to display all of the homes they've designed. This is also a legitimate use, and again, shouldn't present much of a problem. Typically a buyer will rez a home, look at it, then rez another, so it's a manual operation.

There have been situations where temp rezzers are used to effectively exceed the number of prims permitted on a parcel. To do this, they're constantly rerezzing the same items to give the appearance of permanency, at least while the parcel is in use. This usage has, in the past, raised both ethical questions about the appropriateness of this use and technical questions about the load on both the sim and the client. The debates have been heated, and there's no reason to repeat them. Suffice it to say that there are situations in which even this use won't create technical problems, but there are also situations in which LL will investigate and may remove such devices if it's found that they are creating problems.

Yep. Temp-rezzing a few dozen unscripted non-physical prims has never been expensive to the sim; rezzing a dozen scripts in even just one prim will send it into deep dilation for a frame or so.

On the other hand, lots of unscripted prims rezzing at the same time can really hit clients, especially those with slow network connections.

It used to be that temp on res prims came from the global sim limit, but that is not the case any more. Temp prims have their own allocation above and separate from the 15K sim limit. Plus, these temp prim allocations are now allocated by plot just like regular prims so he is using his allocation of temp prims and no more. You may need to let the complaining people know that the temp prims for the buildings do not impact over all sim prim limits. Also, since this is not a constant re-resing it will not have the impact on sim performance like the old style 30 second auto-ressers caused.

It really boils down to one group needing to be informed about the new temp prim allocations and to be assured this is appropriate usage for them. Diplomacy and education are all that is really needed here.

There is a buffer in sims for temp prims, avatars, and vehicles.

When?

Before Havok. Little over a year ago and then stretching back to beta. They were not supposed to count towards the 15K limit, but they did.

I seem to recall something like that also, but can't find my data on it. There was some mucking about with it, to be sure. The grey goo fence was adjusted at that time, too, more than once.

Ciaran, turn on region stats and look at time dilation, and also time (msec) at the bottom of sim stats; expand it out.

It really matters what's being temp rezzed. You might notice severe drops in time dilation every minute or so, roughly, when the rezzer is activated.

For instance, if it's just a .5m cube with a default texture being temp rezzed, it won't affect terribly much. But if it's a huge mansion with bucketloads of textures and scripts, or a highly detailed teapot with 50 large textures on it (amateur construction methods still being terribly common, sadly) ~ that's going to smack the region a bit. Every. Single. Time. It. Rezzes.

I usually see this trend:

Original Perpetrator: Oh, look, what a handy primsaver! It's just one, won't hurt...

Neighbour: He gets to do it, why not me too...

Original Perpetrator: I need more prims. Couple more temp rezzers, yes, there we go.

Both Together: What horrible lag! Time to yell at that land baron of mine, this is awful!

You can get a few poofers, which I think is temp rez??? Which you an turn the amount of stuff rezzed right down.

Poofers are particles.

We've used a holographic projector for a long time now that is basically a temp-rezzer which displays Daryth's products. It has always caused lots of lag every time it is used. Now, it rezzes anywhere from 100-700 prims at a time, and a few of them are scripted, so that's to be expected. Whenever we hold events in Cathedral, we turn off/hide the rezzer to minimize the lag.

Temp rezzers /can/ and often /do/ cause sim lag for everyone in the sim when they are rezzing. Unless the rezzed builds are very low-prim (think <50), and are unscripted, you will likely see some noticeable stuttering in the sim every time it rezzes an object.

Bling/poofers are particles and do not cause sim lag. They /may/ cause client lag, but it is pretty rare and, if it does, the user is 100% in control of that lag, as he can set the max particle count his client is displaying down, or turn particles off completely with a single keychord.

Not in 2005, they didn't. They were broken, for a period, later on... but that was a bug introduced by an attempt to fix the temp rezzer problems... but you could definitely have more than 15,000 prims in a sim in 2005 if some of them were temp rezzed.

I think you can put a big dent in sim performance with far fewer than 50 prims. The ones I looked at yesterday where Maelstorm lives were all 2-prim objects and the region was dipping down to 25-30 sim fps every time new ones got rezzed.

It wasn't the "rezzing mono scripts sucks" bug because there were a number of copies of the objects already in-world.

Bit of a tweak to that statement - I see a lot of effects that very frequently update the particle system. The stoopid things spew updates like there's no tomorrow.

Well-scripted bling does not cause sim lag. Enough poorly scripted bling & poofs around and it will drag the sim down a bit. Not as much as other things but it does happen.

Only the code is shared. Rezzing multiple copies of a mono object still require the data structures to be rebuilt from the linearized format. Unlike LSO where they're just copying a 16k chunk of code and data into RAM, for Mono every data structure has to be traversed and rebuilt. If you have many lists or the script was saved with an active event (say, due to llSleep()) this is time-consuming.