Grey Goo Fence

Let me think about that one... ok done. Crash. The disruptions aren't near common enough to be worth breaking scripts all the time.

If you had non random numbers of rezzes at each stage you should be able to calculate exactly how many objects you're rezzing, and know when they're about to be rezzed. If you have random numbers of objects, then work with the maximum possible number of rezzes at each stage.

Have you tried putting in a llSleep(1.0) before every rez command? I think longer sleeps for prims further along in your tree of rezzers should ensure that you are always rezzing at a constant rate, no matter the stage you are rezzing, and then you'll be fine.

Ok, so the forest will take a minute or two longer to rez than it used to, and I can see that would be an annoyance when testing, but it doesn't make it impossible.

As if primmies weren't already dead; this would kill it. I'm glad to see this is finaly high on the priorities (only been waiting 18 months ).

I'm not sure I'm a big fan of this, because it may break existing content. In the case of building rezzers, for instance, you might get a half-rezzed building with no particularly convenient way of recovering.

Way back when object-to-object llGiveInventory was (temporarily) nerfed, and broke my content, I was talking to a Linden who was working on the problem.

He suggested one potential solution to preserving existing functionality would be to allow object-to-object llGiveInventory(), but if and only if the owner was in the sim. So you could have self-replication, but not grid-wide self-replication. I liked that solution.

What about augmenting your solution with that idea? So if you (the object owner) are in the sim, everything behaves as it always did. If you are not in the sim, your throttling behaviour kicks in.

That seems to combine the best of both solutions, and I can't think of a single script that behaviour would break.

If I understand correctly, that shouldn't happen, since each part of the building was created by hand, and so has a different family_id. It could screw up something building procedurally, although the most popular ones I know of shouldn't be affected.

Ooh, me too. That sounds perfect. Scripted land editing only works with the owner in the sim, kindof a similar situation with a similar solution.

Hi Andrew, does the fence affect object to object llGiveInventory() or is it ONLY llRezObject().

I'm developing a full blown eco system in my sim which relies completely on llRezObject and llGiveInventory. Although it rezzes very slowy, it's remotely possible there could be many objects rezzing simultaneously, ( please see this thread )

Would it be possible for sim owners to have this "feature" turned off (per sim) if it becomes a problem for our own projects ?

The family ID would match when using building rezzers, because those hand-created parts are all rezzed as descendants of the rezzer object, if I correctly understood Andrew Linden`s follow-up post #24 in this thread: The family is determined by the single datum of what object an object was rezzed by, and nothing else, while other parts of the trigger are based on other data.

Anybody: Please correct me if I am wrong. Toodle-oo!

Ah, yes, looks like I misread. I was thinking a family_id was something else. Still, building rezzers are generally used with a minimum number of link_sets, and they tend to rez the pieces sequentially rather than doing some kind of exponential thing, so I can't see how 40 rezzes per second could ever come up.

Something like Cadroe's or Jeffrey's building tools could fall afoul of this, although neither of these do, since they again have a single object rezzing, rather than using a cascade.

The XyObject is a known example where a build-seed runs into the fence. Not because it is rezzing > 40 objects a second, but because it uses a few levels of self-replication and delegation to construct a giant surface. It looks almost exactly like grey goo during its growth, but it eventually stops when everything is in place. Also, it doesn't rez a few pieces with many parts; each prim is rezzed as its own object.

Do you plan any changes to fix this, Trep Cosmo's fractal trees, and my forest rezzer?

Sorry for getting into this convo so late :\ I know that my sim tree planter would hit the fence... and something quick. probably looking at about 65000 trees in about 120~180 secs. They would all be in the same family too.

I think the fence-per-owner option is cool. Perhaps a default value for new accounts and an 'on-request' boost for older accounts. Or depending on your rating with LL (rating as in grief reports etc, not IW rating) you could get a boost.

Also what might work better is the exponential curve... kinda what Talarus Luan posted earlier. Except I would find a trigger value of a couple hundred then just start multipliying... EX: just start at that 240 it then initiates a delay of 0.1 and starts doubling it every rez until a 'quiet' periode is reached. So you get to crazy rez delays of like 10000000 seconds in a real hurry. This was stuff would always 'complete' to rez and self replication could be detected and cleaned up without any major damage.

I like the idea of grey goo fence, it had to be done sooner or later! Keep up the good work!

Can this 'fence' be made an estate tool option, for those who know they are doing things that could hit it unintentionally?

I'm curious, how is the count reset? if I rez 200 objects in 3 seconds, wait 2 seconds, then try to rez 100 more, will that succeed or fail?

Fail, I think from what I read it's total 'silence' from the key functions they are trying to block.

I like this too. I vote get rid of the fence and impliment this change. It'll preserve existing content.

How about no fence for objects on land owned by the owner of the object or objects owned by the group they are set to. And in the case part of a family hits the fence the part over your own land shouldn't. In 2 cases I have planted partial sims and it wasn't practical to specify what part of the sim to plant and what part not to. The script just had to try and fail.

I can think of at least one project I have in mind for the future that'd involve llGiveInventory between objects when I'm not around. It'd suck if this wasn't possible. The grey goo fence is better than a blanket denial of llGiveInventory when the owner isn't around, because you can deal with the grey goo fence if you program carefully enough.

Ah, nice, an AI project to counteract the goo!
Nice to see something simple and truely effective, if swiss cheese of false positives and missed goos. Still, I like the idea and eventually we'll have something that always works.

Reminds me of my roommate's AI homework a few days ago, heck, it took a whole day to find the difference between brwon and pink! (The prject was to be able to control those robotic dogs that play soccer with pink balls). We were trying all kinds of things, some of which worked for some pictures, and then completely broke others!

Keep up the good work (now we just need something that would limit llPush the same way, I was tossed up above 1,000,000 meters in under a minute the other day by this b*tch--TPing out and back didn't solve the problem, it was a consisten llPush(me) that so long as I was in the same sim as her, I was flying upwards at an estimated 20,000 m/s).

FYI, I just ran a test, and the grey goo fence does not behave as advertised.

As Andrew posted, the grey goo fence shouldn't kick in unless you exceed 40 rezzes per second. My testing shows that it kicks in somewhere before 25 rezzes per second.

If you want a copy of my test, send me an IM in-world.

Testing just now, I got "grey goo fence: rapid or recursive rez" messages from anything over 20 rezzes per second. Exactly 20 seems okay. (Apologies to my neighbours for the noise - I plugged the repeat rate into an automatic cannon.)

That's quite annoying as I had planned the rate of fire of the cannon specifically so that it didn't hit the fence as advertised - I could have had some pissed-off customers there.

The initial number of 40 was probably only a starting value, it's maybe been tweaked since then.

I think we need to understand that it is impossible to protect SL as it stands, however, I suspect there is a middle ground which will evolve over time which will be different from what we see today but still just as compelling.

Yes, not all of the details of the fence have been advertised. There are some extra events recorded for rezzing/giving to physical objects, and recursive rez/give. Unfortunately, I had to add the predjudice against physical objects to catch a known instance of a stacked sim bomb that was being distributed (not true grey goo, but an expanding army of rezzers nevertheless).

I talk about Francis' issue briefly here.

I just looked back at the code to see how easy it would be to change. I currently envision three stages of changes, so here's my plan of the moment:

(1) Push the fence out for attachments so that they don't suffer penalties for rezzing physical objects, and maybe even for recursive rez/give. I'd keep the family_id fence in place.

(2) Push the fence out for land owners rezzing on their own land. Maybe also push it out for rezzers in the presence of their owners -- I'm still not sure how simple/cheap/easy that would be in the context of the rez code in the simulator. This is a separate stage because it would require a bit of re-organization of the code so that the fence could span more C++ context.

(3) Add some more intelligence to the fence which may allow me to raise the total rate*time product and thereby recover some of the former volumes of possibility space. The idea is to record the generation number and age of family members, and to use those numbers to scale the 'event' count. So the 3rd generation object rezzing shortly after its birth would be more suspicious than a 7th generation object rezzing when it is a minute or more old -- bursty growth would be impaired much more than gradual evolution.

Other stuff, like making the fence a per-sim or per-estate option would have to wait for the aforementioned stages. It would be my hope that the fence could reach a state where the demand for exemption from it is low or nil. In any case, I'd prefer to punt on that in the hopes that it lands in a future where making UI/estate changes is easier.

I'm curious to know... for those of you who are hitting the fence for 'legit' content right now, or in your plans... at which stage do you think you may be immune to the fence? Assume 40 rezzes per second * 6 seconds until stage (3) at which point it would be changed to new more permissive magic numbers.


As to suggested limitations of llGiveInventory() requiring the owner to be present: I believe that was tried way back when it was first introduced but then removed because it broke some types of vendors that we wanted to enable. We're now looking for alternatives to that limitation.

What about sat-on objects for (1) as well?

Ok, I'm going to try to get stage (1) into the first non-emergency patch for 1.10, which should be released next Wednesday (24th). I would expect the first patch to happen one week after release. Maybe I'll push the fence out for seats too... not sure yet.

Perhaps you can help me with some decisions I have to make:

Should attachments be totally immune to rez limits? Or should they just have a more liberal limit?

Should attachments be constrained by family_id such that they will fail to rez if what they're rezzing hits the limit (by rezzing too much shrapnel for example)? Or should attachments be able to rez as many bombs as they like even if the bombs are already known to be throttled?