UUID issue

Im trying to create a self producing object that rezzes a copy of itself and then dies. However I want to use the UUID of the object instead of the object name in the object rezzing script. Is this possible? And if so why can I not see the UUID when I rightclick on the object in my inventory - all I get is a bunch of zeros GRRR.

No.

See http://lslwiki.net/lslwiki/wakka.php?wakka=SelfReplication

Hi Ordinal, thanks for the reference, but I had studied Stefan's method for quite a bit last week, and in my own version wanted to avoid rezzing an object passing it a copy, rezzing a copy passing it a copy, and so on.

I understand that my own method initially was finite, and would end with no further objects rezzing, the last one dying on temp rezz, and my creation failing So I thought if one could use the UUID instead, the finite nature could be changed to an infinite rezzing process.

It seems that this is not possible, so I will be forced to take Stefan's approach instead.

An object will get a new UUID each time it is rezzed in world, so the un rezzed object has no UUID.
At least that is my understanding.

Right. There is no useful reason to get the UUID of an object in inventory. Also, you can only rez an object from script that is present in your prim's inventory (the same prim that contains your script).

Thanks Dora and Hewee, you are quite right. I found out the hard way, but lesson learnt and remembered .

I have in part used the self replication method shown in the lsl wiki, and now am only playing with the direction the object drops when it turns physical Physics is a whole new kettle of fish! May be back here soon to ask for more advice!

Objects in inventory have UUIDs too. Inventory is just metadata that associates a name/owner/permission with the UUID of an asset in the asset server. You must use an inventory name to rez an object, instead of the asset UUID, because that is the only way the sim can know if you have permission to rez the object. The asset server has no idea who has permission to rez. There is no way in LSL to do anything with the asset UUID.

Your understanding is wrong. Objects in the inventory have an asset uuid, from which an instance is rezzed. You cannot right click and 'copy uuid' of an object though. Just remember, whenever you get the idea that some asset doesn't have a uuid key, you're wrong.

Don't understand your "finite" problem. I have built towers 4000 meters tall using self replication, rezzing one 10 meter tall cylinder at a time. Are you running out of objects to rez or are you actually running into the grey goo fence? The anti-griefer algorithm is pretty intelligent and will recognise this as an attack and will kill the scripts. It helps some if you add in a llSleep period to throttle back how fast the objects are rezzed. Even then once you get to an undetermined amount of rezzes in an unqualified amount of time, the fence is going to kick in.

Sorry I am not more specific but Kelly won't release the specs for the algorithm for obvious reasons, so that leaves us with trial and error.

Bit of a tangent but is this _really_ true? I know the inventory loss form letter LL sends out asks for the exact name of the item lost - does it help them to have the UUID?

What do I care about any asset UUID? Of course the asset server must have some way to identify assets. From a LSL scripter's point of view it might as well not exist.

Sound and Texture UUIDs are very useful since they provide a way to use an asset from script, without including the asset. The other UUIDs aren't really useful, no.

currently rezzed object UUIDs are useful for llemail as well

But that is an Instance Key, which is newly-generated each time an object is rezzed, not an Asset Key.

Hi everyone, my apologies, RL was so nuts I am only now catching up with my threads. My responses to all your wonderful assistance coming right up:

UUID - I got to know UUID's with texture scripts I was playing with, and thought possibly there was a way to do the same with objects not yet rezzed, but silly me, I completely forgot several frustrations with UUID's for objects changing during a little exploration into the world of 'holodeck scripts' last year So I wholly agree that this is not possible to use since they change each time you rezz from inv. However, I did not know that there is something like an instance key. It would have been great if UUID's for objects really existed as permanent references, but I have since managed to fix my rezzing problem that was the cause of this thread.


FINITE - I had used:
<CODE>rotation rot = llGetRot();

llRezAtRoot("fruit", llGetPos() + <0.0,0.0,0.0>, <0.0,0.0,0.0>, rot, 10);
</CODE>
I had not realized that I has set the rezzing count to a maximum of 10 by doing so. Hence a finite number of replications happened and the object died.


I am completing a better edited version of the scripts I am using and will paste them right here by this evening. I wanted to sell the object with scripts to help fund Bishara Resorts as the strain of supporting 6 sims, with 4 pretty much directly paid tiers, is too tough on me since the nice little 40% drop in price of new islands from LL pretty much took me out as a viable land baron .

However, with little help from the texturing forum groups, I decided someone else would make the actual tree objects so much better than I, hence my putting the current scripts here as soon as I have cleaned them up a bit .

Also I know from some threads here that sometimes ppl blanket comment on 'scripters' in-world charging huge fees, not helping new residents, and so on and so on, and partly that may be true, but I wanted to personally thank you all who have selflessly helped me everytime I have asked a question. None of the other forum posting groups work anywhere as diligently helping new participants as you all do. Kudos!!!

Hi everyone, as promised, please find my beta or very much alpha version of the fruit tree scripts at /54/5c/263726/1.html

Thanking you all in advance for any advice and admonishments

O, and right now the fruit, when physical, drop with the usual SL gusto! So I expect there may be a better way to produce this effect.