A lunatic theory on limiting grey goo: the Force

Let me start by saying that I've done little scripting in SL so far (lack of time, mostly). So I know very little — even by inference — on the internals of how the world works. That said, I have in the past thought about multi-agent systems of a different sort, so some economic theories of agents occured to me while I was randomly thinking about the SL Grey Goo problem. I thought I'd share the lunacy, if only as an academic exercise.

Given: scripted objects must be able to produce other objects, which are often themselves scripted. There are just too many useful ways to use this to stop it.

Problem: unlimited replication (duh).

My lunatic idea is to add another ambient force to SL, just like that highly erratic wind. I wasn't sure what to call it (I'm used to this in economic models), but for now let's just call it the Force. The Force is everywhere, always slightly increasing up to some set limit (perhaps adjustable by sim owners). The excess bleeds off into the Void.

Every time a scripted object (not avatars) produces a prim, it consumes a bit of the Force, lowering the ambient Force. Well-behaved scripted objects will of course use the Force regularly, but at a rate that allows the ambient to catch up.

A rapidly replicating object will consume a lot of the force quickly, and when it depletes it all, it will be stopped, or rather be slowed to the rate of ambient Force replenishment. Of course, so will any other object attempting to produce new prims, but the Lindens could watch for sims where the Force has been completely depleted as a sign of potential problems. Sims could monitor the ambient Force in their neighbors and deliberately dump force as a self-defense mechanism.

I can imagine how this might be coded, but of course I've never seen SL source code, so I have no idea how it might accept this model. There may be other show-stoppers I've missed due to my SL inexperience.

Anyway, a few random thoughts.

And I thought this was going to be something involving Jedi....

What happens when you have vehicles, rifles, etc, rezzing bullets as quickly as possible, below the current grey goo limit, but fast enough to lower force levels.

All it would take is a group of troops to walk into a sim, all fire off their weapons for a few seconds, and the entire sim is depleted of all its force and will only slowly replenish.

What if a battle erupts? Fair automatic weapons rez 2< rounds /sec times two teams at five men each.

2</sec * (2*5) = 20< prims per second being rezzed, plus other weapons, multiprim rezzing weapons, etc..

So 22< prims per second, over perhaps.. a minute? Thats 1320 rapidly rezzed prims. If the gun fires 4 per second, its doubled.

Add more men, this could cripple any sim is spills over into.

Treat worn scripted objects the same way as the avatar? In my current conception, avatars are not limited by Force availability.

Can we call it the schwartz instead?

Tuning the mathematics of 'force' calculations would be a painful process at first, and would likely break a number of existing systems. As SL ages, the burden of making the system backward compatible with older scripting becomes more difficult, unfortunately.

Of course, the 'force' idea has a close analog from the Havok implementation that LL is using. Any of you scripters out there ever had a physical creation run out of Energy? AmIrite? AmIrite?

I'm not saying this idea is good or bad-- as an INTP (for those of you who believe in such things), hell will freeze before I develop a strong opinion on much of anything. Anyway, using energy as a proxy for 'force' (both of these terms are ambiguous and vague, but serve a useful role), can we evaluate the potential of 'force'? Did energy accomplish what it was designed for?

EDIT: My vote is for schwartz as well, in honor of Schwartz Guillaume. Yay Spaceballs! =D

I'm sure it would. Testing, testing, testing!

Another thing that occured to me: the request for the Force to replicate will necessarily be a blocking call. Make it slower as the Force is depleted.

So you're essentially proposing to create a race condition between exponential replication and force-dependent rezzing. *head explodes*

Nope, I'm proposing resource starvation. I'm sure LL could manage appropriate mutex control over the Force pool. I'd be surprised if there aren't other places in the system where atomic access is required.

My guess is that it wouldn't be affected by anything "Temp on rez", that is to say only affect things that could stick around longer than a minute or two. It'd be like forcing a time limit on objects for those who forget to code one in themselves....(am I on the right wavelength here?)

- Jolan

A TemporaryOnRez object can exist for up to a minute. That's more than enough time to reproduce; 5 seconds would be. TempOnRez objects are already subjected to population control, so I'm not sure if they're a source of grey goo problems anyway.

Actually, I've had TempOnRez objects last for nearly two minutes, but I agree - they're not specifically grey goo issues.

This is a bad idea, because instead of preventing attacks, it would create a whole new venue of attack: resource starvation. For example, griefers could spend all of the force in a Sand Box, making it completely useless. Or maybe they could go after malls with item displays. But in either case, even legit scripts would not be able to Rez objects. And that's a bad thing. There's absolutely no reason to limit anyone but the griefer. Thus, instead of it limiting by sim, it should limit by user per sim (EX: a person may have holovendors active where that person isn't, which shouldn't be limited by activity in other sims, like holovendors elsewhere).

I should have made it clear at the start that this Force business isn't designed to prevent attacks, but to contain them. I'm simply assuming that SL has entered the same sort of arms race we seen in the SPAM battles. Attacks aren't preventable as long as people get to produce their own content.

The Force quota gives the Gods a chance to wipe out the abominations before they spread too far, by notifying them quickly (zero Force in a sim should page someone) and by limiting the number of sims that need to be bounced to clear out the ick.

I see this Force model as only part of attack prevention and control.

utterly bad idea

why ?

Because its human nature to try to stop other people's property. If u think that making rezzing something dependant on a Maxtotal of whateverucallit. Then im 100% that within 10 minutes theirs gonna be objects that can whoop that Maxtotal to 0 in less then 1 second. Doesnt matter how small the value is for an item; if 1 dont cut it 10, and if 10 dont then 100.

One variation on the theme might be to use force allocations per scripter key, not by region? Dunno.

This is a circular argument. There are already people "stopping other people's property." The very nature of SL gives them wide scope to exercise their sociopathic talents. The addition of another way to cause people misery would be a drop in the bucket, especially since the Force model I propose controls only one thing, scripted production of new prims. Everything else would still work, which is often not the case when a sim has been overrun by grey goo.

Even screwdrivers can be misused. That's no reason not to have a few around.

One limitation of self-replicating objects is that they must all be owned by the same person. If the servers count items rezed-by-objects on a per-person basis and that count goes over a certain threshold in a given period of time, then blocks can be triggered that might prevent or severely delay object-rez-object events for that person, as well as notify the appropriate Lindens of the event.

Being a per-person monitor, no one could grief others by rezing things. By counting only objects rezed by other objects, you can still drop your fully-loaded convention center on the ground out of your inventory without setting off alarms.

That would work very well, too, but imposes a larger penalty in terms of memory use for the sim software. The common Force pool is simpler (less buggy, I would hope) and requires only the space for a single counter. Objects rezzed per owner would take more memory and requires more housekeeping code — how do you decide to clean out an owners rez count? And to work best it would have to contain historical data.

Having said that, I'll admit the common Force pool might be a premature optimization.