well that's multiplayer gaming 101: player's ip addresses can't be public. ever. period. from there there's nothing you can do ... except living in a police state maybe (it seems we're solwly getting there, though).
How long would a ship need to remain persistent to prevent a menu log from being abused?
well that's multiplayer gaming 101: player's ip addresses can't be public. ever. period. from there there's nothing you can do ... except living in a police state maybe (it seems we're solwly getting there, though).
![[VR] Goooost](https://forums-cdn.zaonce.net/data/avatars/m/111/111637.jpg?1589354934){kind=avatar}
I don't see what would prevent fdev from having an ai pilot on standby just like we have with crew already, in the off chance that someone goes to the menu to quit while they're in the instance of another commander, there could be a 10 second or so transition to AI controlled vessel while the actual player disembarks. You'll still get your kill, and they'll still be able to chicken out. Win-win. The only issue would be accidentally making the AI replacement better than the player that left, so we'd have to set that AI to flee only.
Tbf though the same could be said for most technological attacks. Honestly, for someone with half an understanding of networking, building a tool that manipulates connections - especially those as insecure as gaming connections - is a bit of a joke.
And then all they need to do is turn that script into a distributable program, and script kiddies are running riot.
But it's like saying "well you can't stop someone walking up to a man and stabbing him, so why bother having anti-murder laws at all?". You can't stop it all. But you can reduce it to acceptable levels.
No hurry dude, it’s just me with the beers, did you forget I was coming over?
technicalities. when you see 2 players dogfighting, that's basically 2 computers synching with each other. if one disappears the other is left alone. it could be negotiated so that a third machine takes over (a server, or the standing player's own machine which would have its obvious issues) but that's work. in 5 years frontier could indeed have fixed that, but they just have other priorities. (like feeling more at ease)
So, I click on your IP address in this software I have, send you a disconnect packet, you get kicked and an AI takes over control of your ship - thus making it far easier for me to destroy it than it would be if you were flying it.
You're, basically, just giving jerks a reason to mess with the game to create an advantage for themselves.
The only reason it doesn't already happen is because there is nothing to be gained by doing it.
Indeed - and the degree to which that could be abused for the lulz is absolutely enormous.
FD have already tightened things down so that perfectly innocent players get the infamous "IP changed mid-session" disconnection from cheap or over-zealous ISP's.
It's only 15 seconds, but it's 15 seconds of doing nothing in a combat situation. Not shooting back, and (presumably) flying in a straight line (or maybe in a circle). Your ship is far more vulnerable than if you were actually at the controls for those 15 seconds.
What I'm unsure of is what your NPC copilot (if any) might be able to do in those 15 seconds - either in your SLF, or actually at the helm of the mothership while you are controlling the SLF.
What I'm unsure of is what your NPC copilot (if any) might be able to do in those 15 seconds - either in your SLF, or actually at the helm of the mothership while you are controlling the SLF.
your example there has a flaw: you only get the timer in "combat" related situations, so unless you always log out in conflict zones or while under fire, i don't see how you can get to that waiting time
but i agree that 3 minutes would be far to long (i know another game where it was set to 1 minute, and the countdown was canceled by any interaction)
welcome to peer2peer games.
set the game to use the ipV4 protocol
open the task manager, go to the performance tab, click on the "resource monitor" button and then select the EliteDangerous entry. go to network traffic and see all the ipV4 connections to your PC
there must be a reason why FDEV is pushing ipV6 usage
there must be a reason why FDEV is pushing ipV6 usage
It's still vastly improved from the early days where we got hostnames, FQDN's, and even local user account names in the logs
Fair comment although, now you mention it, in beta I'm finding I often get a countdown for no obvious reason, always accompanied by the "Your ship/SRV is in danger" message.
It's not always the same length either.
I quit the game while in an SRV on a planet surface, 5 second countdown. Next time a 10 second countdown.
I quit the game floating in empty space, 10 second countdown. next time a 15 second countdown.
That's becoming irritating enough.
Extend it to 3 minutes and I guarantee you I'll never wait for it to complete.
Ideally, you should be able to instantly menu log and have a minimalistic client maintain your presence in the instance for some period of time while the system is virtually idle, or long enough for Frontier to cleanly transisition your CMDR to a temporary server host.
Failing that, if you ship is in danger, it should explode on exit.
It's just a game after all. If you have something more important to do and you absolutely cannot wait until your ship isn't in danger before leaving, the safest bet is to assume it will be eventually destroyed.
There isn't any timer of any kind if your ship isn't in danger and no one has proposed their should be.
I have virtually as much time in the game as you and I can count the number of times I just so happened to be done with my session while my CMDR's ship was regarded as being in danger on one hand, if not one finger. 99.9% of the time my CMDR is either docked, immune to all (non-bugged) harm, or drifting in a completely empty instance. In these cases, the wait is, and should remain, zero.
Intent.
Menu logging obviously has to exist and has it's place as a means to exit the game.
One cannot and should not be prevented from leaving the game even if their ship is in danger.
However, if one is explicitly leaving the game because of that danger to their CMDR's ship, then that's abuse because that's not what the menu log is there for and that's the sort of thing the timer seeks (but fails) to deter.
The actual problem is, as has already been mentioned, two fold.
1. You have to actually wait 15 seconds to hit confirm if 'in danger', even if that danger is trivial, to exit the game. This is too long.
2. You are only vulnerable for 15 seconds during a menu log out, even if you are in non-trivial danger that would take longer to resolve. This is too short.
Moving the confirmation to the beginning fixes #1.
Keeping the client active significantly longer fixes #2.
Not allowing the other account to log in until the first one times out would solve that pretty easily.
Any punitive measures would need to look at telemetry over repeat instances of suspicious connection activity and would almost certainly reveal weaponized IP manipulation for what it was.
Frontier could also go back to using a method they have used in the past, with a server intermediary between players. The AppConfig.xml used to contain a "RelayViaServer" variable for this...not sure if it works currently, but I'll get around to testing it soon.
Extend it to 3 minutes and I guarantee you I'll never wait for it to complete.
You shouldn't have to wait now and not one person in this thread has even hinted that you should.
About the only thing everyone seems to agree on is that the having to wait to confirm is silly.
Last edited:
@ whoever moved this thread, the reason I placed this in general discussion and not PvP in the first place is that the timer exists outside of PvP and is undoubtedly abused to save CMDR vessels from threats that have nothing at all to do with other CMDRs.
While my example, and much of the discussion refers to PvP, it's most certainly not a PvP-only concern. If someone's ship should have been destroyed, it should have been destroyed, no matter who or what the danger that would have prompted the timer to show up in the first place. Assets not lost when they should be lost are handouts that go back into the game everyone shares.
While my example, and much of the discussion refers to PvP, it's most certainly not a PvP-only concern. If someone's ship should have been destroyed, it should have been destroyed, no matter who or what the danger that would have prompted the timer to show up in the first place. Assets not lost when they should be lost are handouts that go back into the game everyone shares.
If OP wishes to introduce his own rules set he is welcome to make a PG rather than try and enforce his vision on FD and the rest of the game population. You can make any rules you like in a PG; no CL , no PvP , open only etc.
I like how it worked in Jumpgate.
You could quit any time you wanted, or even force close the game, but your ship remained vulnerable (and slowed down) for 30 seconds after logging out. Players who thought they could cheat their way out of a loss were in for a rude surprise.
You could quit any time you wanted, or even force close the game, but your ship remained vulnerable (and slowed down) for 30 seconds after logging out. Players who thought they could cheat their way out of a loss were in for a rude surprise.
this is something that only works in a client/server game.
elite dangerous is a peer2peer based game.
lets say you have player A and B in PvP
for whatever reason, the connection between them is severed, but not the the server, for both.
for each client it will look like the other one has has lost connection/disconnected -> current safety mechanic is, that those ships turn invulnerable and disappear after a timeout.
if FDEV would make it different, like suggested here a few time, by turning that other ship into an npc controlled one, you get the situation where player A fights npc B, and player B fight NPC A.
how will it count if on each side the player wins the battle?
the other solution would be, that if the connection between two peers in pvp is lost, but not to the server, that they both get kicked to the login-screen.
something that would happen instad of combat logging.
IMHO FDEV needs to change the logout timer to work like in perpetuum:
1. if you logout to the menu while "in a dangerous situation" you get a timer and no further confirm button
2. if you are either being hit by weapons, or interact with the controls in any way, the timer is canceled (excluding Chat)
for those circumventing the timer by pulling the plug:
1. if the server detects a the simultaneous loss off connection to the server AND other peers, send a warning to the disconnected peer the next time he logs in
2. if it happens multiple times, shadowban the perpetrator for a day or two
3. if it still happens, let support/GM make contact with that account
Quoted both of these posts because they're both relevant.
Firstly, at the risk of stating the obvious, PvPers (even murder-hobos) actually want the opportunity to explode stuff.
Sure, it's possible that a slippery PvPer might make use of IP manipulation as a last resort, if they're losing a fight, but that would be easy to identify if they did it regularly - with circumstantial evidence, at least.
Think of the other situations where this might be useful though.
At a Trade CG somebody could just show up and start randomly disconnecting players in combat ships to negate any possibility of attack.
If somebody's involved in PP they could show up in a system and, upon spotting players from another faction, they could be disconnected in order to prevent any possibility of attack.
If somebody's doing BGS-related stuff they could disconnect players who might be in opposition.
These are scenarios where IP manipulation would provide an important advantage but - importantly - it's unlikely that the players targeted would even realise anything dubious was afoot.
You'd just arrive in a system and, on occasion, you'd suffer "random" disconnections.
And then there's the issue of people deliberately introducing a random element to their use of any cheating.
The simplest example of this is when people suggest the game might be able to track those who combat-log and take punitive action.
Trouble is, to circumvent this, all I'd have to do is task-kill more, and not always during combat.
If I "lose my connection" 10 times a week, always when I'm losing at combat, the circumstantial evidence would suggest I'm CLing.
If, OTOH, I "lose my connection" 30 times a week and 25 of those instances happened when I'm not in danger, 5 happen when I am in danger but I also have my ship destroyed 5 times a week, there's little circumstantial evidence to suggest anything other than that I have a lousy connection.
Similar thing would apply to any use of IP manipulation.
Whether I'm trying to manipulate a CG, PP or the BGS (or if I'm just screwing with people) as long as I don't do it all the time it's going to be pretty hard to pin anything on me conclusively enough to take action.
These are all vulnerabilities that are already in the game and, in some cases, would already provide people who used them with an advantage.
The only real "counter" is the fact that, rather than cheating, it's easier to simply play in Solo and avoid any situation where IP manipulation would be advantageous.
That's why it's probably not going to be a good idea for FDev to impose anything punitive, either in terms of logging out, PvP or mode-locking.
As soon as there's something in the game that allows people to gain an advantage by using a cheat, it's going to become more common to use it.
Put "placeholder" ships in the game after a player CLs and suddenly there's a reason to kick other players - so you can destroy their ship easily.
Lock PP to Open and suddenly there's a reason to kick other players from your instance - to avoid combat.
In this kind of scenario, it's possibly likely that griefers would be the first to take advantage of cheats but they're certainly NOT the only people who'd do it and it's certainly not just a PvP issue.
And, in that event, I suspect FDev's response would be similar to what they've done with hacking, bot-ships and CLing; they'll pay lip-service to the issue, downplay it and then act like it isn't a big deal and hope it goes away.
A potential solution to this - which would be actively beneficial to people with genuine doorbells or dodgy connections - would be:
1) Remove the menu quit timer - if you press exit, the game exits.
2) On quit, serialise the state of the NPCs in the instance into your savegame on the server. [1]
3) On resume, unserialise them and they can carry on doing what they were doing.
4) If there were any players about, unserialise their ships as NPCs with either a neutral or hostile AI depending on their state.
5) Periodically save the state to allow recovery from network disconnects. It'll be a little out of date, but good enough.
Now if you're playing in Solo with a dodgy connection and you've finally found that mission NPC, you don't have to find them again after you log in again.
(If you logged out to get away from that mission-related Elite Anaconda? Tough - it's still there. But you *do* have time to call out the
[1] Also serialise your own state more precisely - throttle, hardpoints, etc.