Forget. The life is beautiful.
First time
- Thread starter Trickylion
- Start date
If somebody consistently loses their connection every time they're interdicted by a player then they can make a fair guess.
lol wut? Of course they can. A task kill is nothing but a request that can be detected.
They can detect the SIGKILL signal the Kernel sends the process, but that could happen due to a variety of legitimate reasons, including the Client getting into an unresponsive state. They cannot discern legitimate usage of task killing vs malicious usage programmatically very easily (if at all).
Thats way too deep into the stack already, a "kill task" from the Task Manager calls TerminateProcess() on the Windows API, what happens after that is (for now) beyond me, as TerminateProcess() is easy to detect. Detecting the murder of a network socket/connection might be more challenging.
Last edited:
It doesn't matter at which point in the stack they catch the signal. There are still legitimate reasons to use the Task Manager to kill the ED client (ie: UI unresponsive), and it's pretty much impossible to detect if the task manager was used for "legitimate" reasons or not.
Why can't they see the responsiveness of their own application when TerminateProcess() is called?
I got ganked a while back, did not CL... and my game crashed to desktop (and uploaded the dump to FD) just as I was frantically trying to high-wake out.
When I logged back in I got a very snarky message from the ganker threatening to N&S me on some Reddit thread dedicated to shaming combat loggers. Not entirely politely, I told him the game had CTD'd and if I was CLing why would I have come back immediately in Open?
He was still fairly arsey about it... so I dropped FD a line just in case it had any repercussions as I knew it was against the rules. They were fine about it, just said to forget it.
Gankers gonna gank, I know, it's when they also act like dix over the messaging that it's a little annoying.
When I logged back in I got a very snarky message from the ganker threatening to N&S me on some Reddit thread dedicated to shaming combat loggers. Not entirely politely, I told him the game had CTD'd and if I was CLing why would I have come back immediately in Open?
He was still fairly arsey about it... so I dropped FD a line just in case it had any repercussions as I knew it was against the rules. They were fine about it, just said to forget it.
Gankers gonna gank, I know, it's when they also act like dix over the messaging that it's a little annoying.
How would they be able to tell if the processes is truly irresponsive or not? Often even the Kernel has difficulty detecting that condition.
Keep in mind they cannot risk false positives.
Last edited:
Why you need proof that something is not responsive is beyond me, you have proof that the program is responsive while end task was called.
There's no "proof" whatsoever that the game was responsive, or in a non-buggy state. Otherwise bug detection and fixing would be a really easy job.
As a programmer you need to know the state of your program, not knowing it == no program. So if your telemetry shows you the crucial processes are up, the player is in a dangerous situation and end task is called you can let him get away with it once, twice or thrice, but in all situations you can conclude there was a combat log.
FD has been doing this, and according to this board false positives have been made.
I'm talking in general by the way, in ops case it's easy, if the program was unresponsive then they should not be able to determine the log. Dunno if your initial remark was made in a general context or not...
Last edited:
At best, one can reach a "probability" score for the likelyhood of "combat logging" vs "crashed state". And even then it's not ever going to be 100% accurate.
And yes, you SHOULD know the state of your program. When the program enters an unexpected state is usually when things start going bonkers and bugs occur. Detecting such "unexpected states" is not trivial at all, tho - otherwise there would be no bugs.
edit: The fact that the system isn't ever going to be 100% accurate, means FDEV would need to apply real humans to verify each case manually, and even a human can't probably tell you much more than automated analysis with a great degree of certainty. How do you discern someone with a consistent/repeated crash condition that passed through the QA process, from someone with malicious intent? Even someone with a poor network connection from someone that consistently disconnects the ethernet cable?
Last edited:
The 100% thingy depends, from a logical point of you can be 100% sure, from a philosophical point of view you can never be sure of anything. In the last case the missing peace to make 100 is called collateral damage. Just use "sorry" to repair that damage
Except it's not philosophical at all. Cheat detection is difficult, and a lot of times requires manual review to weed out false positives that occur. You can't just ban some random poor dude because he has a bad ISP that drops connection often and gets reported for combat logging.
OK it's all getting a bit techy, I am over it, let's move on, I could have high waked out if the thing hadn't crashed anyway, there as they had nice ships but were only expert and master level combat, so I was fairly in control.
Last edited: