Infinite Nesting

I saw an object today, that gave out a copy of itself, which was capable of giving out a copy of itself, which was capable of giving out a copy of itself.....

How on earth would you do that? I can't figure it out.

The copy you put into the item wouldn't have a copy capable of giving a copy unless it already had a copy inside, but that copy wouldn't have a copy inside unless... <brain breaks>



It was a Linden-made item, do you think they did some Inventory jiggery to make it happen?

read this carefully: http://www.lslwiki.net/lslwiki/wakka.php?wakka=SelfReplication

Hmm interesting, but not the same as what I observed. The wiki page talks of rezzing an item and then giving the rezzed item a copy of itself.

However this item literally gave me a copy of itself directly, without rezzing. So it wouldn't have the opportunity to give this copy a copy itself. And indeed this copy I received has a copy inside which can give copies, ad nauseum.

I guess I'll have to assume LL somehow placed a copy of the asset inside the asset by direct database manipulation.

I think you're missing the implication of giving the rezzed item an *exact* copy of itself...

The item doing the rezzing initially need not be the same as the item being rezzed. It just helps accomplish the task.

.

Rez it in no-script land and start disassembling it?

And you would be wrong. LSL placed a copy of the asset inside the asset by self replication. Really, really, this is what it is.

And you would be wrong. LSL placed a copy of the asset inside the asset by self replication. Really, really, really, this is what it is.

Ok, I thought about it some more, and I think I understand now. Because the copy inside is a copy of the container, the container now has a copy inside, It just twists my brain.

Cute comic

No, I agree. This is not self-replication. There is no opportunity for the function llGiveInventory() to be called with a new copy of the object as the recipient. If the object were rezzed to do this, it could not then be given to a resident without manual intervention.

It might very well be that the object containment hierarchy is simply so deep that it will be very difficult to get to the last generation of given objects though. Maybe it was created with the whole "six degrees of separation" premise or something.

EDIT: Never mind, just gonna be easier to make a test bed script tonight.

Self-reference and the ability to create self-enclosing constructions in the database is something I miss from previous virtual worlds.

'Free for everyone to copy' does exactly that

Right, I'm just trying to work out how LL did this. It's new and I can't quite figure it out, and on the rare occasions I find something like that, I'm intent on getting to the bottom of it.

My current theory is to place the object in an object that gives it out, and then gives a copy to the copy rezzed, and then see if taking that object results in a self-referencing object. I'll probably try that tonight. I don't see any other way at the moment that could possibly work, but somehow it still doesn't feel right.

I'm also going to modify the item, then see if the items it gives out also contain the modification. If so, then it has to be a true self reference, not deep nesting.

The item is the Hoverboard 2009 freebie you can get in Zindra in case anyone wondered.

Yes, if the object was set to purchasable, either as a copy or original, or set so the resident could grab a copy from in-world (already rezzed), then it would work (self replication or not). If it is an actual inventory give, I ain't buyin' it.

I'll send you one in-world, the script is set to only give to people who don't own it, so you can use an alt to test. (or try modifying the script, it's full perms, but i don't know if modifying it will modify the copy inside yet ).

I understand your doubt, that's why I'm so interested in it. It's puzzling.

Darien,

Please pass one over my way also if you have a chance. I was gonna start poking with some code test beds tonight anyway.

Thanks for the copy Darien. As I suspected, there is a finite number of nestings. As of the one you gave me, there are seven generations left before it will be unable to give itself away.

Cool! So that answered the mystery.

So it started at least 8 deep. If each person gives away an average of 10 copies, I think that's enough that everyone in SL can get one including the bots.

Ahh, interesting. I don't know what generation the one I received was, i found it floating in Zindra. But I assume it has to be close to the start. Drat, I was looking forward to picking at it, but Thanks for finding the answer anyway.

Sent everyone a copy just for the fun of it anyway.

There's no real obstacle to infinite nesting. The grey goo fence doesn't seem to kick in if you rely on each object pushing out only one new object at a time even if it's at the maximum rate (3 seconds) the delay will allow and if you're smart about it you get to the point where you have enough rezzers that it doesn't matter. area select, shift click, drag is your friend in that regard.

Erm. Note, Gordon, that this thread is NOT about self-replication; especially destructive self-replication. It was suggested that self-replication may have been the means by which the behavior in question was brought about, but that is not so. The thread is about the ability for an object to give a 100% faithful copy of itself to another resident (one that can then give itself to other residents in turn upon request).

Reading back after I commented I noticed that and actually came back here to edit my post but you replied before I could. It should be noted that the two are very closely related. The simple steps to infinite nesting.

Create object A
Put rezzing script into object A
Take a copy of object A to inventory -> that will now be object B
Put your new object B inside of object A
Take a copy of Object A to inventory -> this will be object C
Delete object C from object A and replace with object C

You can place touches and menus into that and code all sorts of tricks into it and to prevent it getting out of control I'd suggest making it only work on trigger but in theory that idea should give you something that can give out a fresh copy of itself when whatever touch or other event you set it up for is activated with no problems.