Forums » General
Cross-posted from News..
Tonight's server update includes the following change:
- Exploits involving disconnection or duplicate-reconnection during mid-jump, usually for the purposes of avoiding a pursuing attacker, have been more extensively mitigated. Some of these mitigation techniques are old, some are new, but we've gone to some lengths to make them more consistent and robust for both Fighters and Capital ships:
* If a player disconnects mid-jump, a "proxy" ship controlled by the remote sector will be spawned in their place (with their ship and cargo), and will remain there for a minute until timing out normally ([EDIT]: Capships still require 5 minutes to time out). This proxy ship may not spawn until up to a minute after the player's jump, so if another pilot is in hot pursuit, and then finds their target has "disappeared" during jump, the pursuer should have patience for up to a minute.
* Attempts at duplicate-reconnection to knock off existing connections while mid-jump will immediately spawn the replacement proxy ship in the destination sector, until the second player connection is able to establish control.
* In all cases, a disconnection mid-jump will always result in the disconnected player being placed in the destination sector.
* In all cases, if the disconnected user should re-connect while the proxy ship is "standing in" for them, they will re-establish control of their ship.
This kind of development will be on-going, as we look to shore up and improve some areas of gameplay prior to the launch on Steam. As always, feedback is welcome, particularly if Bugs are found (please post to the Bugs forum, or submit via Support Tickets if you think there is a risk of bug exploitation). Thanks all!
Tonight's server update includes the following change:
- Exploits involving disconnection or duplicate-reconnection during mid-jump, usually for the purposes of avoiding a pursuing attacker, have been more extensively mitigated. Some of these mitigation techniques are old, some are new, but we've gone to some lengths to make them more consistent and robust for both Fighters and Capital ships:
* If a player disconnects mid-jump, a "proxy" ship controlled by the remote sector will be spawned in their place (with their ship and cargo), and will remain there for a minute until timing out normally ([EDIT]: Capships still require 5 minutes to time out). This proxy ship may not spawn until up to a minute after the player's jump, so if another pilot is in hot pursuit, and then finds their target has "disappeared" during jump, the pursuer should have patience for up to a minute.
* Attempts at duplicate-reconnection to knock off existing connections while mid-jump will immediately spawn the replacement proxy ship in the destination sector, until the second player connection is able to establish control.
* In all cases, a disconnection mid-jump will always result in the disconnected player being placed in the destination sector.
* In all cases, if the disconnected user should re-connect while the proxy ship is "standing in" for them, they will re-establish control of their ship.
This kind of development will be on-going, as we look to shore up and improve some areas of gameplay prior to the launch on Steam. As always, feedback is welcome, particularly if Bugs are found (please post to the Bugs forum, or submit via Support Tickets if you think there is a risk of bug exploitation). Thanks all!
As note, if you want to post on the forums about this, I expect people to Be Nice. I don't want to hear any historical drama, finger-pointing, baiting/trolling, or claims of who-exploited-what-and-when.
I'm only interested in fixing the issues and moving forward. Leave any drama and baggage at the door, and keep it off my forums.
I'm only interested in fixing the issues and moving forward. Leave any drama and baggage at the door, and keep it off my forums.
Only a minute persistence is probably not enough for capital ships. Seems the fair time for cap ships is about 5 mins, same as the standard capship log off persistence.
Excellent. And yeah, cap ships should take 5 minutes to time out.
well i did this experiment with two accounts.
My intimate friend (different account from CN'B) watch me (C'NB) on the same sector.
I open a new instance of vo and log in the same account of (CN'B).
As soon as the character choice panel open (less than one minute), my intimate friend on the other account witnesses the immediate disappearance of C'NB.
Though CN'B was not in jumpin' process, but this is still an exploit to stop a pursuer to catch ya.
A panel saying wait 5 minute to reconnect would be a nice fix, with a local message on sector saying XXX is disconnected or on proxy.
Just my 2c.
My intimate friend (different account from CN'B) watch me (C'NB) on the same sector.
I open a new instance of vo and log in the same account of (CN'B).
As soon as the character choice panel open (less than one minute), my intimate friend on the other account witnesses the immediate disappearance of C'NB.
Though CN'B was not in jumpin' process, but this is still an exploit to stop a pursuer to catch ya.
A panel saying wait 5 minute to reconnect would be a nice fix, with a local message on sector saying XXX is disconnected or on proxy.
Just my 2c.
Just out of curiosity. Did many exploit this bug? Bug abusers hopefully get banned, right?
I've had this happen jumping to m7 and lagging out pain in the but to redock gunners need to test to see if gunners stay docked
+2 to Deathspores for testing it.
And yes Xeha, I have had countless players disappear while following their warp destination.
And yes Xeha, I have had countless players disappear while following their warp destination.
+1 Xeha
cool update, a long time coming
Only a minute persistence is probably not enough for capital ships. Seems the fair time for cap ships is about 5 mins, same as the standard capship log off persistence.
The 5-minute capship timeout is still being used. The MOTD is basically incorrect in that aspect.
As soon as the character choice panel open (less than one minute), my intimate friend on the other account witnesses the immediate disappearance of C'NB.
Ray is investigating this now. This case was already supposed to be mitigated (there's code in place), so it wasn't tested with all the newer changes. Clearly, it isn't working right. We'll fix it as soon as possible.
The 5-minute capship timeout is still being used. The MOTD is basically incorrect in that aspect.
As soon as the character choice panel open (less than one minute), my intimate friend on the other account witnesses the immediate disappearance of C'NB.
Ray is investigating this now. This case was already supposed to be mitigated (there's code in place), so it wasn't tested with all the newer changes. Clearly, it isn't working right. We'll fix it as soon as possible.
As soon as the character choice panel open (less than one minute), my intimate friend on the other account witnesses the immediate disappearance of C'NB.
DeathSpores, we are not able to reproduce the issue you saw, plus in our server logs it clearly shows the Proxy ship being spawned properly on your duplicate login.
Ray's going to contact you directly for details, but as far as our testing goes.. a second login causes the Proxy to spawn for a minute. If there's some specific edge-case we're missing, we'd love to hear about it. A Support Ticket might be best for that discussion.
DeathSpores, we are not able to reproduce the issue you saw, plus in our server logs it clearly shows the Proxy ship being spawned properly on your duplicate login.
Ray's going to contact you directly for details, but as far as our testing goes.. a second login causes the Proxy to spawn for a minute. If there's some specific edge-case we're missing, we'd love to hear about it. A Support Ticket might be best for that discussion.
Re-tested today.
This time i started a timer as son as i hit the return key for entering the logon password on Capt'N Blood second vo instance.
I had the character choice page in 20s for the new instance. As soon as the page appears i have the initial Capt'N Blood vo instance back to logon screen. On the monitoring instance vo with the second account, Capt'N Blood's marauder was still appearing in space. Capt'N Blood ship vanished at 1.01mn.
It works as intended.
Looks like my test from yesterday was not enough rigorous and accurate.
Apologies guys.
Cheers.
This time i started a timer as son as i hit the return key for entering the logon password on Capt'N Blood second vo instance.
I had the character choice page in 20s for the new instance. As soon as the page appears i have the initial Capt'N Blood vo instance back to logon screen. On the monitoring instance vo with the second account, Capt'N Blood's marauder was still appearing in space. Capt'N Blood ship vanished at 1.01mn.
It works as intended.
Looks like my test from yesterday was not enough rigorous and accurate.
Apologies guys.
Cheers.
"Bug abusers hopefully get banned, right?"
This seems to like the kind of thing that would be annoying to verify. Probably a significant portion of the people folks have seen "exploiting" this just had bad luck with their devices/networks and legitimately crashed mid-jump. Comparing somebody's rate of crashing mid-jump while other players are nearby vs. when players are not around might be a way to distinguish intentional violations, but there would always be some amount of uncertainty, and that means stress, drama, and the risk of penalizing innocents. Plus the time to set up some routines to comb the data, testing them, manually verifying the people identified just in case, and communicating with the offenders (likely involving a progression of warnings followed by close monitoring and more severe punishments if the behavior continues). Huge timesink.
If all they did was fix the exploit, then I for one am satisfied with that. Preventing ongoing and future abuse is almost always more important than punishing past abusers, and there are a lot of more productive things the devs can do with their time than kicking in a few numbskulls' teeth. Such as letting us steal capships, raid NPC stations, or get chased by the cops for carrying/flying contraband.
This seems to like the kind of thing that would be annoying to verify. Probably a significant portion of the people folks have seen "exploiting" this just had bad luck with their devices/networks and legitimately crashed mid-jump. Comparing somebody's rate of crashing mid-jump while other players are nearby vs. when players are not around might be a way to distinguish intentional violations, but there would always be some amount of uncertainty, and that means stress, drama, and the risk of penalizing innocents. Plus the time to set up some routines to comb the data, testing them, manually verifying the people identified just in case, and communicating with the offenders (likely involving a progression of warnings followed by close monitoring and more severe punishments if the behavior continues). Huge timesink.
If all they did was fix the exploit, then I for one am satisfied with that. Preventing ongoing and future abuse is almost always more important than punishing past abusers, and there are a lot of more productive things the devs can do with their time than kicking in a few numbskulls' teeth. Such as letting us steal capships, raid NPC stations, or get chased by the cops for carrying/flying contraband.
Good update!
Best update ever!
P.s. is it just [EDIT] capships that take 5 mins? I think this is a bit biased, heh
P.s. is it just [EDIT] capships that take 5 mins? I think this is a bit biased, heh
You can already steal capships, and NPC's are boring bandaids for the lack of players with computers.
Thought you were leaving?
I'm not subscribed, what about you?
什么时候修复NPC一被打就跑的bug啊。。。很烦的诶