As for combat logging (ungraceful exit during combat). FD says it's against the rules in any mode, and that they are doing what they can to detect and deter. Some obviously think they aren't doing enough. To them I would say, give reasonable suggestions that work in the P2P architecture, and FD will probably listen. Asking for the impossible isn't going to change anything, and will just cause another "FD doesn't listen to their players" thread.
Client-tracked connection loss would likely be possible. I won't say it's a guaranteed solution, but I've mentioned it multiple times and haven't seen any reason why it shouldn't
mostly work on a theoretical level. The long and the short of it is to have the client track the current combat status in a file somewhere. Turn the flag on when combat starts, and then turn it off only when combat ends (use the same routine that unlocks the quit button). Should the user kill the game process during combat, the current combat status would be left on. Should a network issue between the client and the instance host, the client should immediately ping an ED server, and kick back to the main menu if the ping fails (leaving the current combat status as is). Then, when the client next loads in, check the combat status first to see if an ungraceful exit occurred.
There are a few points to be made on this;
• Anyone who knows where to look could find the file and turn off the combat flag. This could be managed somewhat by saving in various locations or using a encrypted file, but ultimately I'm sure a portion of people may be able to bypass it. I argue that even if a workaround is figured out, it will be just a small number of people that use it, and detection will still be better than it is today.
• People with multiple computers will get weird results. Combat logging on computer A, then moving to computer B will show no log happened. But then when the player moves back to computer A sometime later, they will get hit by the detection. This could probably be fixed by giving each session an ID to track, saving the ID to the file, and having the transaction server tell the client what the last-used session ID was. Of course, this opens the door to less-savvy workarounds where people could just alternate computers to avoid all punishments. Whether the system should lean towards forgiveness or enforcement is beyond me.
• Such a system would likely have a high detection rate. With this in mind, punishments need not be shadow banning or other account-related actions. Simply skipping to the re-buy screen alone would be more than enough if
every combat log was detected.
• Players with shoddy connections will be negatively affected. I would argue that this is fine, since their connection as is negatively impacts other players in Open today. Regardless, if client-side tracking is Open-only, these players with less-than-ideal connections could still play in both Solo and Group with no change. While it's true that combat-logging against NPC's to avoid ship loss is technically cheating, combat logging in PvP is what causes frustration. Additionally, if one or two "warnings" were given before actual punishments took place, it would allow once-in-a-blue-moon disconnects from really hurting anyone. This could also help for people using multiple computers in point two, should the system lean towards enforcement.
Players gain nothing from pvp.
It has no impact on the game.
Piracy would be the big one. Under normal circumstances, the pirate need not kill the trader. But if the trader runs, the pirate must try to kill him, or else why would traders ever cooperate in the first place?
Let's not pretend that ED didn't advertise both Piracy and PvP. A lot of people, myself included, signed up for a multiplayer, PvP-enabled space game. I would love more opportunities to do player bounty hunting, but that's hard when piracy doesn't work.