llDetectedCreator()

Returns the creator of the object.

Aww c'mon why not.

I like this idea, but would rather see an llGetCreatorKey(key id) that works like the llGetOwnerKey function we currently have. That way, we can find out the creator of any object *and* inventory item all wrapped up in one neat little package.

We've been asking for that for AGES! the llGetCreatorKey() BUT until the creator names and key can be fixed in object (the <none> I don't think we will see this!

I endorse this idea/feature. (and the fixing of the creator/owner = none)

What about llSetOwner() and llSetCreator()? *ducks*

Xylor

Well, get c reator would be specific to the object that calls the function...I'm not sure I see this as being as valuable...having an object tell you who created it would be uselss if the creator owns the object, and only partically useful if somebody else owned it. The object will always be created by you...what's the point of having the object tell the new owner that, or know it internally?

Detected means you could, for example, give out a gun, with bullets you created. You could script your objects to simply recognize the name of a bullet, coupled with the match up of the craetor (so, if the bullet is named "My Bullet", AND the bullet was created by me, do the damage). This would immediately eliminate a great deal of spoofing hacks, and all the shouting bullets need to do. I don't see getcreator solving this without shouting.

Somebody mentioned encryption to deal with spoofing...I considered it of course, but am dubious, since I'm willing to bet the encryption calls will be slow.

Well, llGetCreator would, but not llGetCreatorKey.

With llGetCreatorKey(key id) you could wrap an llDetectedCreator, llGetCreator, and llGetInventoryCreator(int n) into one function:

llGetCreatorKey(llDetectedKey(int)); // Gets the creator of the specified detected key.
llGetCreatorKey(llGetKey()); // Gets the object's creator.
llGetCreatorKey(llGetInventoryKey(int)); // Gets the creator of the specified inventory item.

Im suprised why LL hasnt taken this route with llGetOwnerKey, there's A TON (IMHO) of wasted function-space and maintenance time with current stuff.

These functions can be depricated:
llGetOwner, replaced with llGetOwnerKey(llGetKey());
llDetectedOwner, replaced with llGetOwnerKey(llDetectedKey(int));

It's called encapsulation LL
Hehe

Oh, and another rant:
llGetCreatorKey(key) and llGetOwnerKey(key) are horrible names ^_^

Id prefer llGetOwnerFor(key) and llGetCreatorFor(key).

Yipes, went off topic! Sorry!

==Chris

::throws a heat-seaking tomato at Xylor::

Yes, there should have been a whole suite of functions to get information based on a key. That there aren't such functions makes me think there is some technical reason. I mean, it's the obvious way to write the language, isn't it? Get a key, whether from an event like listen or a llDetectedKey call, and then psas it to a suite of info functions.

Oh, and even llGetCreator() would be handy if it only returns the creator of the prim the script is in. A No-mod script could make sure it's in a prim created by you, or cease to run. It would be a way to prevent someone from stealing a vehicle script, for example, because you made the vehicle's prims modifiable to permit customization. They couldn't rip out the script and slap it in their own car and sell it.

But, as I said above, passing keys to info functions is THE way to go in ALL cases. It's the most versatile.

Me too please!

Yeah, you could actually give the bullets names like:

BULLET DAMAGE=10 TYPE=STUN

Of course, if you've ever given a mod copy copy of any of your objects to anyone ever, they can make a ton of copies with names like:

BULLET DAMAGE=100 TYPE=ULTRADEATH

Back on-topic, personally, I think that LSL should be able to do anything an avatar can do, and also not have to go via sensor events all the time.

llGetScale( key )
llGetOwner( key )
llDeleteObject( key )

and why stop there, things like:

llMoveObject( key, vTargetPos )
llReturnObject( key )

I'd assume there's some sortof API somewhere that the SL client plugs into somehow; it shouldnt be difficult to just build the LSL wrappers to plug into the same API functions?

Azelda

Yay, at last... a bullet with your name on it...

What I really want it to do is take an item dropped into inventory, check the name and also that I made it. If both things are a match then handover the new version to the avatar who dropped the old one. As it is now, anyone can make an item of the same name and pass it into the updater... which will hand that anyone a copy of the new wares. Is there some other way to check?

Sortof off-topic to the thread, but...

You can do this; you'd need to have an upgrade script builtin to the original object.

The player would place the object on the upgrade machine.

The upgrade script would detect teh collision with the upgrade machine, or its presence, or hear it whispering "UPGRADE!" on a special channel.

It would authenticate to the upgrade machine by sending an authentication code on a secret channel.

The upgrade machine would confirm and request the old object to kill itself.

The old object would send a final handshake confirmation to the upgrade machine and promptly die.

At this point the upgrade machine would GiveInventory the new version to the owner of the old device.

There are doubtless other ways to do this too, but this is one possibility that stands a good chance of working 99% of the time.

Azelda

Yeah I'd like to see this too...

This sounds like an excellent idea to me. Might need some restrictions on it though.

*jaw drops*

Thread necromancy.

The suggestions aren't bad ones.