When conquering a station, if you select "Create a new key..." the newly created key will have problems.

* If the new key is given to anyone, before performing a logout/in, the key will be inactive for the recipient until they logout.
* If you rename the new key, before performing a logout/in, it will be renamed but then marked as inactive until you logout.
* If you give the previously renamed and inactive key to someone it will still be inactive until they logout.

That's the extent of my tests performed thus far.

* Sometimes when you add a new person to a user key the IFF and dock options reset to off.

The key system is pathetic, and combined with the tempkos bug where conq stations shoot you if you are tempkos ANYWHERE makes conq stations so extremely broken that people are making boring in-game political choices just to avoid using the content.

It is the biggest end-game gameplay problem in Vendetta online, even more important than tridents.

We (PCC and plugin authors) don't even have the necessary APIs to work around the key system's shortcomings with plugins either. :(

Regarding the key's inactive state, does it actually affect the usage of the key or is it purely a visual UI error?

I found why the key is not considered active, but it won't affect the actual usage of the key, and the key's active state can be viewed by looking at the Info for the key and seeing its Access Rights.

It did appear that the key would still function for the purposes of docking. I suppose the larger issue is one of accessibility for handicapped players who have difficulty differentiating between the icons for an Active and Inactive key and identifying active/inactive keys via the Lua API for plugins.

The API aspect is frustrating because the station/userlist information is not updated everytime the GetKeyInfo() function is called, which results in it being necessary to open the KeyInfoDialog in order to refresh the key data so that they can be properly identified.

I don't understand how the active/inactive images are that hard to differentiate. The inactive ones have black lines on them and the active keys have glowing blue lines.
I know the lines don't glow enough though. But having the check did help a bunch.

Anyways, I'm working on a fix for the active/inactive problem, but it's not in production yet. It's a server-side issue where they keys weren't marked as active.

I don't know about the problem that TRS reports above, though. 'Sometimes' is hard to reproduce.

Thanks ray.

Regarding the issue of differentiating the icons, I just know that at least one person has complained about not being able to see the difference.

Hmm, that's the opposite of what the code looks like it does.
User key inherits the active state of its owner key, so it would look like it's not active, but the active state has only been a visual state.
I'll test the IFF/Dock states of user keys to see if they can ever be other than what they're supposed to be.
Is this when an existing key is selected as the access key for conq-stations? Or is it also happening when a new owner key is created?

My original bug report only pertains to new keys. I haven't tested if there are any problems with existing keys, at this point in time.

Existing keys would have the same problem.

As for iff and dock being reset, when the station is captured, the user key settings are reset to unchecked.

The active state of keys are updated on the client as they change but the settings have to be queried through either the UI or the function that the UI calls.
Keychain.list(keyid, cb)
Hm, the callback isn't called when the result is returned from the server though. It always sends a KEYINFO_DIALOG event, which causes the key info dialog to open.
I'll have to change that.

How hard would it be to make user key settings default to checked?

I've had it uncheck them when it gives me a new user key after I had the owner key and add someone to the corresponding user key. This results in the turrets firing on anyone in the sector who has a user key at that time.