Forums » Suggestions
Simple keychain changes that would make a big difference
These seem like low-hanging fruit. Simple stuff like changes to string formats and sort order that would make the player experience with keys a lot less miserable.
- Show Key IDs in the GUI
The same key can exist under a dozen different names for a dozen different players. The only constant is the Key ID, but that's only shown to players in the output of the /key list command, which is really clunky, and can't be used while the key selection dialog is up after conquering a station.
It would be really nice if user keys also showed the ID of the parent owner key. Something like [888/889], especially if/when multiple user keys are re-enabled.
I've been asking for this for years. How hard is it to change a string format? :(
- Sort the list by something user-visible
After conquering a station, the game presents you with a modal dialog that blocks the rest of the interface until you select or create a key. The list it gives you is sorted by whatever and you can't use the game chat to ask other players what keys they have. This would be a lot less cumbersome if it was sorted by something visible and useful. Key ID would be great. Name if that can't be added.
- Default access for IFF and Can-Dock
These permissions are useless as long as an owner key can only have a single user key. When an owner key can only have a single user key, it makes no sense for that user key to default to no access when the only purpose a user key can serve is to give IFF and Can-Dock access without the ability to grant new keys.
Apparently this was by design! It makes for a really bad player experience as you have to navigate through the clunky keychain UI in the middle of a fast-paced station battle before your newly respawned turrets kill off your allies.
I'm sure people are going to dump on this thread with lots of requests for guild keys, delegated keys, key access by guild rank, nation, ship type, hair color, etc. That's not the point here. That stuff all probably requires major dev work. I'm not suggesting a major rewrite. I'm asking for some simple changes to improve the game now.
- Show Key IDs in the GUI
The same key can exist under a dozen different names for a dozen different players. The only constant is the Key ID, but that's only shown to players in the output of the /key list command, which is really clunky, and can't be used while the key selection dialog is up after conquering a station.
It would be really nice if user keys also showed the ID of the parent owner key. Something like [888/889], especially if/when multiple user keys are re-enabled.
I've been asking for this for years. How hard is it to change a string format? :(
- Sort the list by something user-visible
After conquering a station, the game presents you with a modal dialog that blocks the rest of the interface until you select or create a key. The list it gives you is sorted by whatever and you can't use the game chat to ask other players what keys they have. This would be a lot less cumbersome if it was sorted by something visible and useful. Key ID would be great. Name if that can't be added.
- Default access for IFF and Can-Dock
These permissions are useless as long as an owner key can only have a single user key. When an owner key can only have a single user key, it makes no sense for that user key to default to no access when the only purpose a user key can serve is to give IFF and Can-Dock access without the ability to grant new keys.
Apparently this was by design! It makes for a really bad player experience as you have to navigate through the clunky keychain UI in the middle of a fast-paced station battle before your newly respawned turrets kill off your allies.
I'm sure people are going to dump on this thread with lots of requests for guild keys, delegated keys, key access by guild rank, nation, ship type, hair color, etc. That's not the point here. That stuff all probably requires major dev work. I'm not suggesting a major rewrite. I'm asking for some simple changes to improve the game now.
+1.
With the current set of permissions, having all permissions enabled by default is strictly more efficient. If you want somebody to have no access at all, you simply don't give them a key in the first place. If you want them to have partial access, then it doesn't matter whether they key defaults to having both or neither checked, because you'll have to either check or uncheck one box in either scenario. So the only area where there is a difference is if you want the user to have full permissions. In that situation you currently have to tick two boxes. It would be more efficient to not have to tick any boxes, and as I said, this wouldn't impose any extra cost when you don't want to give full permissions.
Granted, this doesn't hold in possible futures where there are additional permissions. But if nothing else, the IFF permission should be enabled. That is the time-critical one. It's very rare that you might want to give somebody a key but not give them IFF. Taking slightly longer to revoke IFF in those cases causes significantly less harm than taking slightly longer to give IFF.
With the current set of permissions, having all permissions enabled by default is strictly more efficient. If you want somebody to have no access at all, you simply don't give them a key in the first place. If you want them to have partial access, then it doesn't matter whether they key defaults to having both or neither checked, because you'll have to either check or uncheck one box in either scenario. So the only area where there is a difference is if you want the user to have full permissions. In that situation you currently have to tick two boxes. It would be more efficient to not have to tick any boxes, and as I said, this wouldn't impose any extra cost when you don't want to give full permissions.
Granted, this doesn't hold in possible futures where there are additional permissions. But if nothing else, the IFF permission should be enabled. That is the time-critical one. It's very rare that you might want to give somebody a key but not give them IFF. Taking slightly longer to revoke IFF in those cases causes significantly less harm than taking slightly longer to give IFF.
+1
+1
Maybe also an improved organizational system for the PDA's Keychain page?
The ability to sort keys by Capship/User/Owner/Active/Inactive etc would be a great improvement for players with cluttered Keychains. Even just separating Capship keys would be nice.
Maybe also an improved organizational system for the PDA's Keychain page?
The ability to sort keys by Capship/User/Owner/Active/Inactive etc would be a great improvement for players with cluttered Keychains. Even just separating Capship keys would be nice.
If this is something we can do quickly, we'll take a look.
Also, take Ray's "by design" comments with a grain of salt.
Also, take Ray's "by design" comments with a grain of salt.
Thanks for looking in to it. This stuff gets to be really frustrating once you have more than half a dozen keys.
Thanks for adding the key IDs.
Did you take a look at changing the sorting order? It still seems to be sorted by whatever.
Did you take a look at changing the sorting order? It still seems to be sorted by whatever.
It says on the update notes that it's sorted by keyid but it's not.
+1 OP
+1 to sort by hair color.
+1 to sort by hair color.
What list is not sorted? The modal dialog box asking to assign an access key should be sorted.
The Main list of all your owner and user keys is not sorted.
The Main list of all your owner and user keys is not sorted.
Ah see that's where the confusion is. The key chain itself being sorted would be a huge help since 95% of interactions with keys have nothing to do with assigning a new key. We'd want to find a key quickly in the key chain and give/revoke keys.
Yeah, I was talking about the keychain list in the PDA's Inventory tab.
Sorting the key selection dialog is a good idea too, thanks for doing that.
Sorting the key selection dialog is a good idea too, thanks for doing that.
Please check out the latest update and see if it is satisfactory.
Ray, Thanks! That's awesome!