A Simple Solution to Combat Logging

So, essentially you are firmly advocating extreme measures for every player solely as you do not wish your reputation to be stained. Did I read that correctly?

There would be nothing extreme in it, most people wouldn't even notice the difference, and it's not only my reputation but everyone else's as well, but you don't need to agree. It's only my opinion, you can have your own ofc.
 
The solution has always been there...collect telemetry and look for patterns of abuse. There may not be any good way to identify and punish cheaters in real-time, but habitual behavior would not be overly hard to detect (with negligible false positives), and those engaging in it could be removed. Of course, the priority that has been given to enforcement of most rules that don't create legal liability or directly strike at Frontier's bottom line, and thus the effort they are willing to spend on them, seem to be quite low.
Absolutely, but you have to report. FD can't/want do full scale continuous telemetry checks on the entire player base.
If you are lucky FD will check, find solid proof and ban.
If they don't find solid proof, your report may add to the history of the naughty commander and the ban may come after the next report.

This is how it is and how it most likely will stay. No simple solution will come.
 
Absolutely, but you have to report. FD can't/want do full scale continuous telemetry checks on the entire player base.
If you are lucky FD will check, find solid proof and ban.
If they don't find solid proof, your report may add to the history of the naughty commander and the ban may come after the next report.

This is how it is and how it most likely will stay. No simple solution will come.

This is what I think the Karma would be all about.... and reporting player put then in front of the queue of logs to scan.... Karma by the sounds of it would not punish a player for a single "action", it should act more on what a player repeatedly do, so I would expect it could take 10, 50, 100 times before the Karma systems to actually flag a player for a undesired behaviour... then how they would use the data once they have it, that is a totally different story.... So in most part this could be a fully automatic system to collect data to get a wider picture on player behaviour, that FDev then can act on, if they believe in the analysis of their logs, this could cut down on the time support has todo do this...
 
It is not about monetary gain IMO as much as time lost - for some that would be data, for others it could be something else - ultimately, it does not matter what aspect we are losing on death it would account for lost/wasted gaming time regardless.


Irrelevant to the topic IMO - the fact is outside influences that could induce combat logging are sufficiently random and notionally unpredictable in nature that the punitive measure of insta-death on disconnect (regardless of the circumstances) is not justifiable.

I'm not saying that your ship should instantly be destroyed on disconnect. That's ridiculous. I'm saying it should just stay where it was in the instance at the last communication from your client. If somebody's out exploring, this is not going to affect them. And nobody with a bunch of data is going to risk it on combat. If your client isn't running, then I'm not even sure how much AI even gets run for you. It could be that you could lose connection while in SC and once your client was down, the servers wouldn't even do anything with npcs for your cmdr. That's before even suggesting something like dropping you from SC if you lose connection. A player would have a wake to drop into for a little while, but after that, your ship may as well have disappeared.

If the ship was left in the instance, the only people it would affect would be those in combat. I think losing one hour or so's worth of npc bounties to AI is worth destroying clogging for cloggers. You could even undo that by only leaving the ship in play if you were in a instance with another player.
 
Personally, I don't really see combat logging as so much of an issue. While it's something I'd never do myself, because I like to accept in-game consequences, I don't really care if someone who is that afraid to lose a ship or pay a rebuy does it to me. I'll just move on and keep playing.

The justification for the mechanism the way it currently works is that there's no real loss to the player that was doing the attacking when someone combat logs, whereas if an exiting player were to have their ship destroyed in any combat situation, then in those situations where the logging is due to a genuine network or PC issue, they lose a ship or credits for a rebuy.

I say leave it how it is and learn to live with it, if you haven't already.
 
I'm not for instant death on disconnect. But some info on the connexion quality of those you share instance with could be welcome to fine tune my blocklist.

Not mentionning those internet generals trying so hard at pvp, while behind a vpn, on mobile or eating most of their bandwith while streaming, could have some epiphany about their presumably pristine connexions...
 
I'm not saying that your ship should instantly be destroyed on disconnect. That's ridiculous. I'm saying it should just stay where it was in the instance at the last communication from your client. If somebody's out exploring, this is not going to affect them. And nobody with a bunch of data is going to risk it on combat. If your client isn't running, then I'm not even sure how much AI even gets run for you. It could be that you could lose connection while in SC and once your client was down, the servers wouldn't even do anything with npcs for your cmdr. That's before even suggesting something like dropping you from SC if you lose connection. A player would have a wake to drop into for a little while, but after that, your ship may as well have disappeared.

If the ship was left in the instance, the only people it would affect would be those in combat. I think losing one hour or so's worth of npc bounties to AI is worth destroying clogging for cloggers. You could even undo that by only leaving the ship in play if you were in a instance with another player.
How many times must this be said? Once you disconnect from other players in an instance, your ship cannot remain in the instance for them. It doesn't matter if it would be a good idea or not; it's simply impossible. This means that it does not happen and it cannot be made to happen. That's P2P.
 
No, no, it's not that. My main problem with the current system (and with your proposal as well) is not what other people do. The problem is that I might have a disconnection during combat, which can result in other people accusing me of combat logging. And the significance of the possible loss of reputation far outweighs that of the loss of a ship or a few credits in an online multiplayer game.
The current system does not expose the circumstances around any given disconnection incident and my proposal would not either - if you do not engage in combat logging then you have nothing to truely be concerned about regardless, if you do engage in combat logging then the problem is on you. Having your ship auto-destruct on disconnect would not solve the underlying issues in play.

It is not about winning or losing, the insta-death on disconnect regardless of the cause is merely massaging the egos of some pixel bandits who probably manly kill others in-game purely for lolz. Ultimately the proposal of instadeath on disconnect is unreasonable and hyper punitive.
Okay, then I (as someone who has spent much more time in PvP) can assure you that these moments of genuine connection losses during combat are extremely rare, so especially if you aren't PvPing very often, the chances of you ever experiencing such a moment is minuscule. Everyone can afford a rebuy, even lots of rebuys. Your reputation you can lose only once.
You can not legitimately project your experience on to that of others, different people will have different system configurations and infrastructure concerns - my point was that any possibility of penalising a player for something that happens outside of their control is ultimately unacceptable. I don't care how you try to dress it up, it is still overly punitive and without due cause. The state of your system, energy supplier, or internet connection is not necessarily representative of those that could get accused of combat logging (legitimate or otherwise).

The fundamental problem with combat logging complaints in these forums is that most of those complaining do not accept the fact that menu logging is NOT combat logging and there in lies part of the problem. I highly suspect that outside of the genuine cases of disconnection due to external influences outside of the player's control and menu logging that the actual combat logging incidents are not as prolific as some try to claim.

As with griefing and ganking, the simple option is clear - block, report, move on. Automated resolution of any of these incidents should NOT be implemented in any shape or form (at least not with punitive consequences such as instadeath or auto-shadowban) as automated tools are indiscriminate in their application and fail to take into account mitigating circumstances.

The points system I proposed for handling combat logging incidents should help to mitigate issues with overall connection stability - those with genuine connection stability issues will probably end up with consistently low point scores and those that actually engage in combat logging will probably end up with more higher point averages. At the very least it would allow FD to track disconnection incidents on a player by player basis more reliably. The points system I have proposed should be kept private and not unveiled to other players via the UI - it would be an Account based metric that FD can use to help police the problem either through instance segregation or mode access restrictions.

Where menu logging is concerned, FD need only add a counter to indicate that the player in question is waiting for the log-out timer and this should help deal with menu logging being falsely referred to as combat logging.

Overall, I believe I have made my position clear - this is not about me personally, this is about being against blatantly overly punitive measures.
 
But some info on the connexion quality of those you share instance with could be welcome to fine tune my blocklist.
I think the problem here is that the underlying issue may not be their connection specifically, and even with such a measure, there is no guarantee that something would not change and cause a disconnect in the process. Also the connection quality would not necessarily indicate whether there are other causes that could trigger a disconnect.

Sure, having some indication of ping time (or more likely connection latency) would not be an unreasonable expectation perhaps (should be derivable from the network packets received) but it would not necessarily give you enough of a picture to fairly manage a block list. You could perhaps follow the principle of a three strikes before blocking with an attempt in the intervening time to investigate what happened through direct reasoned dialog with the other player rather than assuming the worst and auto-demonising them.

The biggest issue with griefing/ganking/combat logging (and other notional offences) is probably social media and the attempts of some to publicly demonise anyone that seemingly offends them. The tools are there in-game to block and report and that is where it should start and end.
 
As a player who spends all thier time in pvp it is inevitable that untimely disconnections will be encountered from time to time.
I have always just recorded the event and sent it to the opposing player with an apology and request to hang around while i log back in.
I see absolutely no reason why i should have my ship destroyed in these events especially considering that in more than half of these cases i was winning.

I'll add to this i think it would be very helpfull if our HUD displayed a visual impending menulog indicator.
 
Last edited:
On PS4 we get errors related to certain crashes. If we crash to a blue screen while we are in combat with another player, there will be a code for the error displayed on the screen. We can screenshot that as proof we didn't clog and send it to the person we lost connection with.

Doesn't PC have something like this?
 
On PS4 we get errors related to certain crashes. If we crash to a blue screen while we are in combat with another player, there will be a code for the error displayed on the screen. We can screenshot that as proof we didn't clog and send it to the person we lost connection with.

Doesn't PC have something like this?
Depends on the crash, sometimes we just encounter the main-menu. At other ocassions we got a crash to desktop (with a crash-report upload window). Or we encounter a bluescreen error, what would be the worst case because then your hardware is going to go south.
But it's not what I find very appealing, because that would result in "Guilty until proofed otherwise".
 
I have a perfect example that you cannot precicly identify a c-log. During yesterdays training session of my squad, with 10 cmdrs, Some of them simply "dissapeared" as soon as things were going to boil up. I'm pretty sure they didn't c-logged, but for me it absolutly appeared as such. It's a pity really and Frontier has to do something against this. As long as that doesn't happen, we only have to live with it, that cmdrs perform a "Houdini". 🤷‍♀️

Addendum: And no it wasn't a "random cmdr", always the same commanders dissapeared because of no reason...and they always told us "Crash to menu"..."Crash to desktop"..."Oh damn...another colored ship"
 
Last edited:
On PS4 we get errors related to certain crashes. If we crash to a blue screen while we are in combat with another player, there will be a code for the error displayed on the screen. We can screenshot that as proof we didn't clog and send it to the person we lost connection with.

Doesn't PC have something like this?
It does. It also has Photoshop.
 
Just for the record: 3 disconnections (Purple Pythons) during the Wyrd Wednesday wingfight event yesterday. But these errors seem to happen only while you are trying to drop into an instance, never once during the fight itself.
 
Last edited:
But the simple fact that you 'disappeared' whilst entering the instance is enough for some here to label you a heinous Combat Logger and C H E A T and forever be hunted down like the scum you evidently are … ;)
 
But the simple fact that you 'disappeared' whilst entering the instance is enough for some here to label you a heinous Combat Logger and C H E A T and forever be hunted down like the scum you evidently are … ;)

I never said the netcode was perfect, on the contrary. Actually it seems to be more buggy than ever, so obviously there is a lot to fix before you can even think about changing anything else.
 
I never said the netcode was perfect, on the contrary. Actually it seems to be more buggy than ever, so obviously there is a lot to fix before you can even think about changing anything else.
And that is precisely what some here have been saying for 500 odd posts! The netcode will never be perfect, not game has perfect netcode, so there will always be a grey area on whether a player disconnecting is due to pulling the cable or accidently losing connectivity for a variety of reason.

Can we be honest, what is someone losing when their opponent engages the special cloaking device? Rarely is it a high bounty, and it can't be cargo because a Commander's ship doesn't leave cargo when destroyed. So what are they losing except a bit of salt seeing their opponent blow up? They have already won the engagement, they forced their opponent to flee the scene.

And before some brave soul jumps in and accuses me of encouraging or supporting cheating, I am not, just don't think it is as big a game breaking problem as some here are portraying it to be.
 
Back
Top Bottom