Self-replication once per sit

I have an object that on sit moves the avatar to a different location. I also need the object to leave a copy of itself behind, in the exact location and rotation as the original. Because of this a normal rezz from inventory will fail, because of the iterations of multiple use.

I also don't want to create a self-replicating disaster

It needs to make one copy, per sit not keep replicating like a griefer object. Rather than messing up a sandbox, would like some advice , would this work?

changed(integer change)
        {
        if (change & CHANGED_LINK)
            {
            key user = llAvatarOnSitTarget();
            if (llGetAgentSize(user) != ZERO_VECTOR)
                {

                llRezObject(NewObject, llGetPos() + (<0, 0, 2 > *llGetRot()), ZERO_VECTOR, llEuler2Rot(< 0, 0, 0> * DEG_TO_RAD)*llGetRot(), 0);
                llGiveInventory ( ITEM, llKey2Name ( ITEM ) );

                integer access_granted = FALSE;
                if (access_mode == 1)
                access_granted = TRUE;
                if (access_granted)
                    {
                    vector init_pos = llGetPos();
                    posJump(destination);
                    llSleep(0.2);
                    llRezObject(2ndObject, llGetPos() + <0, 0, -3.9>, ZERO_VECTOR, ZERO_ROTATION, 0);
                    llSleep(0.2);
                    llUnSit(user);
                    llDie();
                    }
                }

Or you can have the first prim return back to the starting position instead of dying.

well the effect needs to be that the object never leaves, so the copy needs to be rezzed while the original leaves for a high altitude trip
the give item from the wiki gives the content of the original to the copy. Here was the example code:

default
{
touch_start ( integer NUMBER )
{
llRezObject ( "Object", < 0., 0., 1. >, ZERO_VECTOR, ZERO_ROTATION, 0 );
}

object_rez ( key ITEM )
{
llGiveInventory ( ITEM, llKey2Name ( ITEM ) );
}
}

from http://lslwiki.net/lslwiki/wakka.php?wakka=ExampleSelfReplication

posJump is so fast you it would be back in about 1/2 sec, .4 of that is the sleep you put it. It would be back in about .1 sec without those.

Hmm ok i'll try that and see how it looks, the final would also use an animation

Rather than actual self-replication, it's sometimes useful to have a permanent object at the starting location, and use it to rez the moving object when the moving object has been "consumed". Then just have the moving object die when it's done. This makes it a lot more difficult to do anything that might bring a whole sim to its knees, and doesn't look the slightest bit like actual self-replication (recursion can be nasty).

This is what I always do.

Just set up a sensor that scans a 10 meter range for the object name every 10 seconds or so. You can even make it record the object position and rotation the first time, to use when it rezzes the object from inventory. Leave one copy of the object in the desired location and put a copy into the rezzor inventory.

Right. Or grab the key from the 'object_rez' event and use llGetObjectDetails(). Doesn't hurt to send "die" commands too to prevent accidental clutter just in case.

I, also, always do what Hewee said ... the way mine work is that you touch the permanent object, choose your destination from a menu, then a TP "chair" is rezzed from the permanent object's inventory. The chair's script sets itself temp_rez as soon as it is rezzed, plus it dies after the TP, just to be sure it's gone.

However, if I wanted to do it with one object, I wouldn't bother with llGiveInventory, I would just put a copy of the object in its own inventory. As soon as it is sat on, I would have it rez another, phantom version of itself in place before it goes anywhere (which would already have the copy in inventory). That way, it will look as if it never leaves.

The new copy would look for the old one (I would probably use chat instead of a sensor), and when there are no other copies around, the new one would go non-phantom so it could be sat on. It would then remove the listen or sensor.

It all seems less flexible and more likely to break than having a separate permanent TP object, tho.
.

That's the point, though..it won't have anything in its inventory unless either you've put a copy inside the object (like Russian dolls) or unless you use llGiveInventory to put a copy of it into it after you've rezzed it. If you do the Russian doll method, eventually you're going to end up with an object that has nothing in it. Have a look at /54/0c/326115/1.html
I usually use a rezzer, too, as suggested by Jesse and Hewee. I'm wondering, though, about sitting on the object, having it rez a temporary copy of itself before it posjumps off.. and then have the permanent, mobile object, on its return, tell the copy to llDie() -- a sort of Potemkin object to give the visual effect that it never moves.

This for me. Its simpler I think. When rezzing the new chair, I pass a random channel to the chair to let it communicate back to the rezzer when it leaves so the rezzer can put another one out.

Yep. And you might want to have the rezzer announce it's rezzing something new on a channel as well, to let any defuct chairs know to delete themselves if they aren't being used (just in case the communication gets out of sync somehow or something). I'm always worrying about that kind of thing. Heh.

Even better. I hadn't thought of that. Can see how that would be very useful in a busy place. Cheers

caount me in the de coupling the rezzor from the sat upon object camp. and for even more fun have it rez a slightly larger invisible object than itself. when the invisible object is sat upon it sends a message to the rezzor and zips away, the rezzor recieving the message rezzes a new invisible mover.

you can do it with self replication if you REALLY want. the object should contain a copy of itself with all scripts included in the copy, when sat upon it rezes the copy, and gives the newly rezzed copy the object in it's inventory and then goes it's merry way.

Excellent ideas, I must say. I tried the original suggestion of having the object return to the original location, and was surprised how well that worked, I can't even see a flicker between it's leaving and return. I have not had a chance to try to implement the separating permanent object and moving object, however i think i will be, as for my purpose that seems like an optimal solution in order to have some things occur at the destination prior to dying, which would introduce delays with the return method that might not look as clean.

In any case I won't go the self-replication route. The idea of an invisible object slightly larger than perm object seems great, could have the perm object rezz that when it is rezzed (so it does not need to be a coalesced object), and the moving object message the perm object to rezz another in the on sit, as suggested.

Then add a sensor to the moving object to detect if a destination object is at that location already to know if it needs to rezz one or not before un-sitting and dying.

If the destination is less than 520m away from the origin, you can always use a llSitTarget TP. The object never moves, the avatar does.