llGiveMyself

Would be *extremely* useful for an object to be able to give a copy of itself to another object. In the case where that object is NoCopy, it will give itself and no longer exist as a rezed entity.

Two key uses:

- rezing systems. Just add the rez slave script to each prim, then get a master rezer to ask each slave script to provide it with:
--- coordinates and rotation
--- a copy of itself

- boxes of items that are rezed on demand. Rather than requiring that the objects are copyable, and creating a new copy on each demand each time, you really could put the items back in the "box"! Would help a lot with permissions nightm^H^H^H^H^H^H technical issues, and also has a lot of advantages for script version control on largish projects.

Azelda

Yes PLEASE! This will be so useful for automaticly updating rezzers.

Plus, I cant see any additional security issues from this then what is created by llGiveInventory.

==Chris

You can do this with llgiveinventory... i've done it back in 1.1~1.2

No, Nexus. You can't. "But you can copy the object to your inventory then drag that copy into the inventory of the object!" Yes, but that's not the point.

Try making a rez system for upwards of 50 prims and you will see what I mean.

Or, try making a gun where you dont have to give copy permissions to the buyer for the bullet.

Azelda

Right, you cant. llGiveSelf(key) gives the object currently executing the script with the command to the key specified, no inventory item required. In the case with llGiveInventory, you have to actually have a copy of yourself in your inventory to give yourself. (And in all cases, that's not possible, one excellant use of llGiveSelf would be to have totally dynamic rezzing systems, where you can simply move around prims and shout a keyword, perhaps "save state" that will automatically save the way the prims are aligned.)

==Chris

Just a note on a personal *theory* of mine, and a statement based on that theory.

Theory:

The reason why the world isn't overrun with self replicating objects on a regular basis is because it takes a little bit of cleverness to figure out how to get around the recursion problem. Based on my experience with questions I've been asked, the solution that we already know (and therefore seems obvious to us) is not obvious to a large number of residents.

Statement:

This function *may* cause self-replicating objects to be more ubiquitous.

Well, I agree that my own personal rule of thumb for avoiding self-replication is not to rez object A from object A, and this implies not to put object A inside object A.

In practice my own requirements for llGiveMyself all entail giving object A to an object !A, so there's no problem there.

I'd have no problem with making llGiveMyself not work if you attempt to give the object to itself. I think such a limitation would address the bulk of your concerns Kex?

Azelda

Appendix: A really core reason for needing llGiveMyself: script version updating

Let's say I have a system with 32 objects each containing 5 scripts.

I could update new versions of each script by hand, but that would take me a long time, especially if there are regular version releases (there are, tons, since the system is in development).

Thankfully we dont have to do that any more: we have llRemoteScriptLoad (thank-you Lindens!)

However, my next problem, an order of magnitude less hastel it is true, but still a problem is: these objects are actually embedded in another object, a game box if you like.

So, in order to update the scripts, I need to rez each object, run the remotescriptload, then take the objects back into my inventory, delete the old ones, then delete the old objects from the box (scriptable), then drop the new objects into the gamebox.... that's actually a lot of work, especially for frequent upgrades.

It would be *much* easier to get the box to rez its contents using a script, then bulkload to the subobjects, then get the subobjects to llGiveMyself themselves back to the box (which cleaned itself during the bulkload).

And looking to the future, in the case where the MMOGToolkit actually gets into prod, this problem wont apply just to one site and one object, but to every monster rez point in every location using the toolkit.

Its not quite as automated but there is a feature that you can use in the UI for some of those last steps:
Tools -> Save Object Back to Object Contents

What this does, is if you rezed object B from the contents of object A, then you messed with object B, you can select object B and choose the above option from the tools menu. Then all your changes to object B are automatically saved back to object A (replacing the existing object B in there).

A note of warning: it does NOT work with shift clicking multiple objects from As inventory. ie if you rez Obj. B,C and D then shift select them all and choose this option it will not do what you want.

SO??

There's no reason to cripple a functionality just because of how it may be used for griefing.

There may be many other reasons for doing an llGiveSelf(llGetKey()) other then for griefing things.

We already have something with this kind of volitity in the language, llPushObject, and we see how the crippling of this function's abilities has killed most of its usefulness.

==Chris

There are a few problems with this UI tool. One espicialy peeves me, is that it does *not* give any confirmation that the save failed. Sort of like how linking used to silently fail in the old days :hivers::.

Plus, it only works if you drag the object directly out of the other object's inventory. If the object was rezzed using llRezObject, this tool will not work.

Ok, call me an idiot, but how is this different from an object containing a copy of itself, and giving it to other objects?
Isn't the "cleverness" behind self-replicating objects that whenever one is born, it just screams to its nearest cousin "waah, i want a copy of myself too!" ?
I did like the bit about the nocopy objects though. Makes me miss the old days when everything was copyable by default and it was almost insulting for people to set permissions on an item.

Idiot!!!

Mainly, llGiveSelf makes rezzing systems more able to handle dynamic objects.

Ill give you some examples:

1:
You want to create a rezzing system that auto-rezzes your lab. Your lab is *not* static; you're constantly updating and adding scripts to the objects that make up the walls and other decor. You also like to move things around a bit, change the position of your sofa or test tube for a new project perhaps.

Now, what happens when you derez and rerez your lab from the copy in the rezzor?

It doesnt have the new and updated scripts or positions. For your lab to remain constantly updated, you would have to re-save a copy of your lab in the rezzor every time you made a change. This is an amazingly time consuming process, since the UI tool doesnt help much (see its limitations in my post above).

With llGiveSelf, you could have each piece of your lab update itself in the rezzor as you play with it. This way, your lab constantly remains updated, no matter the number of places you move the sofa.

2:
Azelda gave a good example in her message, where a scripted object A, in object B's inventory, needs to be rezzed, updated and given back to object B. Currently, there is no way to do that last step of giving back the newly updated object A.

3:
This would work wonders for the ALife community. Making llGiveSelf possible, allows people to make dynamically mutating objects that dont rely completely on their scripts to provide genetic morphing.

Ill think of more

==Chris

Oh. I misunderstood it then.
So what you're saying is that you want an llReturnAnUpdatedCopyOfMyselfBackIntoMyParentObjectsInventory

lol
Not exactly, it really has nothing to do with parent objects.

llPutMyselfInObjectInventory(key destination)

This could be usefull, I endorse this feature/idea.

I like it *support*

BUMP!

BUMP! Me and Eggy just found *another* use for something like this, saving script state! With this function, people can "save a copy" of the stuff in a scripts memory and retrieve it later.

I want this so badly!
==Chris

Yes, I definitely, definitely, D E F I N I T E L Y could use this function as Christopher Omega suggests it. Actually, I thought this function DID exist until today - I was working on my pet script, which makes said pet follow me, dance, ect, blah blah...

Anyways, I want to make it so that if people who buy this object get it caught or stuck anywhere, and it no longer senses it's owner to follow, it begins counting and eventually returns itself to it's owner's inventory...

I'm trying to be a responsible coder and make an item I'm selling go back to it's owner's inventory unstead of sitting there lost, taking up prims on someone else's land, to later HOPEFULLY be returned, or <gulp> deleted.

...and, unfortunately, since there is no llReturnObject, the only way I can ensure paying customers don't lose their pet it to make the object copy/no transfer?!? (which, means they'll just lose it again and junk up the world with them more)

...oh, wait... or annoy the hell out of the owner by IM'ing them it's position until they go back within sensor range?

BUMP to this old request thread.

We don't seem to have got this, and I really need it for a significant project. So do lots of other people, it seems. And I DONT need it for self replication - I got that working anyway a long time ago.

Please, Lindens. This was requested so long ago - can we at least have a response guys ?

Unless its been done and I can't find it ?

Perhaps I should be a bit more specific, in case some kind person can point out there's another way of doing it, and to support the request more clearly.

In an entirely script-driven process, I want to modify an object (B) currently in the inventory of another object (A). I propose to rezz B, talk to it, get it to remember what it was told, then put it back into object A's inventory. As far as I can see, the last step is impossible without the involvement of an agent. There may (of course) be a lot of objects B.

well, since we've now all been told how to make self replicating objects ... why not just add llGiveSelf and be done with it .

I endorse this feature/suggestion

McW

So if you wish to vote to support this feature, you might like to go to
www.secondlife.com/vote
and vote for proposition 111.

considering your post is 2 years old you'll probably never read this but maybe someone else will get some use out of this answer

here's my "simple" dillema...

you want to sell someone object a
you want them to be able to sell object a and give you a cut evertime they do
you want them to not have copy perms because that would reduce commissions
so you put a copy of object a in object a
then when you sell them object a, they get the copy
problem is that the copy doesn't have a copy of object a in it
even if you put a copy of object a inside the copy of object a
the person who tries to resell object a can only sell to buyers not to resellers
because the copy of the copy of object a that was inside the copy of object a that was inside object a is empty
so you can sit there putting copies of copies of copies inside of copies of copies of copies of copies all day but eventually, somewhere down the line someone will get an empty object a
at this point you pull out your hair, scream and jump out the window
at least I did
I can't think of a way to do this without a vending server
which is more research and hassle that I wouldn't need if I coul just use a llCopySelf() command

ech