LSL Wiki : SelfReplication

Self-Replication

In a worst case scenario, self-replicating objects will get you banned from SecondLife. Usually because they can bring down simulators and/or harass other players. Self-replicating objects that are an annoyance of any fashion are against SecondLife's community standards.

So far, every noticeable case of uncontrolled or excessive self-replicating objects has resulted in threats of banishment from SecondLife. Except in the latest instance where the user was perm banned.

Self-replication requires the use of llGiveInventory. This function call has a built in delay of 3 seconds each time you call it.
It also requires the use of llRezObject, which has a built in delay .1 seconds.

How it's done

See Example of Self Replication

WARNING

To read an example of self-replication gone bad, click here, here, and here. This is just the most recent example, and others involved ants and "green slime".

If you're still looking to perform self-replication experiments, here are a few suggestions:

Precautions

Test everything first. Run test case scenarios where you code in limits on how far the objects can travel. Test things in the island sandbox first.

There are several things that can ensure that you do not get abuse reports if you ever do make a self-replicating object. If you're planning on releasing your script 'in the wild', implement at least two of the following:

Add a ttl counter - a counter that counts down one with every replication, and stops replication if the counter reaches zero. This is the most BASIC precaution. An example of this is found in the example of self replication

Slip in a distance and/or simulator limitation. This would be especially useful when you have the replication under control and predictable, and want to see what people's reaction to the object will be. Release the object in a single sim only, and kill off the object if it ever leaves that simulator. This will give you a reasonable judge of how people will view your object (Annoyance? Cute? Abuse report worthy?) and will also give you a smaller area to search if you ever have to clean up the objects quickly.

Create a function that tests to see if it's after a certain time. If it is, the object should kill itself.

This code kills the object if it's not its day. (Every dog has one, but necessarily not today)

string daytolive = "2005-07-15";    //The one day that this will be alive for

integer failsafe()            //Are we allowed to live today?
{
    if ( llGetDate() != daytolive )
        llDie();
}

Of course, it is possible to make it live for two or more days by using ORs.

If you want to specify an even narrower life-scope you could check for a certain time-of-day.

integer dieByTime = 120;

failsafe()
{
    if(llGetWallclock() > dieByTime)
        llDie();
}

The above script would kill off the object if the failsafe() function is called any time after 1AM, server time. llGetWallclock is handy for this sort of work.

Common to both, is; be SURE to hardcode the die-by time into the script, rather than letting the script figure out when it should die by on it's own. Yes, it means you having to change the "constant" each time you want to save your script, especially if you're being smart and limiting your tests to five minute intervals, but it's a lot better than having a thousand objects creating copies of themselves every four seconds.

Observe that if you do it in the self-replicating script itself, you MUST put this failsafe function call at the beginning AND end of every event, inside of every do, for, and while loop, and pretty much everywhere else in the script, in order to avoid the test not ever being reached because of infinite loops. (i.e. If your script gets stuck in a while() loop that doesn't have the failsafe, since it's never leaving the event, nor is it ever going anywhere else, it'll never test the failsafe condition.)

Most definitively you should do this test before rezzing the offspring.

Add a watchdog timer. The watchdog calls the failsafe function regularly.

Have the object listen on a channel for a death command. For example, you could make it listen on channel 300 for anyone saying "die". This might lag the sim up, but if you're making a self-replication script you really shouldn't mind that much. This would also make it easy to make something that would ensure them to not bother you.

Make the object cost $0L, and set the buying option to "original". This way, people will be able to buy and delete the offending objects themselves.

ExampleSelfReplication