no names displayed when someone attenpting to use rlv on your collar

[demonseed76]

What version of OpenCollar are you using? 7.3 What behavior did you expect? names wo the person trying to control rlv What behavior did you see instead? lots of question marks What steps does someone need to take to reproduce the problem? wear collar and have someone rlv you to a device

https://gyazo.com/cdc3bd4429ee7d70661a4f3985498078

I have a new collar with 7.3, I have notice several times now when the colar is attempting to accessed by an rlv device I do not get names displayed, only question marks, see link.

[mistressohm]

What restrictions are already imposed by the collar, or by another RLV relay device? Are you in Daze mode (where names and locations are hidden)?

What viewer are you using? What are your settings in regards to "object spoofing"? Firestorm has this setting in Preferences | Chat:

• Mark objects with (no name) when they speak to avoid spoofing: This allows object names in chat to be clicked, so that you can get information about them (creator, owner, etc). Useful in griefing situations.

What is the SLURL of this particular RLV device, so that someone can attempt to recreate the same event?

[mistressohm]

Looking into oc_relay.lsl, the prompt above is driven by this code:

_string sOwner=NameURI(llGetOwnerKey(kCurID)) ;
string sPrompt="\n"+llKey2Name(kCurID)+", owned by "+sOwner+" wants to control your viewer.";_

The function llGetOwnerKey is supposed to return the owner of any item (attachment, rezzed object, or avatar) in SL. However, it returns null if the key provided is invalid. I would expect to see "???" or "(null)" in the dialog if this is the case. A quick way to check is to right-click on the trap, or furnishings, and Edit - the General tab should tell you who placed the item, whether it is deeded to a group, etc.

[zontreck]

Unfortunately this happens in other relays too. Aside from initiating the confirmation prompt from a dataserver event and requesting the name,etc,etc. There's not much we can do. This is a limitation of Second Life. Something we can look at I suppose is whether the source of kCurID is valid. If kCurID is not equal to the actual object then that is a quick fix, but if it is equal to it, this code realistically should be working..

This code becomes more unreliable when the owner of the object is not on the sim. There are also similarly limitations with the llKey2Name function, and llGetObjectDetails would be more reliable in this instance. But that only solves the object name not showing up. We could potentially also use llGetObjectDetails to more reliably get the object owner key, if it is returning NULL_KEY.