Breeding like prims

So yet another thing about having one’s own private virtual world is that one can do all sorts of fun but dangerous stuff that one wouldn’t do in anyone else’s.

The main fun-but-dangerous thing, naturally, being the creation of uncontrolled replicators.

(Carefully controlled replicators are safe even for, say, Second Life; and of course SL has the Grey Goo Fence, which is good for the Grid but can be annoying for Residents.)

The other day in my local OpenSim-on-a-stick I made a little physical sphere that randomly moves around. It promptly took off into the open water ‘way off the side of the sim (into space that, strictly speaking, doesn’t exist).

So then I made a tall green wall, and put the randomly-moving ball inside the wall, and that was better.

Then I taught the ball to make copies of itself, and also to randomly delete itself. I set the probability of replicating just barely above the probability of self-deletion, knowing from my days as an Anti-Virus Guru that this should lead to an (initially) slow population increase.

Then I got bored, watching the number of balls inside the wall go from one to two to three, back to two, back to three, to four, back to one…

So I cranked up the probability of replication a bit. And then of course the phone rang and I had to open a different window to do something, and when I went back to the viewer:

Runaway 1

Oh, dear.

Well, no problem, I thought; the sim was running kind of slow, but I could just cam up, select everything nearby, deselect the wall, and hit Delete.

And that worked great, except that in the few seconds between my selecting everything and hitting Delete, another few dozen balls had spawned, and they weren’t selected or deleted, and then a couple seconds after that the sim was running so slowly that deleting stuff wasn’t really working anymore.

And then I noticed…

Runaway 2

a potential crisis! If the balls were to start spawning outside the wall, it seemed not unlikely I would have to restore the sim from the last OAR file I took or something.

On closer investigation there were at least three balls that had apparently escaped the wall:

Runaway 3

but when I went to examine (and hopefully quickly Delete them), it turned out none of them actually existed as far as the sim was concerned, the viewer was just confused as a result of all the physics and lag going on. So that was good.

I thought I would log out and then log back in as the AV with Estate powers (Simona Stick, rather than Test User). I noticed that over on the Opensim console, things were not entirely happy:

Runaway 4

It look a long time to settle down again when I tried to log out, and at this point I started to panic a bit. In the time it would take me to log in as the estate owner and try to turn off scripts or whatever, would the sim have become utterly unusable? So instead I did a shutdown on the Opensim console. This resulted in lots more red messages for quite awhile…

Runaway 5

but eventually it did shut down.

Okay, smartypants, so now what? Well, it turns out that Opensim in Sim on a Stick happens to use a MySQL database to store everything in, and that due to the Day Job I have some knowledge of MySQL, and the database tables that Opensim uses are at least somewhat documented.

So once I’d figured out the MySQL username and password that SOAS had installed, I logged into the MySQL console, and viola:

mysql> select count(*) from prims;
| count(*) |
| 1482 |
1 row in set (0.00 sec)

So we have fourteen hundred and eighty-two prims. Fortunately all of the self-reproducing ones have the same name, and each rezzed prim (as far as I can tell) corresponds to one or more records in just three different tables.

First we delete the shape-records for the prims (Opensim could save considerable space in the database by compressing out duplicates here, one would think):

mysql> delete from primshapes where UUID in (select UUID from prims where name="moving and reproducing ball");
Query OK, 1294 rows affected (0.05 sec)

So it looks like we have about 1294 replicators

Then, we destroy the contents (prim inventories) of all of them:

mysql> delete from primitems where primID in (select UUID from prims where name="moving and reproducing ball");
Query OK, 2385 rows affected (0.14 sec)

And that more or less makes sense; each replicator typically contains a script and a copy of itself, so we’d expect to have roughly twice as many contents as we have replicating prims. 2385 is somewhat less then twice 1294, but that’s because of that “roughly” in the last sentence, which I will not go into in detail.

And finally, we remove the little beggars themselves:

mysql> delete from prims where name="moving and reproducing ball";
Query OK, 1294 rows affected (0.05 sec)

Another reassuring 1294.

Now we would expect to have 1482-1294 prims left, and:

mysql> select count(*) from prims;
| count(*) |
| 188 |

(counting on fingers) that adds up!

Crossing our fingers and venturing back into the world as Test User, we find:

Runaway 6

The wall (and everything else) undamaged, but the nasty replicators gone! And sim performance back to normal. So huzzah!

Disclaimer: I have no idea whether the steps above are actually the right way to remove a bunch of nasty things from an OpenSim instance, and for all I know they have left the database in some incoherent state that will cause it to die horribly tomorrow. If your Opensim world is valuable to you, take frequent backups and don’t go messing with the database directly in MySQL because of something you saw in a weblog once. Also, in retrospect, it probably would have been cleverer to use MySQL just to turn off scripting for the estate, and then gone in and cleaned up normally inworld. But hindsight is a penny earned!


Who you callin’ goo?

We start this morning’s entry in the Thingmaker Weblog :) with a picture of five more things that the Thingmaker made yesterday:

Five things all in the same picture!

(See also bigger.)

I like the upper-left one because of the weird flickering pseudo-texturing that it has, due to almost-overlapping prims. That’s something that I would normally never think to do when building by hand; the flickering-texture effect that you get when two prims have coincident surfaces is generally a bad thing. But Thingmaker doesn’t know that, so it plays around with the effect freely, and in this case with a neat result.

And I like the lower-right one for its total flatness of color. I’m not sure how it did that! Obviously it has shiny turned off, but usually that wouldn’t do it this thoroughly. I’d say that it might have fullbright on, but I’m pretty sure that I haven’t taught it about fullbright yet! I love it when my thing-creator things create things that puzzle me. :)

I didn’t make nearly as many things as I otherwise would have last night, because for some reason the Thingmaker kept getting shut off by the Grey Goo Fence, a feature of the SL laws of physics designed to prevent some kinds of griefing attacks.

I was (and am) very puzzled to find the relatively slow and not-numerous rezzes that the Thingmaker does hitting the fence, especially since it was if anything even slower than it was the two days before, when it didn’t hit the fence once. Maybe they’ve been changing the fence rules: they do that periodically, and they don’t document exactly what the fence rules are, for the pretty good reason that they don’t want griefers to optimize their griefing tools to come right up to the edge of the fence and stop.

It occurred to me that it was sort of odd to have the fence tripping on me on my own land, anyway (I was in the Hughes Rise park); I don’t really need to be defended against griefing myself! :) So I opened a JIRA suggesting that fence rules be relaxed when the object doing the rezzing is on its owner’s property. I’m not sure it makes complete sense, but it’s at least worth considering.

Amusingly enough, while I was looking to see if such a JIRA already existed, I came across another JIRA, complaining that the fence wasn’t strict enough, and was letting griefers rapidly rez thousands of objects. So I stuck a comment in there also.

Hard things to contain, these replicators!

(Oh, and while we’re on the subject, here’s an important JIRA that all SL users should read.)