The Fix For Combat Logging (MENU LOG)

Good stuff, Lateralus, both the bounty hunting and CQC ideas. Nice to see actual, constructive arguments from the PvP camp instead of the same old "git gud" drivel. Because that crap is a recipe to kill the game. Can't have a viable business model around a narrow elitist niche that is hell-bent on ruining it for everyone who cannot or will not invest insane time and effort into a game.
 
I've got a suggestion (albeit unpopular) - how about we all stop worrying about it and try to remember that this is all just a bit of jolly fun?
 
I’d be cool if they’d just extend the timer to a max amount of time (if the player keeps taking hits) say 2 minutes, but then the log off happens automatically. This allows the player to go afk on the fly and not have to sit there waiting to log off. Sometimes you gotta answer the door, pick up the phone, turn off the bath, stop a cat fight outside, answer some pressing and immediate call for attention from a significant other etc. under those conditions even the 15 sec timer is too much. It needs be like a countdown with the option to opt out but no need to confirm.

When that happens I boost the ship and go take care of what actually matters rather than the video game. If my ship happens to survive great, if not well it’s a shame but that’s just bad fortune. As NPCs are unable to catch most idle ships that boosted away this leaves only Players as a potential threat to the AFK ship.

Real life happens, no we don’t need combat logging to deal with it.
 
Having in mind what an utter ridiculous C&P system we have, the proposed fix will fix exactly nothing. Moreover, in the game where a griefer can grind the credits in solo, where the well-known player killers are using CL to escape either from NPC’s or from players without consequences, removing the only legal way to deny unwonted PvP will punish the players who play in open in any ship but nowadays PvP meta build.
I’m totally agreed with the proposal and totally sure, that CL and C&P must be fixed first.
 
The fix for menu combat logging (abusing the 15 second timer.)... is simple.

Reset the timer to 15 seconds upon taking damage.
If you are continuously ANY taking damage, your timer will remain at 15 seconds.

This includes, but not limited to:

-Any incoming player damage.
-Any incoming NPC damage.
-Logging out when critical modules are 'destroyed' (Powerplant, thrusters.)
-Taking any heat damage
-Taking any corrosion damage.
-Taking any hull damage from inanimate objects.

It has been three years since release, and this still isn't fixed. You (FDEV) may not be able to directly solve task killing, but this will solve menu log cheating.

This is a multiplayer game. Fix it.

No thanks. Happy to have the confirmation moved to the start of the countdown so the player can go AFK immediately though. Plus it means the timer can be extended.

I can see a number of issues with taking when a game can be exited out of the direct & predictable control of the player; it would just increase actual CLogging.
 
Last edited:
Playing devil's advocate to conversation, if you can't kill a ship in 15 seconds while it isn't evading, then how is that different from not being able to kill a ship thats high waking in 15 seconds while it is evading? Either way, you aren't getting that kill. So why does the timer need to be higher?
 
Playing devil's advocate to conversation, if you can't kill a ship in 15 seconds while it isn't evading, then how is that different from not being able to kill a ship thats high waking in 15 seconds while it is evading? Either way, you aren't getting that kill. So why does the timer need to be higher?

LHS3447 has a distant binary where most of the action happens. If the baddie sealclubber has to high wake it's going to take them a few minutes to get back into the action. If they menu log they can just jump back in without all that travelling from the entry point inconvenience.

I agree an important aspect of this menu-log thing is accepting that they can't control other players' choices like they can with NPCs, so it may be better to play in solo where they won't be frustrated by menu-loggers.
 
LHS3447 has a distant binary where most of the action happens. If the baddie sealclubber has to high wake it's going to take them a few minutes to get back into the action. If they menu log they can just jump back in without all that travelling from the entry point inconvenience.

I agree an important aspect of this menu-log thing is accepting that they can't control other players' choices like they can with NPCs, so it may be better to play in solo where they won't be frustrated by menu-loggers.

So the better fix then would be to have all log ins in deep space (not docked or in range of a station ) be at the nav beacon or close to it. That's a better solution to that problem than changing the timer.
 
So the better fix then would be to have all log ins in deep space (not docked or in range of a station ) be at the nav beacon or close to it. That's a better solution to that problem than changing the timer.

That could work. I've had the game lose connection to the server (timeout) while jumping between systems & when you rejoin it puts you a safe distance from the main star of the system you were last in.

So have the game do that for a menu-log, where the player won't have it happen to them by accident. Potentially could become the default for any exit while the ship is in danger.

Note: there are a few scenarios where an unintended disconnect could make this frustrating, the trade off may be worth it though.
 
Last edited:
What I find curious is how force quitting the game still isn't dealt with. It seems illogical and strange that the game can't do anything to punish a player for it. Considering an OS has to signal the application that it received an application close event. It can even go as far as to describing the event. This to give the application the opportunity to do cleanup, close resources and exit gracefully. What's happening now is that the player is removed from the instance server side. However the client can, before actually terminating, signal the game server to delay removing the player server side from an instance. Thus this will leave the player there as a sitting duck for a timeout period before actually removing the player from the instance.

This will however not protect against people pulling the ethernet cable, disconnect WiFi or pull the power plug. Simply stating well, you just have to suck it up and face the re-buy screen, will not be met well by people who don't have the greatest connectivity but want to enjoy the multiplayer aspect of the game. So while it can be made more tedious for a player to combat log, totally preventing it is a more difficult matter. This could be somewhat alleviated if the player can reconnect into the instance if a short connectivity loss was the case. When ganked by multiple ships it won't. Losing power to the system you're playing on while in danger should be a very rare event to occur. So I think the benefits outweigh the downsides in this case.
 
What I find curious is how force quitting the game still isn't dealt with. It seems illogical and strange that the game can't do anything to punish a player for it. Considering an OS has to signal the application that it received an application close event. It can even go as far as to describing the event. This to give the application the opportunity to do cleanup, close resources and exit gracefully. What's happening now is that the player is removed from the instance server side. However the client can, before actually terminating, signal the game server to delay removing the player server side from an instance. Thus this will leave the player there as a sitting duck for a timeout period before actually removing the player from the instance.

This will however not protect against people pulling the ethernet cable, disconnect WiFi or pull the power plug. Simply stating well, you just have to suck it up and face the re-buy screen, will not be met well by people who don't have the greatest connectivity but want to enjoy the multiplayer aspect of the game. So while it can be made more tedious for a player to combat log, totally preventing it is a more difficult matter. This could be somewhat alleviated if the player can reconnect into the instance if a short connectivity loss was the case. When ganked by multiple ships it won't. Losing power to the system you're playing on while in danger should be a very rare event to occur. So I think the benefits outweigh the downsides in this case.

The problem is, there are legitimate disconnects that do occur, not everyone in the world has the most reliable internet you do. Frankly, mine sucks but it's the only option I have.
 
When that happens I boost the ship and go take care of what actually matters rather than the video game. If my ship happens to survive great, if not well it’s a shame but that’s just bad fortune. As NPCs are unable to catch most idle ships that boosted away this leaves only Players as a potential threat to the AFK ship.

Real life happens, no we don’t need combat logging to deal with it.

That’s also what I do. Not sure what you mean by the last part of your statement as it doesn’t really corolate to anything I’ve written.
 
Posted a few times. Doing so again.
Same as Frontier's. But they're more lenient than I am; if you have multiple 'disconnects', you should be pushed into solo. I don't think Frontier should make allowances for people with poor connections, whilst solo is an option for them.
 
Alternate, and much simpler solution to the CL problem;
If someone combat logs on you, and you know it was deliberate.. Remember their CMDR name and put them on Ignore.
You will never have to see them Combat log ever again.
 
I think the automatic logout after the 15sec timer would be very useful for real life happenings. BUT I think that maneuver should be discouraged... I present, when a player combat logs their lovely ship remains in-game but now with AI control and it has one motive, HIGH WAKE. The aggressor can still try to destroy the Logged player's ship before it jumps and if they succeed the logged player will be presented with the rebuy when they return... the aggressor is none the wiser and the Logger still has to deal with their choices.
 
Playing devil's advocate to conversation, if you can't kill a ship in 15 seconds while it isn't evading, then how is that different from not being able to kill a ship thats high waking in 15 seconds while it is evading? Either way, you aren't getting that kill. So why does the timer need to be higher?

Player piracy gets punished in these cases as non-lethal disables as part of stopping a runner would result in a combat log. Under this scenario, a ganker gets the kill, but a pirate stops the runner, shoots them into being unable to escape, makes their final ultimatum for cargo, and ends up with nothing as a result.

Everyone always complains about gankers being too common over player pirates, but neglects to realize that it’s the player pirates who end up getting penalized when the other party can just log to avoid consequences.


Other considerations: Powerplay involves parties hauling merit cargo and opposition wanting to stop said delivery. Is it fair that a merit hauling ship that is successfully beaten gets to escape by logging off and returning into the game later to make their delievry?

Should a highly wanted player, whose killed many CMDRs, escape all rebuy penalty because when cornered by Bounty Hunting Players they log off at 5% hull? Combat Logging is also a factor in avoiding the often proclaimed ‘crime and punishment’ after all.

Frankly combat logging has pretty much allowed for cheating death through ‘out of gameplay mechanics’. Even if it’s ‘tolerated’ by Frontier it’s still bad gameplay that favors unscrupulous behavior over fair play.
 
Frankly combat logging has pretty much allowed for cheating death through ‘out of gameplay mechanics’. Even if it’s ‘tolerated’ by Frontier it’s still bad gameplay that favors unscrupulous behavior over fair play.

Please, please, please tell me that you are attempting to be a joke...
 
Top Bottom