Infinite Nesting

I tried it twice, but it just gave me two levels of nested objects. C rezzed B, B rezzed A, and A gave an error cause it had nothing inside.

I may very well have made a mistake on that. As I said I haven't had to do that in awhile. It's too late to try tonight but tommorow morning I'll give it another try.

You know there is an easier way of doing this.

Have a server, and clients. You click the client, it contacts the server and the server gives you a client. Anyone who clicks your client, it does the same thing. Gives the appearance of self replication. You could even put a client in the client's inventory to confuse people.

Assuming you mean, "... and so on", that's not infinite nesting. It's "arbitrarily high" nesting. There's a very big difference in theory, though not much difference in practice, if you go deep enough. You'd have to make sure all nesting levels of the object stay rezzed or in avatar inventory, though, or they'd eventually be deleted from servers by garbage collection.

If you don't mean "and so on", then this only goes 2 levels deep (or 3, depending on how you count). I made a balloon that contained a copy of "itself" 2 levels deep like this: if you click on a balloon, it bursts and releases 5 copies, each of which can also burst and release 5 empty copies, using precisely your method above. Fun way to slow a sim down during a party! but not for long since they're all temp on rez. I've made other objects that contain objects that contain objects (e.g., a tossable wedding garter and bouquet). A friggin nuisance to update, these toys! But it's just bookkeeping.

The only way I know of to do replication in SL takes two objects on each replication, as discussed in the wiki page mentioned above. Of course, the object, when rezzed, could rez what's inside (an empty copy of itself), and give that object the same item to take into inventory, and then delete itself. The owner may not even notice, except that "take" wouldn't put it back in the same folder. That gives the effect of self-replication ... almost. You'd lose changes to the object name in inventory, and there may be other oddities.

How can a server give inventory to an object that's not in the same region?

The wiki for llGiveInventory() says "If destination is an object then it must be in the same region."

slightly simpler version of Gordon's instructions (because I like minimalist instructions)

create object A
drop in a script that rezzes the copy and gives all inventory to that copy.
take a copy to inventory, then drop it in the original
done.

the relevant script looks something like....

default{
  touch_start( integer vInt ){
    llRezAtRoot( llGetObjectName(), llGetPos() + < 1.0, 0.0, 0.0 >, ZERO_VECTOR, ZERO_ROTATION, 0 );
  }

  object_rez( key vKeyTgt ){
    llGiveInventory( vKeyTgt, llGetObjectName() );
  }
}

the server method works for items that are given directly to the av, either the object can request a copy from the server when it rezzes, to give directly to the av, or it can just pass the request to to the server which sends the item directly to the av. (I'm guessing something like the first case occurs with OP's item)

Should the last line read "Delete object B"?

It does not seem that Object C would be in Object A's contents.

Should the last line read "Delete object B"?

It does not seem that Object C would be in Object A's contents.

Should the last line read "Delete object B"?

It does not seem that Object C would be in Object A's contents.

Should the last line read "Delete object B"?

It does not seem that Object C would be in Object A's contents.

it'd be enough at only a 2 deep if the inventories are copiable (in which case only the sub copies lose ability), the originals and first levels will still be giving out fully loaded versions =X

Although prloading does give me some ideas for limited use items that I hadn't considered before...instead of doing it by script... the physical nesting may actually be more secure than can be done by script.

now to come up with a delivery system....

I have a question about a previoius post in this thread.

Gordon says in a post above:




Should the last line in the above quoted passage read "Delete object B" instead of "Delete object C"?

It does not seem to me that Object C would be in Object A's contents after following the first four steps, and hence could not be deleted from Object A.

minor typographical error, just use my instructions, so much simpler, and you end up at the same place... infinite recursion.