Jump to content

llKey2Name(llGetOwner()) returns empty string!


You are about to reply to a thread that has been inactive for 3703 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

From the LSL wiki:

• key id avatar or prim UUID that is in the same region

id must specify a valid rezzed prim or avatar key, present in or otherwise known to the sim in which the script is running, otherwise an empty string is returned. In the case of an avatar, this function will still return a valid name if the avatar is a child agent of the sim (i.e., in an adjacent sim, but presently able to see into the one the script is in), or for a short period after the avatar leaves the sim (specifically, when the client completely disconnects from the sim, either as a main or child agent).

  • Like 1
Link to post
Share on other sites

Okay, I have on_rez doing an llResetScript( ), and default's state_entry then captures the current owner's name
from the llKey2Name(llGetOwner( ) ) method.

Assuming that to transfer ownership the object has to be taken into inventory, and then rezzed again, the owner should never change in-world (without re-rezzing), except:

1. owner account closed - what should I do here?

2. I want the vendor to be copy + transfer + noMod, but not sold - how do I set those perms?

 

Link to post
Share on other sites

 


Domitan Redenblack wrote:

Okay, I have on_rez doing an llResetScript, and this then captures the current owner's name from the llGetOwner key.

Assuming that to transfer ownership the object has to be taken into inventory, and then rezzed again, the owner should never change in-world (without re-rezzing), except:

1. owner account closed - what should I do here?

 

Nothing you can do there unless you plan on running something that checks whether an account is still in the database, why would you want this feature?


Domitan Redenblack wrote:

2. I want the vendor to be copy + transfer + noMod, but not sold - how do I set those perms?

 

Right click your object and near the bottom you should see "Next owner permissions" you can set it to copy + transfer there.

 

Link to post
Share on other sites

 


Domitan Redenblack wrote:

Ciaran Laval wrote: Right click your object and near the bottom you should see "Next owner permissions" you can set it to copy + transfer there.

Thanks, but does "Next Owner Permissions" also apply to the scripts and notecards inside the vendor? Are they protected?

 

Ah well it's just the prim, you can right click on the individual items in the contents tab of the prim inventory and set their perms there too, I always do this just for peace of mind to make sure everything is set how I want, and then transfer it to an alt to check again!

 

Link to post
Share on other sites

owners of items inworld do no change if their accounts are closed. so I wouldn't worry about that.

if an item has transfer permissions, it can be sold... period... there is no way to prevent that.

 

PS
just because an item is rezzed, doesn't mean that key to name will return a valid name... if the object is rezzed by script the owner does not need to be around... instead use llReqestAgentData, which needs to go through the dataserver event if you absolutely must have a name (otherwise the key is just fine if you are only comparing it for changes). alternatively you could just link to the presons profile with secondlife:///app/agent/<key>/about

Link to post
Share on other sites

Very interesting, Void, thanks.

I would not expect this vendor to ever be rezzed by a script; is that likely?

These vendors will be given by my staff to parcel owners to place into their shops etc. Those parcel owners may make copies to put in their other shops, or to friends for their shops, etc.

If never rezzed by a script, then is state_entry > llGetOwner( ) sufficient?

If you can't stop an item being sold, perhaps I should note "Free copy and transfer ONLY" in a startup message?

 

 

Link to post
Share on other sites

Domitan Redenblack asked:

"If you can't stop an item being sold, perhaps I should note "Free copy and transfer ONLY" in a startup message?"

A more effective tactic, perhaps, might be to code something like

 

changed (integer change){    if(change&CHANGED_OWNER)    {        llOwnerSay("If you just paid for this item, you were robbed. You can get one free from Domitan Redenblack.");    }}

 :smileyvery-happy:

 

Link to post
Share on other sites

if you don't actually need the name, and just the key to compare, then it doesn't matter how they rez it...

 

is it likey that someone would rez it by script? probably not, but if it's information you are going to depend on, you want to be sure (and if there's any reason a person might want to cheat it, someone will)

Link to post
Share on other sites

 


Void Singer wrote:

if you don't actually need the name, and just the key to compare, then it doesn't matter how they rez it...

 

is it likey that someone would rez it by script? probably not, but if it's information you are going to depend on, you want to be sure (and if there's any reason a person might want to cheat it, someone will)

 

Thanks, I record the name of the new owner of the vendor board into a MySQL database, along with the region and parcel and location etc. I can't honestly see any advantage into not having your name there; when the board vends something, they will get paid and there will be a record etc.

:smileywink:

Link to post
Share on other sites

When you send data using llHTTPRequest() the owner's name and key (and the object's name and key) are automatically included in the headers SL sends.  Which means there's no need for you to include it in the body of your message and, in turn, that you probably don't need to record it in your script.

http://wiki.secondlife.com/wiki/LlHTTPRequest

Link to post
Share on other sites

 


Void Singer wrote:

owners of items inworld do no change if their accounts are closed. so I wouldn't worry about that.

I had a free item from Arcadia...oh, what was her full name... anyway, she closed her account a couple of years ago. For a while her name held as owner. Then for a year or so, some of the linked prims in the set took on some random names. Sometimes it was a friend of mine, other times people I never heard of. Then after about a year, the name changed to "unknown" and has stuck that way. It was kind of sad, I heard she was a legacy.

 

Link to post
Share on other sites

 


PeterCanessa Oh wrote:

When you send data using llHTTPRequest() the owner's name and key (and the object's name and key) are automatically included in the headers SL sends.  Which means there's no need for you to include it in the body of your message and, in turn, that you probably don't need to record it in your script.


I didn't realise this! Not that I've done much with using a webserver but I did play around a little with getting the owner name and key in the body and felt it would be too easy to fake, having it in the header has piqued my interest again in that little project.

 

Link to post
Share on other sites

Unfortunately ALL web-traffic is easy to fake, unless you check that the IP-address the request is coming from really is a Linden server. (Any old program can send a web-request with any headers it likes, including faking the SL ones).

On the other hand the major volume of traffic in my current project doesn't have to send any information at all, everything I want - object & owner names, co-ordinates, region name and corner - are all in the automatic headers!

Link to post
Share on other sites

 


Paladin Pinion wrote:


Void Singer wrote:

owners of items inworld do no change if their accounts are closed. so I wouldn't worry about that.

I had a free item from Arcadia...oh, what was her full name... anyway, she closed her account a couple of years ago. For a while her name held as owner. Then for a year or so, some of the linked prims in the set took on some random names. Sometimes it was a friend of mine, other times people I never heard of. Then after about a year, the name changed to "unknown" and has stuck that way. It was kind of sad, I heard she was a legacy.

I knew about the display changing (it used to happen with the old method of account removal, and you'd see it when LL swatted a griefer account sometimes) but I thought they had fixed that.... coming up "unknown" might actually be a good thing by comparison... but slightly troubling.

 

Link to post
Share on other sites


Void Singer wrote:

there's been reports of infrequent bad data in the name metadata.... mostly just after region changes... sometimes comming up blank, or "(loading...)". so be careful with it.

Ah yes, there is that.  I have seen "(loading...)" for owner name & key, and position data while the avatar is not properly 'present' in a new sim.  For my purposes I can just ignore those records, in other cases requesting a re-send should be enough to give the sim time to get itself together.  Presumably the usual llFunctions for getting name & position simply don't run until the sim is ready - or at least they don't return until then.

Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 3703 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...