Forums » Bugs
Concerning the key ids (4235/4236), (4240/4241), and (4242/4243):
-I can confirm at least one instance (on another day several weeks ago, with different participants) where a key was revoked and reapplied in a strategic manner during a station takeover.
I'd consider that offensive use of the key system.
-To my knowledge, only User Keys are currently given out to the general player base, leaving the key power and usage requiring a lot of trust in the Owner Key holder(s).
In this case is at least contradictory to the common trope of 'Pirate Havens', as the RP names here indicate.
Thoughts on keys and the system:
-Holding a key constitutes not only a right of access but also a responsibility towards it. Freedom of choice to accept this should be given to all and not forced upon someone like spam e-mail.
-A 'Change Log' of the personal key chain would make overall key usage more convenient and transparent (e.g. Mon Feb 16 25:25:25 4650: 'User Key id (xxxx/xxxx)' was changed to No 'IFF')
-I can confirm at least one instance (on another day several weeks ago, with different participants) where a key was revoked and reapplied in a strategic manner during a station takeover.
I'd consider that offensive use of the key system.
-To my knowledge, only User Keys are currently given out to the general player base, leaving the key power and usage requiring a lot of trust in the Owner Key holder(s).
In this case is at least contradictory to the common trope of 'Pirate Havens', as the RP names here indicate.
Thoughts on keys and the system:
-Holding a key constitutes not only a right of access but also a responsibility towards it. Freedom of choice to accept this should be given to all and not forced upon someone like spam e-mail.
-A 'Change Log' of the personal key chain would make overall key usage more convenient and transparent (e.g. Mon Feb 16 25:25:25 4650: 'User Key id (xxxx/xxxx)' was changed to No 'IFF')
I have never *given* a key to a player in an attempt to gain a strategic advantage by preventing them from being able to cap the station. That’s what this thread is about. *Revoking* a key while a player is in the station sector isn’t an exploit, and should be expected when you’re trying to abuse the fact that you have a key to attack station defenders without activating the station defenses. Discussion about whether you believe the way I manage keys fits your idea of “pirate RP” is a complete digression from the topic of the thread—if you’re concerned about that you should make a post in the RP forum or say so in game.
I think there are considerable potential pitfalls in requiring players to “opt in” to a key. Relatively few players have any detailed awareness of the key system, which is a feature, not a bug—if you don’t manage the key, you don’t have to interact with the system at all, and you can still be granted access to stations and capships. Especially in the case of capship keys, requiring a new player to accept a key to dock with a capship adds an unnecessary step to a very useful tool for onboarding (pun intended).
To be honest, my preference would be to have “blacklist” keys as an option as opposed to the current “whitelist” keys, where everyone has access by default and owners can revoke access to specific players. I’m less concerned about players having the ability to permanently refuse a key, provided that requires the player to actively “opt out” of that key.
A changelog of the keychain would be useful but it wouldn’t address the issue we’re discussing.
I think there are considerable potential pitfalls in requiring players to “opt in” to a key. Relatively few players have any detailed awareness of the key system, which is a feature, not a bug—if you don’t manage the key, you don’t have to interact with the system at all, and you can still be granted access to stations and capships. Especially in the case of capship keys, requiring a new player to accept a key to dock with a capship adds an unnecessary step to a very useful tool for onboarding (pun intended).
To be honest, my preference would be to have “blacklist” keys as an option as opposed to the current “whitelist” keys, where everyone has access by default and owners can revoke access to specific players. I’m less concerned about players having the ability to permanently refuse a key, provided that requires the player to actively “opt out” of that key.
A changelog of the keychain would be useful but it wouldn’t address the issue we’re discussing.
I do think the current key system is like a hot fix the devs did to try a new feature then moved on (considering it is just inc n ray,, and whatever interns at the time it's fair enough) so abusive things you find should be reported before exploit. Only exploit them to explain and give good feedback to get fixes after no resolution. The fix to the problem is simply to make a UI change so the first time you are given a key it pops off a window saying "you have been given a new access key! To accept this key, and learn more click (here) which opens the pda to key management with a bit of blurb which id be happy to write in many languages but I digress...
After the first interaction with keys it should simply send a text saying you been given one, then goto pda to accept whatever blah blah ducks go quack (quan) etc.
[I removed portions of this post that are not in keeping with the forum rules and have locked the author out of the thread. ~Whistler]
After the first interaction with keys it should simply send a text saying you been given one, then goto pda to accept whatever blah blah ducks go quack (quan) etc.
[I removed portions of this post that are not in keeping with the forum rules and have locked the author out of the thread. ~Whistler]
What femum said
use a checkbox to accept/deny keys send to you
firstly i think there should be a selection in the config options. Auto accept keys, accept keys with approval, accept no keys.
for accepting keys with approval a continuation of the buddy system should be applied so users can either type a /accept response or "click" a button on the UI in the PDA.
+1 for csgno1's suggestion of tkos being cancelled once the defenses are down, its crazy to have to bring in an alt to have to change keys. owner key holders should be able to change the station key over while docked in the station without having to attack it first, with a timer and announcement to holders if need be to prevent "malicious use"
+1 also to Hawkfeathers suggestion for a key blacklist, I have been given keys part way through station battles before to prevent me taking the dock also so its a know tactic used by both sides i would imagine without anyone throwing their toys out of the pram
[moderator - removed unrelated note; please stay on topic for the bug report]
for accepting keys with approval a continuation of the buddy system should be applied so users can either type a /accept response or "click" a button on the UI in the PDA.
+1 for csgno1's suggestion of tkos being cancelled once the defenses are down, its crazy to have to bring in an alt to have to change keys. owner key holders should be able to change the station key over while docked in the station without having to attack it first, with a timer and announcement to holders if need be to prevent "malicious use"
+1 also to Hawkfeathers suggestion for a key blacklist, I have been given keys part way through station battles before to prevent me taking the dock also so its a know tactic used by both sides i would imagine without anyone throwing their toys out of the pram
[moderator - removed unrelated note; please stay on topic for the bug report]
I would suggest an alternate method for consideration.
Accepting auto-key would be fine if:
1. If you have key access and attack the stations, you forfiet key access immediately and get tkos (preventing station capture).
2. If key access is revoked by owner, it doesn't take effect until you leave the sector and come back (preventing triggering station defenses while in sector).
3. If you are given key access while attacking, it doesn't take effect until you leave the sector and come back (preventing tkos status and allowing capture still).
4. If you revoke your own key, it doesn't take effect until you leave sector (preventing someone from hiding a capship behind roids for protection and also applying tkos so you can't take the station).
I'm sure they could be tweaked better but it seems like a step towards eliminating exploits.
Accepting auto-key would be fine if:
1. If you have key access and attack the stations, you forfiet key access immediately and get tkos (preventing station capture).
2. If key access is revoked by owner, it doesn't take effect until you leave the sector and come back (preventing triggering station defenses while in sector).
3. If you are given key access while attacking, it doesn't take effect until you leave the sector and come back (preventing tkos status and allowing capture still).
4. If you revoke your own key, it doesn't take effect until you leave sector (preventing someone from hiding a capship behind roids for protection and also applying tkos so you can't take the station).
I'm sure they could be tweaked better but it seems like a step towards eliminating exploits.
Key blacklist sounds a bit ridiculous not to mention someone could circumvent it easily by just assigning different keys... that's one more thing to manage and keys are already tedious enough as is.
As far as a key confirmation/accept dialog that sounds great on paper, unless it only gets triggered upon the next time the player docks in a station or something that's also a potential avenue to troll players or binding different keys to spam that shit in combat...
Best solution I have would be to add removal conditions to the TKOS and leaving the whole thing as is. (provisions to prevent the old "exploit" of sploding one's own turret to start the conquering stuff wouldn't hurt either but it's not super important since the two phase dock timer got added, extending the first timer would probably suffice to mitigate retake shenanigans)
and since we're on the subject of keys - being able to changeover station keys without sploding the turrets would be pretty freakin' cool too (and putting it behind a time gate to prevent spam and other shenanigans would probably be a good idea too)
As far as a key confirmation/accept dialog that sounds great on paper, unless it only gets triggered upon the next time the player docks in a station or something that's also a potential avenue to troll players or binding different keys to spam that shit in combat...
Best solution I have would be to add removal conditions to the TKOS and leaving the whole thing as is. (provisions to prevent the old "exploit" of sploding one's own turret to start the conquering stuff wouldn't hurt either but it's not super important since the two phase dock timer got added, extending the first timer would probably suffice to mitigate retake shenanigans)
and since we're on the subject of keys - being able to changeover station keys without sploding the turrets would be pretty freakin' cool too (and putting it behind a time gate to prevent spam and other shenanigans would probably be a good idea too)
This is tentatively related to the thread but I was once given a key that was entirely composed of whitespace characters... deleting that "offensive" key was also a pain in my ass!
The key in question was named with the intent of making it difficult to remove and thankfully the key command prints/outputs to err.log otherwise I wouldn't have been able to get rid of it. (unless bruteforcing the right number of white space characters is considered late game content I guess!)
The solution to that bullshit could be making /key delete only require an associated ID# for deletion instead of having to type out a case sensitive description.
The key in question was named with the intent of making it difficult to remove and thankfully the key command prints/outputs to err.log otherwise I wouldn't have been able to get rid of it. (unless bruteforcing the right number of white space characters is considered late game content I guess!)
The solution to that bullshit could be making /key delete only require an associated ID# for deletion instead of having to type out a case sensitive description.