Grey Goo Fence

Thanks Andrew

As I understand it, the grey goo fence is supposed to be a tool to drastically slow down grid attacks enough so that they can be taken care of manually.

To this end, I think that as long as the owner is in the sim where rezzing/self-replication is in place, there's no need for any sort of limitation. This can't be part of a grid-wide attack. So by definition of an attachment, the owner must already be in the same sim, so there's no need for limitation.

Another type of content that can be negatively affected by the grey goo fence are autorez buildings/games. You could imagine that someone has made some sort of scripted game that does interesting things for people who visit. In that case you can easily imagine that the owner of the game is also the owner of the land (or a member of the group that owns the land). So it makes sense to unlimit rezzing/self-replication in that case - again, you can have unrestricted content, but not the ability to carry out a sudden grid-wide attack.

Myself, I can't think of a case where you really need vast rezzing/replication ability where the owner is not in the sim, and they don't have land rights.

So that would be my suggestion - unlimit the land owner/avatar in sim cases, and then have a much more conservative grey goo fence for other cases. I can't personally see the need for something that needs more than 10 rezzes/second that doesn't fall into one of these two cases.

I think that attachments should be given free rein. Consider a grid attack that starts with a person wearing something that spews out the first generation of objects as fast as it can go. I'm not sure how fast one can realistically rez stuff with a lot of slave scripts and such, but they'd be able to go pretty fast, anyway. Then those objects would receive the inventory which allows them to start their own level of replication. If I understand you right, they'll all be part of the same family_id, so pretty soon, their combined efforts will result in them all collectively hitting the fence, and the replication will freeze up.

Instead, say you go ahead and limit the attachment from rezzing just like you do any other object. The attachment itself will hit the grey goo limit, and fail to rez/give inventory during the deployment of the first generation. In either case, the fence gets hit pretty quickly. The difference is that if we drop the fence entirely for an attachment, someone can conceivably fill a sim... pretty slowly. Probably, what, 40-50 objects per second? And those objects won't be able to do much damage, aside from, say, running for the sim border at top speed and trying to replicate there with a fresh fence... but that can happen even with the current fence.

Basically, it looks like dropping the fence for attachments would allow rezzing at a rate that's a constant multiple of what would be allowed if the fence was in place (assuming careful tuning of a bomb to only rez at just below the "trip point" of the fence). It seems to me that when you're talking about preventing exponential growth, a relatively small constant multiple at the start really doesn't matter, especially when the exponential growth is still cut off in the same way. The general order of the growth is unchanged. Plus, you've got the perpetrator right there spawning objects.

The advantage to dropping the fence for attachments is that people get to keep their toys. :)

Any response about the idea doing longer delays instead of outright fails?

Yes, I talked about it in post #44 of this thread. I had an idea when I was writing the reply about how that might actually work, but I'll have to experiment. If I make any progress on that I would guess it would be around stage (2.5) or (4) of the current plan.

Coo. Thanks for the feedback, Andrew.

As of the update this morning attachments should be immune to the llRezObject() portion of the grey goo fence, although it didn't get mentioned in the release notes.

W00t! You rock Andrew

Now if you could pretty please make it so XyObjects works again that would be great

nifty

Well, one of the things that has to be realized, is that sometimes someone needs to leave a rezzer on, as well as rez other things. In any given instance, yes, a rez-rate of 10 rezzes per second is probably not bad for a single given process. But imagine that you are doing 10 processes at once?
It could be a fancy effect. It could be something else. (And yes, I know the general is 240 rezzes per 6 seconds, or 40 average per second. But someone was also saying that 10/s would be acceptable. Personally, I'm having problems with a single project with the 40/s limit.)
In general, first generation (made by the avatar or an avatar's attachment) and second generation (made by an object rezzed by the avatar or an attachment) would appear to be the most used -- although they are also used for guns and gun-turrets, as well as spamming and griefing devices.
Third Generation rezzers could fill some sort of off-target effect, like a sort of fireworks. But they are also commonly used in area grief attacks, where an first generation rezzer shoots out 2nd generation rezzers which travel out and shoot out 3rd generation disruptors and 3rd generation rezzers and so on.

It would seem to me that...
The limitations on the radius of how far out someone could fire these disruptors isn't too limited by the number Grey Goo Fence itself. However, the limitations on how fast the expansion can occur is.
I would question two things -- is the Grey Goo Fence limited to per-simulation rezzing?
And would it be beneficial to add in a 'generation location' to the grey goo fence as well..? This would be so that objects take penalties based on how far away their original spawnpoint, to where they are when they rez the next rez.

It would disrupt an object's capabilities to create effects if the fence reflected how far away the rezzer was from it's orginal position on the first rez. However, if the different generations are rezzed generally far apart (the length of a sim or so), from the previous generation, then it could help to slow the rate at which these griefing devices can expand, and allow for notice to admins.
Of course, since sims are much larger in height than they are in North-South and West-East coordinates, it would make sense to reflect this as well.

If you wanted to get really complicated, you could create a formula based on the number of objects rezzed and the distance between them and their parent's original location, and create a fence on points from that. That would truely nullify a griefing device's ability to spread overly fast (Well, fast enough to span over 100 sims like some of these puppies do.)

But, this is just an idea that may compliment your own and allow some user-freedom. Your idea definitly has it's own merits and definitly can work alone.

I bumped into the grey goo fence this morning makin temp on rez topology maps, maybe you might fix it so it only restricts goo by stopping its moving capability completely?

or, might you be able to have potentially useful and martketable items that might hit the grey goo barrier, authorised and de-restricted to enable their functionality, even though this may mean a permanent no mod being applied even by the creator and future owners. (you could even make a small charge for the 'licensing' service).

Sorry I am also responding to this late, but I have some simple concerns that I do not see as of yet.

Altho I fully understand the need/reasoning behind limits of this nature I do not like the road this is taking and the general feel of limitations over the years in scripting based on a select few.

I really wonder why you LL can't log or make some sort of log based upon statistics of rezzing behaviour on residents that pass a certain "threshold" and take appropriate action on that person/group and or IP.

You have servers obviously, you can detect IP's that connect to you. Why not Ban/suspend people that are obviously abusing SL. Could it not be considered some sort of illegal activity also if it is seen as something that hinders the "service" you provide?

Ever since the end of beta there has been countless changes and limitations because of these few that seriously effect or ruin the enjoyability of the "service" by a majority of your population by making blanket limits and therefore putting restrictions on everyone, most of which are not griefers.

By removing or limiting "law biding" customers. You are allowing 2 things to happen.

1) The griefers are getting exactly what they want, all be it in a round about way, they are hindering the freedoms and enjoyment of others.

2) You are taking the easy way out, and not cracking down on the individules doing this. All this does is make them get more creative or move on to the next thing they want to ruin for us.

What can ultimatly happen, people will get sick of constantly changing old scripts, adjusting their learned patterns of scripting/developing, and move on to bigger and better.

Some of these suggestions posted in this thread I can agree with regardless, but to make a cap on rezzing so close to the legit rezzers actual use stops the possability for making anything that goes beyond that cap for legit reasons. In other words refer to previous mention in #1.

I may post other ideas/rants....what ever later, but I feel this is continueing a bad form for SL one that has mostly turned my away from anything creative in SL and has removed a majority of my interest to even come online any more. Which in itself is sad considering I was one of the first few that tried to find ways around the time limit to be in SL longer in beta just because I enjoyed my time here.


99% of my scripts I have developed since and during early beta are rezzer driven. So this does hit home a bit just in case anyone questions my right to complain such as this.

You aren't hitting the grey goo fence; you are hitting the refigured temp flag (it is no longer temp on rez, it is temp when the box is checked). Look around the forums for the equations for the new temp flag; the limits are a bit complicated.

Was definately Grey Goo fence, they were self replicating, temp on rez map pieces.

It yelled at me! more than once.

I have a class registration object that tracks a class enrollment list, and uses the list to give inventory objects to participants throughout the class. This worked fine until last week, when it hit the grey goo fence, repeatedly. There were less than 10 people in the class, and at most I give 2 objects in quick succession, resulting in about 20 llGiveInventory calls in about 60 seconds (given the built in delay). I do not use link message 'threading' to get around the llGiveInventory delay, I just cycle down the list of class participants and wait for llGiveInventory to return before I go on to the next person.

It hit the fence repeatedly over a one hour period (I give objects every 5-10 minutes during the class as scripting examples), with fewer than half of the inventory gives succeeding. There was nothing else untoward going on in the sim at the time. No self-replicating objects that I noticed, nothing that should have contributed towards the sim's fence.

Is the fence broken? Because my object certainly should not have triggered it, and has worked fine for many months before this incident.

I also hit the fence right after this last griefer attack with my plants in Terminus something I haven't done in months.

Andrew repost from Answers



Is this something that will be activated during an attack or something that will have a negative impact on existing and future legitimate uses of self replication. Artificial life is my personal concern. Terminus is still impacted by the last measures to control attacks.(On that note any progress on no fence for objects on their own land?)

Charlie Omega, yes many changes to the system since beta have reduced the set of possible content, and it is a shame. We're attempting to strike a balance by outright preventing the fatal possibilities, while still leaving enough capabilities to mame. I won't speculate on your item (1), however regarding (2) I think technical solutions to problematic content is the most scalable, which means ultimately the only viable solution.

Goapinoa Primeau, sorry you hit the fence. I've got some improvements to the fence coming in soon that may help reduce your problem, although perhaps it will have the opposite effect. It deepends on how you're implementing your project. You might consider using real prims, and recycling them by moving them to where they are needed, rather than throwing a constant stream of temp-on-rez prims. Dunno how you're doing things, but for best results, rez everything from one or more primary rezzers rather than using recursive rezzing.

Aryn Lassard, the only thing that recently changed with the grey goo fence that might affect you is a clamp down on calls to llSetObjectName(). However, after working on some more improvements I decided that that, and the name correlation penalty for rezzing objects, is just a Bad Idea. I've already ripped that out of the next version of the fence, which will have a narrower focus on recursive rezzing and a higher overall rez rate threshold. As soon at that is deployed I would expect your distribution system to work again.

Sera Rawley, the next set of changes coming in should make your artificial life more doable, unless you're trying to grow your life very fast. To really avoid the fence I'd recommend that you try to keep reproduction times below one minute. The fence's main threshold will be much shorter than that (5 to 6 seconds) however there will be some other fence relaxation logic that will kick in after a minute, and if you keep your reproduction time below that level you should be able to maintain a large army of life on a sim.

This may be a dumb question, but why can't a prim limit in a sim for temp on rez prims for each user prevent runaway grey goo.
I thought there already was a limit, something like your allowed number of real prims on the land plus an extra amount.

If the problem is it keeps on getting returned to the inventory due to this limit, then the act of it hitting this "return to inventory" should be what triggers the script slowdown or script error (slowdown is better).

Not all grey goo is temp-on-rez. In fact, the grey goo fence is more resilient to temp-on-rez goo, since as soon as the goo hits the fence the fence electrifies and each bit of temp-on-rez goo that touches it will be flagged for deletion. If the entire family of foo is temp-on-rez it is possible for it to be completely cleaned up.

It may be possible in the future to only slow down goo scripts rather than cause their oprations to fail; I'll think more about how to do it. I've already got a few ideas, but I need to figure out how to distinguish between real and artificial slowdown of events, so the fence can know correctly when to relax back into monitor mode.