Don't click here unless you want to be banned.

LSL Wiki : SelfReplication

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are


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


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:


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:

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 )

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;

    if(llGetWallclock() > dieByTime)

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.

There are 12 comments on this page. [Display comments/form]