Forums » Suggestions
It seems some players (thespian for one, yeah, i'm not afraid to name and shame) think its cool to play VO while downloading. Now I have no idea why VO prioritises the laggy player by making his shots count, (I guess its your fondness for being able to run VO from a 56k modem) and not mine, but the simple solution to this would be for the server to kick a player if they have more than 500ms ping.
Martin.mac.au had a 500ms at times, and our fights were still stable, but if I throttle my connection to VO (which makes my ping higher than it should be, like if a throttle it to 28k i have a 1000 ping) or have a download going on in the BG or like a P2P app running, I know it makes me near impossible to fight, and that if someone is silly enough to stick around for a fight I will win.
Simple matter is, should you fix the way VO networking works? (No, because it does, I had stable fights with martin from the UK to AUS! Thats impressive) or should you kick people who are abusing the current lag issue.
Most companies go with the second option, I suggest you do too. :) BTW, I have run a few tests on "stable ping" before I made this post, at 500MS I am laggy, but not warping. The warping is a problem, cos all though they are warping round for you? They aint for themselfs.
[edit]
Just tested from the UK with a 56K modem, and Vo works ok, still only 347 ping though, people with above 500 are either in china, or have a really bad connection.
[edit 2]
thespian didn't kill me or anything, he was warping so I flew away, then other players dies to him, and whined about him warping on 100.
Martin.mac.au had a 500ms at times, and our fights were still stable, but if I throttle my connection to VO (which makes my ping higher than it should be, like if a throttle it to 28k i have a 1000 ping) or have a download going on in the BG or like a P2P app running, I know it makes me near impossible to fight, and that if someone is silly enough to stick around for a fight I will win.
Simple matter is, should you fix the way VO networking works? (No, because it does, I had stable fights with martin from the UK to AUS! Thats impressive) or should you kick people who are abusing the current lag issue.
Most companies go with the second option, I suggest you do too. :) BTW, I have run a few tests on "stable ping" before I made this post, at 500MS I am laggy, but not warping. The warping is a problem, cos all though they are warping round for you? They aint for themselfs.
[edit]
Just tested from the UK with a 56K modem, and Vo works ok, still only 347 ping though, people with above 500 are either in china, or have a really bad connection.
[edit 2]
thespian didn't kill me or anything, he was warping so I flew away, then other players dies to him, and whined about him warping on 100.
I second this in a major way. Terribly annoying for all involved.
what do i do when im in Thailand or in Japan. :(
Actually go out?
Spidey, we all know what you do in thailand...
Get kidnapped in the Golden Triangle and sold off as a rape toy to some vacationing banker?
I love this idea.
Is it possible to set up a certain tolerance for known areas of bad connections? Such as China would have a higher tolerance than the West Coast US.
Might balance out some of the issues that might arise from people who just are unfortunately located far away from the servers.
Is it possible to set up a certain tolerance for known areas of bad connections? Such as China would have a higher tolerance than the West Coast US.
Might balance out some of the issues that might arise from people who just are unfortunately located far away from the servers.
A good point yoda , and one that needs to be addressed at some point.
Of course, if a player is on a shared internet connection then their high latency might not be of their own making , but a valid argument nonetheless.
Of course, if a player is on a shared internet connection then their high latency might not be of their own making , but a valid argument nonetheless.
I can see where the existing VO latency arbitration system allows the client to appear to run smooth, while hunting bots, and this could make the game very attractive to people that do suffer latency.
The problem here is that this very same system is detrimental to pvp. And it is most problematic when that latency is in a specific range of short duration burst.
Since the problematic issue is only latency in a specific range, an addition latency arbitration system could be added at the server, where by, when a player's client reports movement in violation of VO' physics model, the server could buffer up that movement, and distribute it over a period of type, to bring it back into line with VO's physics model. In this way, the player would appear to someone else, to move at the maximum capability of their vehicle, until they achieved reasonable parity with the server. This would smooth out the movement on the server, and make it at least theoretically possible to hit them with energy weapons. To prevent intentional abuse, damage reported by a lagging client to another player will need to be limited, reduced, or otherwise negated, at least in proportion to the amount of time the client was out of contact with the server.
The problem here is that this very same system is detrimental to pvp. And it is most problematic when that latency is in a specific range of short duration burst.
Since the problematic issue is only latency in a specific range, an addition latency arbitration system could be added at the server, where by, when a player's client reports movement in violation of VO' physics model, the server could buffer up that movement, and distribute it over a period of type, to bring it back into line with VO's physics model. In this way, the player would appear to someone else, to move at the maximum capability of their vehicle, until they achieved reasonable parity with the server. This would smooth out the movement on the server, and make it at least theoretically possible to hit them with energy weapons. To prevent intentional abuse, damage reported by a lagging client to another player will need to be limited, reduced, or otherwise negated, at least in proportion to the amount of time the client was out of contact with the server.
Well put, Roda. That's exactly what should be done.
Roda, let me see if I understand.
Player is at Point A and starts lagging. Say it's just a second hiccup. He stops lagging at Point B. You want to smooth out the flight path between Point A and Point B, but in essence you can't because to do so you'd need to know when and where Point B is. And once you do, the travel time between is done and gone in the past. So without extending his "lag" longer, I don't see how it can be done, from a coding perspective.
I think, however, that the server should rely on itself more for damage hits rather than sanity check the clients. Both you and your opponent send info to the server and the server is monitoring the battle. If your opponent suddenly stops pinging, the client assumes their flightpath given the last vector. Why not have the server be the nanny in this case? Stand in for the client and register hits even if one of the clients does not respond.
It sort of does that already, but that's usually for full blown ping outs, not lagginess.
Player is at Point A and starts lagging. Say it's just a second hiccup. He stops lagging at Point B. You want to smooth out the flight path between Point A and Point B, but in essence you can't because to do so you'd need to know when and where Point B is. And once you do, the travel time between is done and gone in the past. So without extending his "lag" longer, I don't see how it can be done, from a coding perspective.
I think, however, that the server should rely on itself more for damage hits rather than sanity check the clients. Both you and your opponent send info to the server and the server is monitoring the battle. If your opponent suddenly stops pinging, the client assumes their flightpath given the last vector. Why not have the server be the nanny in this case? Stand in for the client and register hits even if one of the clients does not respond.
It sort of does that already, but that's usually for full blown ping outs, not lagginess.
rodas just whinin cause he cant beat me anymore with a one one with vultures :P
Seconds: activity
0.000 Player A is at full strafe right, when lag spike hits. Server lets Player A "drift" at full strafe right.
0.100 Player A continues full strafe, and register 1200 damage on player B.
0.200 Player B registers 1200 damage on Player A.
0.300 Player A changes to full strafe up.
0.600 Server receives update from Player A, showing the 1200 damage, and the fact that he is now some 20m up and left of where the server believed him to be. The server now applies maximum strafe to the servers representation of Players A, in an attempt to bring the servers representation of player A to the same position reported by player A's client. The 1200 damage to player B is reduced by a factor of 6. The 1200 damage to player A is registered in full.
0.700 Player A has changed strafe again, and reported a new position. The server ignores all previous inputs, and applies maximum strafe, by the shortest route, to resolve discrepancy between server's represented position, and players reported position.
For any player, with greater than 0 ping, the server is always buffering input, and applying shortest route strafing to reported position. If the discrepancy is greater than full thrust, then it is limited to full thrust. Otherwise, a fraction thrust based on frequency of updates from client is applied.
This produces a smoothing effect to a second hand observer, that mirrors the current smoothing effect observed on bots. It also keeps laggers from registering unrealistic amounts of damage on opponents that where only stationary in their local client, but where in fact dodging on the server.
This produces a minor handicap to the lagger, but lag should never be an advantage. Great ping can not be faked, it is either great ping, or it isn't. If a disadvantage must be mediated, then it should be mediated to the advantage of the condition that con not be faked.
The fact that omega starts downloading pron while spidey starts a dog fight should not lead to an advantage on spidey's part.
0.000 Player A is at full strafe right, when lag spike hits. Server lets Player A "drift" at full strafe right.
0.100 Player A continues full strafe, and register 1200 damage on player B.
0.200 Player B registers 1200 damage on Player A.
0.300 Player A changes to full strafe up.
0.600 Server receives update from Player A, showing the 1200 damage, and the fact that he is now some 20m up and left of where the server believed him to be. The server now applies maximum strafe to the servers representation of Players A, in an attempt to bring the servers representation of player A to the same position reported by player A's client. The 1200 damage to player B is reduced by a factor of 6. The 1200 damage to player A is registered in full.
0.700 Player A has changed strafe again, and reported a new position. The server ignores all previous inputs, and applies maximum strafe, by the shortest route, to resolve discrepancy between server's represented position, and players reported position.
For any player, with greater than 0 ping, the server is always buffering input, and applying shortest route strafing to reported position. If the discrepancy is greater than full thrust, then it is limited to full thrust. Otherwise, a fraction thrust based on frequency of updates from client is applied.
This produces a smoothing effect to a second hand observer, that mirrors the current smoothing effect observed on bots. It also keeps laggers from registering unrealistic amounts of damage on opponents that where only stationary in their local client, but where in fact dodging on the server.
This produces a minor handicap to the lagger, but lag should never be an advantage. Great ping can not be faked, it is either great ping, or it isn't. If a disadvantage must be mediated, then it should be mediated to the advantage of the condition that con not be faked.
The fact that omega starts downloading pron while spidey starts a dog fight should not lead to an advantage on spidey's part.
Yeah, I kind of agree with you Roda, but as I understand it, that would require the entire re-working of how VO works, which is a long term thing for sure.
If there is going to be *an influx of newbs" this needs a *short term* fix.
Fin Kename plays happily from Asia, he used to have a 500ish ping, and take "sometimes up to 10 minutes" to load a sector. Yes, long term, maybe the networking code needs work, but to be honest, I'm sick of hearing about this "long term plan" Roda, I have been hearing it since alpha.
If there is going to be *an influx of newbs" this needs a *short term* fix.
Fin Kename plays happily from Asia, he used to have a 500ish ping, and take "sometimes up to 10 minutes" to load a sector. Yes, long term, maybe the networking code needs work, but to be honest, I'm sick of hearing about this "long term plan" Roda, I have been hearing it since alpha.
I am not going to kick people off who have a higher-than-500ms ping. That's just not a reasonable solution.
The complaint seems to be that, when updates from a client are delayed, the server attempts to resynch as quickly as possible to the client's latest reported location. This can result in people skipping around, but makes everything appear relatively "sane" from the given player's perspective (good if they're just, say, flying through an asteroid field with a 500ms ping, it looks the same to them as if they flew through with a 5ms ping).
We could, conversely, treat people over a latency/distance threshold a bit differently, and instead of resynchonizing the server to the client's last reported position/rotation/velocity, instead for the client to resynchronize to what the server last saw. This would mean, instead, that people over 500ms would "skip around" to their own point of view, and would probably end up flying in straight lines and things to other people, as the server would continue their last known trajectory, and force them to adhere to it on resynch. In other words, they would be total cannon fodder in PvP. The other side effect, is that the game would appear crappier to the impacted individual, since they would be skipping around, out of their own control.
We could also further limit this to only occur in "combat" scenarios. That might be rather complicated, but it could be limited to sectors where weapons fire had been detected, for instance. This would make high-latency gameplay (like, say, mining or trading) still less annoying for people in non-combative roles, limiting their awareness of the impact of their higher ping times.
That might be a reasonable tradeoff, but I'm not totally sure on all the implementation concerns. A totally elegant solution where the server tries to match the client's position over a period of time, using interpolation and velocity changes based on the known capabilities of the client's equipped ship.. is overly complex and will probably not happen in the near term.
The complaint seems to be that, when updates from a client are delayed, the server attempts to resynch as quickly as possible to the client's latest reported location. This can result in people skipping around, but makes everything appear relatively "sane" from the given player's perspective (good if they're just, say, flying through an asteroid field with a 500ms ping, it looks the same to them as if they flew through with a 5ms ping).
We could, conversely, treat people over a latency/distance threshold a bit differently, and instead of resynchonizing the server to the client's last reported position/rotation/velocity, instead for the client to resynchronize to what the server last saw. This would mean, instead, that people over 500ms would "skip around" to their own point of view, and would probably end up flying in straight lines and things to other people, as the server would continue their last known trajectory, and force them to adhere to it on resynch. In other words, they would be total cannon fodder in PvP. The other side effect, is that the game would appear crappier to the impacted individual, since they would be skipping around, out of their own control.
We could also further limit this to only occur in "combat" scenarios. That might be rather complicated, but it could be limited to sectors where weapons fire had been detected, for instance. This would make high-latency gameplay (like, say, mining or trading) still less annoying for people in non-combative roles, limiting their awareness of the impact of their higher ping times.
That might be a reasonable tradeoff, but I'm not totally sure on all the implementation concerns. A totally elegant solution where the server tries to match the client's position over a period of time, using interpolation and velocity changes based on the known capabilities of the client's equipped ship.. is overly complex and will probably not happen in the near term.
Was it more like that during alpha? I remember my ship had a bit a life on its own back then when I was still on dialup.
A friend I wanted to introduce to the game had the same problem ..said the game sucked ..and never tried it again...
(ok.. maybe the jumpyness wasn't the only reason ..but it was probably a factor)
Overly laggy people are annoying. Although I can't complain cause my connection isn't always smooth either. :/
A friend I wanted to introduce to the game had the same problem ..said the game sucked ..and never tried it again...
(ok.. maybe the jumpyness wasn't the only reason ..but it was probably a factor)
Overly laggy people are annoying. Although I can't complain cause my connection isn't always smooth either. :/
We tested different things during alpha (mostly compression behaviours and updating schemes), but we never did what I mentioned above.
In general, a user who is experiencing latency sees the dynamic objects around him "jumping" (bots, people, etc), but not the actual universe objects (asteroids, stations, etc).
[EDIT] I discussed the above idea with Andy, and he added it as a ticket to the Trac system. FYI.
In general, a user who is experiencing latency sees the dynamic objects around him "jumping" (bots, people, etc), but not the actual universe objects (asteroids, stations, etc).
[EDIT] I discussed the above idea with Andy, and he added it as a ticket to the Trac system. FYI.
In other words, they would be total cannon fodder in PvP.
Better that than their being an untouchable annoyance to the whole Goddamn universe. It's not our fault they have shitty internet.
Better that than their being an untouchable annoyance to the whole Goddamn universe. It's not our fault they have shitty internet.
Well right now it's the one lagging that's jumping around for everyone else, which makes him sometimes very hard to hit. In a way everyone else is getting penalized.
I'd think the situation you described might look worse to the one lagging but would be much better as far as pvp goes and look better to everyone else.
And really, if you have ping over ~200 but below what causes the whole jumping thing you already are cannon fodder in pvp.
I'd think the situation you described might look worse to the one lagging but would be much better as far as pvp goes and look better to everyone else.
And really, if you have ping over ~200 but below what causes the whole jumping thing you already are cannon fodder in pvp.
I guess penalising the lagger instead of those with fine connections is a better idea Inc. I guess kicking folk is a bit harsh, but so is the current system where if you have a high enough ping, you are immune (or practically immune) but can still cause damage.