They wouldn't but then killing Overwatch is not the same as killing ED.
Logging During Combat Punishment [Proposal]
- Thread starter MONTItheRed
- Start date
They wouldn't but then killing Overwatch is not the same as killing ED.
What's interesting is, IMHO, if we follow your lead but instead suggested gankers were perma banned, the overall outcome for the game and community would be far more beneficial...
If we consider the wider picture, which is always a good idea instead on fixating on a specific point rather than the broader goal, I suspect combat logging doesn't happen very often during PvP piracy, but is instead more common when CMDRs feel they are being interdicted simply to be pointlessly destroyed for someone else's enjoyment (at their grief).
Could we not maybe consider then that just maybe, pointless illegal destruction, performed by quite likely a very small minority, at the expense of a vaste majority, for in truth no in game purpose/outcome, is actually what's on trial here?
Now, maybe we could suggest, if the game actually at long long last finally offered simple easy to participate in legal PvP activities (eg: via Powerplay, or other tasks), and then mindless (illegal) destruction was heavily penalised to seriously reduce it, the outcome might be far more productive? Except for griefers of course!
Last edited:
The rules are simple, combat logging is against them and is a ban-able offence. I'm simply saying make it a permanent ban; if one can't be bothered to play by the rules, then one should rather go play something else. When you break the rules, your opinion of those rules is mute.
But one can make educated guesses based on the information at hand. There's a plethora of telemetric data that can be used, there's playing habits, there's connection history and so on.
It's not difficult to determine if someone combat logs if their data shows, for example, 100 player combat encounters, 70 in combat disconnections. Yes, that's the kind of data sent back to FD. 70% of the time that player engages in combat, he innocently disconnects?
If it looks like combat logging, and it smells like combat logging ..
If FD said "do not exploit Sothis/Ceos, it is cheating and you will be punished for doing it" .. then yes, I'm wholeheartedly in favour of a perma-ban.
I'm sorry if my zero tolerance for cheaters somehow bothers you; I simply prefer multi-player games that don't have that kind of scum bobbing about.
Do you even know what the word "cheating" means? It means to gain an unfair advantage over another person. Please explain, in elaborate detail, how ramming your ship at high-speed into another player is cheating?
Unless, of course, there is more to this high-speed griefing I don't know, which is possible. As I already stated, I didn't even know it happened so I can only go on what's been said and make assumptions therefrom. As I understand it, players were killing other players by ramming their ships into them. I can't infer much else from it.
You cheat. You're out.
I'm sorry that you consider lack of leniency to be unreasonable.
Not that this really matters anyway. Remember that instancing in this game is based on P2P architecture and, as a result, Fdev cannot detect combat logging. It probably shows up as some sort of connection error and no other useful data, assuming that it shows up at all. Punishing means some way to determine guilt, which means some method of detection. As a method of detection does not exist, and may never exist, this argument doesn't get us anywhere. The easiest way to cut down on combat logging isn't harsh punishments to act as a deterrence, but rather removing the incentive. If there were no reason to combat log, then no one would combat log. The problem is that this is a different kettle of fish. People combat log for many reasons, like getting away from a greifer or psycho player, a PvE guy getting out of unwanted/unwarranted PvP, or a PvP guy who is a sore loser. That last reason can't really be helped, but the other two can. Having the instigator pay for the rebuy of his victim's ship and cargo would accomplish this goal. Unwanted and/or unwarranted PvP would no longer be an issue because it would be expensive for the other party, same for griefers and psycho players.
Don't try to sell me on players reporting other players when they combat log. Eyewitness testimony is the worst kind of evidence, and a lot of players can't tell the difference between a case of combat logging and the graceful log out that Fdev put in the game. Not to mention that its one player's word against another's, and there is no way to know who is right. At least in legal cases like this, the whole case gets thrown out because it is a waste of time.
How is it different? End task is end task, doesn't matter what program it is. Affecting the BGS? Big deal, its not like any of us actually knows how it works. We have suspicions, but not much else. Prevent a player bounty hunter (trying not to laugh here) or pirate (assuming there are any left out there these days) from doing their jobs? Ok....so? Aren't both of those jobs based on preventing someone else from doing their job? At that is ignoring the fact that suicidewinders and (ironically) combat logging/regular logging make bounty hunting players an exercise in futility and that genuine player pirates are an endangered species now.
CMDRYoloSwag420 attacks 100 people; 70 of them disconnect him from their instance; CMDRYoloSwag420 appears to disconnect 70% of the time he engages in combat; CMDRYoloSwag420 is permanently banned.
I feel like I have to explain this every other day.
Last edited:
Last edited:
Oh my, you are something. Now, prey tell, what's the difference between killing the ED task and, say, ED crashing? Or getting a "connection to matchmaking server" error (or however that message goes)? I've had both happen to me on multiple occasions (the matchmaking thing being way way more common), in different scenarios (from jumping to another system to already being in an instance and seeing other people).
People are trying to tell you, but you won't listen. You're arguing about enforcing something that can't be enforced*. Yes, we can argue that deliberately killing ED is against the rules. But because you can't enforce those rules in any way, shape, or form, the end result is that said rules should be treated more like a gentleman's code.
In fact, banning people for "killing the game executable via the Task Manager", in ANY game, would be insane! Absolutely mad! Bonkers! Bananas! (Please stop smoking them!) [wacko]
* It IS be possible to implement mechanisms which would make killing the task pointless (other games don't have this problem, after all)... but implementing those mechanisms would require rewriting and remaking the network model, which likely won't happen.
Last edited:
What's more, if ED is going after players that only combat log when in PvP combat, you only need to combat log once or twice out of PvP combat for each time you combat log to escape PvP; with that, Frontier should find most of your combat logs aren't related to PvP and peg you as someone with a bad connection instead of a combat logger.
If you know a bit about statistics and about which data is being collected you can easily play havoc with the results. Statistical analysis is nearly useless against someone intent on not allowing it.
It's not against the rules to kill Overwatch, because you don't gain anything from it and you're only hurting yourself. ED you are unfairly benefitting from killing the ED process. You didn't die when you should have, and your opponent didn't get the loot he should have gotten.
I'd have thought the difference was obvious.
I have two words for you: Graceful Exit.
Here's a wiki link on how graceful exits usually work in software development: https://en.wikipedia.org/wiki/Graceful_exit
Largely used as a form of error handling, graceful exits can also be used to determine if the correct process was followed when exiting a program. For example, ED likely returns a notification of intent to the server "I am closing now" (I say likely because I didn't write it so I can only make an guess based on my own experience as a developer). Without this, the loss of connection by the client to the server can be recorded as a ungraceful exit (the program did not notify the server of it's intent). Couple this with various other data, such as the frequency with which a user disconnects and under what circumstances and, with an acceptable margin of error, one can make an educated guess on what's going on. As in, one can determine that, the user tends to disconnect when there are a large number of players in an instance, or the player tends to disconnect when they engage in PvP are about to die.
If the shoe fits...
There is no reason to CL. People make up a reason because they want to play in open without the risk of getting their ship blown up by another player. Those people need to come back to reality.
Log off normally then. You're getting griefed in a game world that allows for open PvP interaction? Then suck it. Die, rebuy, and log off. Alternatively, pick a cheap ship, jump to a distant system and then transfer your ship. Combat logging is not acceptable.
PvE getting unwanted PvP? Play in Mobius. Unwarranted? In Open, you don't have that luxury. A player can engage with you in PvP. He does not need your permission, he doesn't even need a reason.
Welcome to Open.
No it wouldn't. It would simply kill any desire for PvP and destroy Piracy, one of the primary careers of this game.
What, you want a pirate to pull a player out of SC and go "sup friend, wanna engage in friendly PvP so I might partake of some of the gold in your hold?"
Or a player approach another player and select the "Request duel" option?
You want PvE, play in a PvE dedicated group. If you play in Open, you must stand up like a man and deal with the cards that are dealt you.
It's not an issue now. Players have an option to remove unwanted PvP. They don't take it? That's their look out. If they don't like it, that doesn't justify combat logging.
It doesn't matter if they can't tell the difference, because it's on Frontier to determine if the accusation has merit; the player is simply saying "hey guys, I think he combat logged can you check?"
Not really. Player makes an accusation, Frontier verify said accusation, action may or may not be taken.
A player isn't automatically guilty of CL'ing just because a player reported him for it. Frontier still need to do their investigations.
- - - Updated - - -
Let me know when you have software development experience in client/server architecture.
Last edited:
The difference between killing ED and ED crashing? ED generates a crash log when it crashes, not when you kill it.
Match making server error? The fact that the client is capable of returning that error shows that the error has been handled. Meaning Frontier would be well aware of it by looking the data the client returns to them, not to mention the logging that occurs server side.
People are trying to tell me things, they just have no experience in client/server architecture and application interoperability. I do.
Let me know when you discover that Elite handles player interaction via P2P.
Let me know when you realise we're not talking about player interaction, but rather telemetry data and logging information.
This is fun. Let's keep it going. 
Last edited:
Let me know when you realise we're not talking about player interaction, but rather telemetry data and logging information.
This is fun. Let's keep it going.
You can't collect telemetry on which player dropped the P2P to end a fight without interfering with Elite's processes or connection to the transaction server. Or if either player did it, for that matter.
Whoops, I mean, uh, let me know when you realise that
Last edited:
You can't collect telemetry on which player dropped the P2P to end a fight without interfering with Elite's processes or connection to the transaction server. Or if either player did it, for that matter.
Whoops, I mean, uh, let me know when you realise that
Let me know when you realise...
... that this is a large wall of text. Sorry. :/
There's an object inside the ED API labelled "vanishCounters" which tracks commander logging data. Now, it's not sensible to store that information locally in a file because it can just be edited/deleted, however, it makes sense for your peers to store that information in memory; because if your client exits/crashes, that information is lost once the memory block is freed. This information you've received is either from my client or from the server when one of us enters the other's instance.
Each key/value pair in this commander logging JSON structure, can store various information. Such as are you friendly? Are you in danger? Etc.
As you may know, if the owner of an instance leaves, ownership is transferred to a new player (if there is no new player, the instance is destroyed), so when you disconnect from the other's instance (in any way) that information is recorded.
You can see what information is recorded just by looking at the ED log files.
[ The following is assumption by experience ]
If you leave either by Waking, Menu > Quit or killing the process the method used is recorded: it won't say "scum pressed Alt+F4
" but it might say "client X timed out" or "client X disconnected; ungraceful exit" or various other informative messages. This information is submitted to the Frontier server at some point and likely stored in a table that is linked to your commander ID by all the connected peers, or maybe just by the instance holder.
Look at how often ED communicates with the Frontier server, even when you're in an instance alone (Ctrl+B when in game).
When you relaunch the game, your logging data is submitted to the Frontier server, possibly alongside information like "client was terminated by the user."
This can be determined either using the Windows API, or simply from reading a log file. The file could reference an associated crash file if the program crashed, or it could simply not have the entry available which means the program was closed prematurely and didn't crash.
This is three examples of how I'd do it:
{ crash }
[ 01/01/2017 - 22:00 ] [CRASH] Appended by CrashLoggerApp. See crash_log_XYZ.log
// You could put code here to handle crashes. Eg: Run in "safe mode"
[ 02/01/2017 - 09:30 ] [APP_START] Application started. Client reconnected. Logging started.
{ graceful exit }
[ 01/01/2017 - 22:00 ] [APP_EXIT] Client disconnected. Application terminate. Logging stopped.
[ 02/01/2017 - 09:30 ] [APP_START] Application started. Client reconnected. Logging started.
{ ungraceful exit }
[ 02/01/2017 - 09:30 ] [APP_START] Application started. Client reconnected. Logging started.
// The client has determined that there is no [APP_EXIT] or [CRASH] entry in the file. It generates an error code.
[ 02/01/2017 - 09:30 ] [ERROR] No [APP_EXIT] found. No crash log found. Error Code: 5004585
All this information is submitted to the Frontier servers.
If they then compare that data they have against all your previous encounters they will be able to pick up a pattern and -within an acceptable margin for error- make an educated determination as to what happened.
Is it 100% accurate? No but patterns don't lie, and if the behaviour is consistent both with combat logging and with your general behaviour (e.g.: You frequently disconnect when you're in trouble in PvP), then one can normally safely assume you were combat logging.
If both clients crash simultaneously, then Frontier can see this as well. They'll see both disconnected ungracefully and they can assume that it was perhaps a bug or a server issue or some such case.
My point though is that there's a plethora of telemetric data that be recorded in various ways, and it doesn't all have to come from you. Telemetric data about you, can come from me as well.
Last edited:
Let me know when you realise...
... that this is a large wall of text. Sorry. :/
There's an object inside the ED API labelled "vanishCounters" which tracks commander logging data. Now, it's not sensible to store that information locally because it can just be edited/deleted, however, it makes sense for your peers to store that information. This information you've either received from my client or from the server when one of us enters the other's instance.
Each key/value pair in this commander logging JSON structure, can store various information. Such as are you friendly? Are you in danger? Etc.
As you may know, if the owner of an instance leaves, ownership is transferred to a new player (if there is no new player, the instance is destroyed), so when you disconnect from the other's instance (in any way) that information is recorded.
You can see what information is recorded just by looking at the ED log files.
[ The following is assumption by experience ]
If you leave either by Waking, Menu > Quit or killing the process the method used is recorded: it won't say "scum pressed Alt+F4
This information is submitted to the Frontier server at some point and likely stored in a table that is linked to your commander ID by all the connected peers, or maybe just by the instance holder.
Look at how often ED communicates with the Frontier server, even when you're in an instance alone (Ctrl+B when in game).
When you relaunch the game, your logging data is submitted to the Frontier server, possibly alongside information like "client was terminated by the user."
This can be determined either using the Windows API, or simply from reading a log file. The file could reference an associated crash file if the program crashed, or it could simply not have the entry available which means the program was closed prematurely and didn't crash.
This is three examples of how I'd do it:
{ crash }
[ 01/01/2017 - 22:00 ] [CRASH] Appended by CrashLoggerApp. See crash_log_XYZ.log
// You could put code here to handle crashes. Eg: Run in "safe mode"
[ 02/01/2017 - 09:30 ] [APP_START] Application started. Client reconnected. Logging started.
{ graceful exit }
[ 01/01/2017 - 22:00 ] [APP_EXIT] Client disconnected. Application terminate. Logging stopped.
[ 02/01/2017 - 09:30 ] [APP_START] Application started. Client reconnected. Logging started.
{ ungraceful exit }
[ 02/01/2017 - 09:30 ] [APP_START] Application started. Client reconnected. Logging started.
// The client has determined that there is no [APP_EXIT] or [CRASH] entry in the file. It generates an error code.
[ 02/01/2017 - 09:30 ] [ERROR] No [APP_EXIT] found. No crash log found. Error Code: 5004585
All this information is submitted to the Frontier servers.
If they then compare that data they have against all your previous encounters they will be able to pick up a pattern and -within an acceptable margin for error- make an educated determination as to what happened.
Is it 100% accurate? No.
But patterns don't lie, and if the behaviour is consistent with combat logging. Well, one can normally safely assume this is the case.
You're still talking about exiting the game or killing processes. Frontier have already said that they can tell when people do that, and I'm not disputing it.
But there's no need for somebody to exit the game or kill processes to combat log. If the P2P connection drops, it looks exactly the same to each client.
Statistics are obviously still a thing. But then you run back into my original point about how likely it is for many different players to disconnect from one other player.
Granted, however if your P2P connection drops, something either went wrong or someone interferred. In either event, someone's client will raise a red flag. Either my client will raise an exception ( PEER_E_INVALID_PEER_HOST_NAME if it can't find your PC ), or your client will raise an exception ( PEER_E_FW_BLOCKED_BY_POLICY if I decide to block P2P on my firewall as an attempt to leave ). Somebody's client will make a fuss in someway.
Windows COM (Component Object Model) under which P2P falls, generates an exception (error) if something goes wrong when it shouldn't, both client and host side.
All this information is logged and all of it helps Frontier made educated decisions.
Last edited: