von Neumann machines

I've been on SL for about three weeks now and I'm pretty n00b on building and scripting still, but I'm quickly getting the hang of it. From looking through the LSL docs it looks possible to build a "true" von Neumann machine in LSL of more or less arbitrary complexity. Not just a prim that's capable of rezzing some other object, but a scripted object that is capable of building more just like itself strictly through scripting, which itself is able to build more of itself.

I joined up from reading about some alife experiments being done in SL, so this is exactly the kind of thing I find fascinating about SL. But before I go and do something stupid, I have some questions:

Has anyone actually tried this? Have I just not familiarized myself enough with LSL and I'm going to hit some major block that makes it impossible?

How would one go about testing this sort of thing without getting onesself into trouble for say, forgetting to make machines llDie() and crashing a sim...?

Is this something I should even mess with or will I flat out get into trouble?

Assuming I could do this and not get into trouble, is there an easy way to issue a command that would llDie() _all_ of 'em that have been created? (Is this just a listen() on a custom channel, perhaps?)

Personally I think it'd be cool as heck to see a bunch of little robots running around, waving their arms and "assembling" more little robots that would run around and wave their arms to "assemble" more robots that.... Just so long as I could keep them all under control.

For safety's sake I can always have the first vnm build his child and then llDie() himself so there is only ever one little bot running around making a new bot and then dying. (Poor little bot....)

There's a wiki page on this topic you may find interesting:

http://secondlife.com/badgeo/wakka.php?wakka=SelfReplication

Jess

Ah, cool, that pretty much answers everything. I hadn't run across that page yet, thanks.

Yes. I made the mistake of not properly coding in a failsafe (forgot to add the llListen to the state entry so I just shout...) and brought down Cordova, then Goguen, then Abbots.......

Speaking from experience, I think there are at least two failsafes you should install BEFORE installing the self-replication code:

1) A travel check. Basically, have some centre-point that the experiment is focused on, and if your replicant finds itself beyond some safe distance from that centre (this number would depend on your needs, but I find 20-50m is more than enough since you need to be able to monitor your experiment) then it should either (a) critically damp its motion back towards the centre, or (b) kill itself (or perhaps (c) just freeze in place...but that could get ugly easily).

2) A population limit. This is tough (since sensor sweeps only return 16 objects matching the parameters of the sensor, and as a result objects dont know the difference between being around 17 and 170 objects), but you need to make sure you dont inadvertantly create a billion objects (I crashed a server a little while ago with a stupid food script...). The MOST reliable method is to have a "monitor" object that just keeps track of the numbers of your replicants, and have those replicants ask for permission from the monitor to reproduce (e.g. the monitor only does three things, 1: listen for creation requests, 2: grants the request if the max number hasn't been reached, 3: if permission has been granted, raise the number of existing replicants by one). A more sophisticated monitor would also be able to account for dead replicants (i.e. keeping accurate 'score').

3) A kill-switch. This could be accomplished a variety of ways, but the simplest is a llListen() on some channel (just not 0) that looks for some failsafe command (e.g. "KILL ALL REPLICANTS". The best way I've thought of to accomplish this is actually to have a seperate script inside the object that does this (in other words, have the scripts that control your objects actual behavior, and then ALSO have this kill-switch script). That way, your other behavioral script can switch states, etc. (which normally kills listens) while the kill-switch script quietly listens for the suicide command. A more sophisticated version of this would have a variety of commands, such as "FREEZE", "STOP BREEDING", "RETURN TO ME", etc. limited only by your imagination and experimental needs.

As an addendum to 3), I'm actually planning on releasing a copy of my fail-safe script later today or tomorrow, in order to encourage more people to play with self-replication safely. If you can't code it yourself, look for my post then.

How much would you pay for such a self-replicating, wandering Chocobo ?

One method I have used to keep my self-replicating project under control is to check the fps on the sim. If it goes below a certain value, the objects begin dying.

So, I noticed in the LSL wiki page for llSetStatus() the option "STATUS_SANDBOX" which prevents objects from crossing sim borders or moving more than 10m from its starting position. Has anyone ever tried this for self-replication? It seems like an ideal fail-safe, does it work?

By the way, I really like your other suggestions, and I think that fail-safe script will be really helpful.

These are all really good suggestions. I'm happy to see that others have at least attempted this, even if there have been ....errrr... unexpected results.

I think the idea of having the builder llDie() as soon as it builds a new one is probably the way I will go. That way there's never more than one around at a time.

And I'm thiking little wandering domo-kun...

These can be fun, but I've so far avoided building a replicant object. Too many things to go haywire.

The above advice is good, but let me inteject a few others:

1. You need to put a resonable delay into the 'replicate' code. Why? To make sure that you don't activate it and that it begins instantly building more faster than you can stop them. A fast loop could build thousands in seconds, bringing a sim down soon after you click SAVE.

2. Be aware if something goes wrong, about half the people you meet are going to want to remove your head first, and ask if it was intentional later. The least inconvenience will make angry mobs faster then a murder would...

3. Make sure you have a seperate script in EVERY replicant. This script should do nothing but listed on a sub-channel for the command to DIE. Why a seperate script? No state changes will turn it off, so less chance of a mistake. And if things go wrong, use the SHOUT option to cover a 200 meter area in one hit.

4. If your project is going to breed fast, then make sure it's as low prim as possible. Heck, one prim with a good texture can do it if your imaginative. Picture a half sphere and a pill-bug texture...

5. If possible, use temp-on-rez. this allows the lindens to just kill scripting in the area temporarily and let the problem clean itself up as the critters die off without being able to move or breed.

Thanks for your time, and remember:

Safe procreation is FUN procreation.

What about:

- each creature can replicate once then later die
- the probability of dieing within a given delay after having replicated grows as the sim's FPS go down
- the probability of replicating within a given delay grows wwith the sim's FPS

I forgot to post this earlier:

I'm not bothering to post my whole security script, but to clarify, all it does is listen on a given channel (an uncommon one, presumably) for a self-destruct command. When it receives the command, it first re-shouts that command (so the self-destruct echoes outwards, hopefully encountering every wayward critter) then immediately llDie()s.

This would be the perfect example for why there's an island sandbox and why we probably need more of them.

Well, it's true that those sandboxes have a good purpose, but I don't think we need to limit all experiments to them.

Actually, I'd rather we taught people to be more responsible - eg using failsafe switches - since in the long run it's more beneficial.

That said, I -would- like more sandboxes, if just to encourage more risky experiments (e.g. more potentially laggy stuff, etc. that nonetheless might be very interesting).

considering how often the sandbox sims go down, i think people are learning efficient ways to tank the sim.

I just take a linden-created library script, add llCrashSim(REALLY_REALLY_HARD); to a new script, and run like hell.