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.

Comments [Hide comments/form]
Wouldn't it be better to place the failsafe code in a separate script within the object? Just run a timer in that other object, and die when appropriate. That way, you won't have to pepper your script with the code or mess up and not check if in an infinite loop.
-- HankRamos (2005-07-06 07:50:14)
Woah, I had the same thought, and I added it before I even read your comment. Yes, I completely agree, a second failsafe loop would be much easier.
-- KeknehvPsaltery (2005-07-06 09:08:00)
What if the watchdog script is stopped, then? (I really don't know what external events will stop a script, but I do know that now and then I stop scripts to edit them and forget to turn them on...)
-- StefanNilsson (2005-07-11 11:44:56)
Yes, well, then you're just screwed. If you're making a script like this anyways, you should be careful so as to not have an angry mob of lagged Residents after you. It's not our fault if you're incompetent.
-- KeknehvPsaltery (2005-07-11 16:39:07)
Here's a crappy solution: build an interlock into your main/real scripts, which ask the watchdog if it's alive, and don't run until they get a response from it.
-- GenePoole (2005-07-13 23:19:29)
Why's that a crappy solution?

By the way, I added a paragraph about how it's actually done - as I've understood it. If I've complicated the procedure, please correct it.
-- StefanNilsson (2005-07-15 12:01:20)
I would REALLY like to know what the examples that went wrong are. I can't access the MG forum, as I'm a TG account.
-- CirrMarat (2005-12-03 03:35:09)
I was giving a warning for letting lose a horde of 'Green Slimes'. But I was three days old, and told to help expand SL's wildlife with them by a troublemaker.
-- SevenEightTwo (2005-12-11 04:29:59)
me too. im TG member cant go MG forum. lol. how could it go wrong?
i just had a idea:
turnni1 sim crashing script.
refering to:
Usually because they can bring down simulators and/or harass other players
-- Turnni1 (2007-01-13 07:19:37)
Um, this is my first contri to any wiki ever. So please pardon if this is out of line. I fear that too little emphasis on the difference between the kind of linear mode replication ( of the example page ) and exponential replication. which rapidly ravinously gets out of hand. I'm intrested in this for AL, but the fear of out of controll replication has kept my pace extreemly measured.
-- ZenZeddmore (2007-08-30 18:29:14)
Also, I seem to recollect this page having a few more ideas on failsafes. Like " if not owners parcel then die " . I like the suggestion of having it listen for anyone saying die, this info (especialy the chanel) sould be stated in the name or the discription .

To err on the side of caution, incorperate ALL of these safegaurds. run away replication is nothing to mess with.
-- ZenZeddmore (2007-08-30 20:13:04)
i particularly like an attachment with this code on board

touch_start(integer total_number)
llRegionSay(5000, "die");
-- ZenZeddmore (2007-08-31 04:02:18)
Attach a comment to this page: