Forums » Suggestions
Request for Comments: Prediction Monitoring and "lag jump".
We've recently released some fundamental changes to the game's protocol, to help mitigate the issues in PvP combat where individuals may have really chaotic ping times, or packet loss, that makes their movements very difficult to track. Basically, ships "jump around" so much they're nearly impossible to shoot.
There have long been many suggestions about addressing this, but for a game with an international userbase, who all play on a single server, there are some really significant usability trade-offs that kept this from being a simple fix.
It's taken quite a bit of time, and development, and testing, but the result is the new system released this past weekend, in 1.8.520. For the sake of simple discussion, I'll call it Prediction Monitoring.
A complete description of how it works would be quite lengthy, I'm going to skip that, and limit it to what's relevant from a player standpoint:
1) Let's say two players exist in a sector.
2) They must be able to potentially damage one another (can't be the same-nation in a Capitol system, for instance).
3) They must NOT be grouped (grouping excludes the lag-management behaviour, for users within the group).
4) They must NOT be in a No Fire Zone (players in NFZs are excluded, as it could make docking too hard for high-ping players).
If one of the players fires a weapon, and that weapon fire is spawned within 3000 meters of the other player...
THEN..
- Prediction Monitoring is then engaged for those specific players, for 30 seconds.
The "30 seconds" concept is basically that each new instantiated shot, that is within the 3000 meter distance, will re-start the 30-second timer.
What does Prediction Monitoring do?
Basically, it looks for disparities in server-predicted data, for a given client, versus client-reported data, and when a "triggering threshold" is crossed, it ignores the update packet from the player and instead responds with a "server-enforced" packet of its own.
This does not mean the player will suddenly "stop" or "hold still". Stopping in VO means instant death, and that's basically too much of a negative impact to place on a player who has an unfortunate "slow update packet", because someone in their house decides to stream Netflix right then, or whatever else.
The server will currently allow the player to predictively "drift" in the orientation, speed and direction that they last reported, and force the "lagged" user's client to update to this new position/orientation/velocity.
In practice, this means that an adversary with a chaotic or (very) high ping may still jump around quite a bit, but the jumps will be interspersed with brief periods where they fly more consistently in a direction.
In my testing, this changed targets from being nearly impossible to hit at all, to.. possible to kill (but still not trivial).
"As a higher-ping player, will this negatively impact my ability to fly?"
Hopefully not? The whole idea here is to give a nuanced solution that allows for the best gameplay experience for the greatest number of people, including those beyond the US and Europe.
Testing is on-going, but the biggest impact thus far as been on extremely high pings, like 800ms. But connection stability is actually more important than absolute "ping time": having a consistent higher-ping should be better than a chaotic and lossy lower-ping.
Basically, we DON'T want to make combat significantly worse for someone in Australia fighting someone in the USA. There's always going to be some "jumping around" in that kind of pairing, and people can still use the existing "ping indicator" colors to make judgements about who they want to engage.
We DO want to handle cases where there are really egregious and massive jumps in location, due to "lost" network packets or major retransmissions, so that this kind of "advantage" can't be artificially induced by less-than-ethical players.
"If it happens to me, what is the result?"
The server-enforced re-positioning can be a bit disorienting. Your ship may go from facing one direction in one location, to suddenly being somewhere else and facing a different direction. For VR players, it could be particularly unpleasant.
This is exactly why we wanted to be extremely minimalist with how this system is triggered and applied. For instance, there's no reason for it to ever happen to people who are botting, or mining, or regularly flying around.
Similarly, this is a per-packet system, so even if you experience it once, due to a random dropout on the internet, that doesn't mean you'll continue to have problems. This is part of why we avoided the kind "ping-specific" suggestions I linked above.
This will be a WORK IN PROGRESS for probably some time to come
The full extent of this system quite complicated, well beyond what I'm discussing here. There are edge cases that came up in testing that required implementing fairly involved solutions.. but that's all beyond scope of this discussion.
We're likely to continue tweaking and improving the system, based on player feedback, as well as our own analytics. So, as always, don't take anything here as "cast in stone", we're continually interested in making the game better.
This thread exists so people can give real-world feedback.
Please test the new system and let us know how it works for you.
There have long been many suggestions about addressing this, but for a game with an international userbase, who all play on a single server, there are some really significant usability trade-offs that kept this from being a simple fix.
It's taken quite a bit of time, and development, and testing, but the result is the new system released this past weekend, in 1.8.520. For the sake of simple discussion, I'll call it Prediction Monitoring.
A complete description of how it works would be quite lengthy, I'm going to skip that, and limit it to what's relevant from a player standpoint:
1) Let's say two players exist in a sector.
2) They must be able to potentially damage one another (can't be the same-nation in a Capitol system, for instance).
3) They must NOT be grouped (grouping excludes the lag-management behaviour, for users within the group).
4) They must NOT be in a No Fire Zone (players in NFZs are excluded, as it could make docking too hard for high-ping players).
If one of the players fires a weapon, and that weapon fire is spawned within 3000 meters of the other player...
THEN..
- Prediction Monitoring is then engaged for those specific players, for 30 seconds.
The "30 seconds" concept is basically that each new instantiated shot, that is within the 3000 meter distance, will re-start the 30-second timer.
What does Prediction Monitoring do?
Basically, it looks for disparities in server-predicted data, for a given client, versus client-reported data, and when a "triggering threshold" is crossed, it ignores the update packet from the player and instead responds with a "server-enforced" packet of its own.
This does not mean the player will suddenly "stop" or "hold still". Stopping in VO means instant death, and that's basically too much of a negative impact to place on a player who has an unfortunate "slow update packet", because someone in their house decides to stream Netflix right then, or whatever else.
The server will currently allow the player to predictively "drift" in the orientation, speed and direction that they last reported, and force the "lagged" user's client to update to this new position/orientation/velocity.
In practice, this means that an adversary with a chaotic or (very) high ping may still jump around quite a bit, but the jumps will be interspersed with brief periods where they fly more consistently in a direction.
In my testing, this changed targets from being nearly impossible to hit at all, to.. possible to kill (but still not trivial).
"As a higher-ping player, will this negatively impact my ability to fly?"
Hopefully not? The whole idea here is to give a nuanced solution that allows for the best gameplay experience for the greatest number of people, including those beyond the US and Europe.
Testing is on-going, but the biggest impact thus far as been on extremely high pings, like 800ms. But connection stability is actually more important than absolute "ping time": having a consistent higher-ping should be better than a chaotic and lossy lower-ping.
Basically, we DON'T want to make combat significantly worse for someone in Australia fighting someone in the USA. There's always going to be some "jumping around" in that kind of pairing, and people can still use the existing "ping indicator" colors to make judgements about who they want to engage.
We DO want to handle cases where there are really egregious and massive jumps in location, due to "lost" network packets or major retransmissions, so that this kind of "advantage" can't be artificially induced by less-than-ethical players.
"If it happens to me, what is the result?"
The server-enforced re-positioning can be a bit disorienting. Your ship may go from facing one direction in one location, to suddenly being somewhere else and facing a different direction. For VR players, it could be particularly unpleasant.
This is exactly why we wanted to be extremely minimalist with how this system is triggered and applied. For instance, there's no reason for it to ever happen to people who are botting, or mining, or regularly flying around.
Similarly, this is a per-packet system, so even if you experience it once, due to a random dropout on the internet, that doesn't mean you'll continue to have problems. This is part of why we avoided the kind "ping-specific" suggestions I linked above.
This will be a WORK IN PROGRESS for probably some time to come
The full extent of this system quite complicated, well beyond what I'm discussing here. There are edge cases that came up in testing that required implementing fairly involved solutions.. but that's all beyond scope of this discussion.
We're likely to continue tweaking and improving the system, based on player feedback, as well as our own analytics. So, as always, don't take anything here as "cast in stone", we're continually interested in making the game better.
This thread exists so people can give real-world feedback.
Please test the new system and let us know how it works for you.
I'm sending a video via support ticket. Is this what the server-enforced re-positioning looks like?
Based on preliminary investigation, it appears that your issue was not related to this change at all.
Plus, if it happens to you, you'll see a chat message that says:
"High latency detected, resetting position."
Plus, if it happens to you, you'll see a chat message that says:
"High latency detected, resetting position."
nice improvement
Been having issues occasionally. Sometimes I'm in the middle of a bot sector and then I randomly start taking damage and then die. Same thing happened last night at Odia M14 when I was pvping Westacular.
Stavinar: Unless there is another player in that sector whose weapon fire was spawned within 3000m of you, prediction monitoring was not in play for you. If it were, you would see "High latency detected, resetting position." in your chat box. Are you seeing that?
Yes, let's keep this on-topic. This new feature is not the source of all mysterious problems seen in the game. A lot of those can just be explained by "the internet is a mess".
Please only respond here if you have completely read the original post at the top, and have a direct and specific comment to make about the Prediction Monitoring system.
Please only respond here if you have completely read the original post at the top, and have a direct and specific comment to make about the Prediction Monitoring system.
I was in an empty sector (exept for roids) testing the range of adv rails and got the msg
"high latency detected resetting position"
I checked my ping and it was 100
"high latency detected resetting position"
I checked my ping and it was 100
I'll throw in that I was having the same issue one night travelling from edras to dau, but didnt see anyone the whole way due to how late it was. I'm not sure what caused it, either (i normally have an incredibly stable connection, but that night i was having lots of slowdown on my upload speed), so i'll have to fiddle with things and see if I can't simulate the issue again.
anyways, point being, there *might* be some false positives going on for its engagement.
anyways, point being, there *might* be some false positives going on for its engagement.
This issue was fixed last night, but thanks for the reports. The system was being enabled too often, but the actual activations you encountered were "real", or would have been if another player had been present.
As a reminder, anyone can be susceptible to connection dropouts sporadically, which are not reflected in the "ping" rolling-average display, unless they're consistently bad over a period of time.
As a reminder, anyone can be susceptible to connection dropouts sporadically, which are not reflected in the "ping" rolling-average display, unless they're consistently bad over a period of time.
My connection has been behaving tonight as far as I can tell, so i'll throw this in here just in case its relevant. Around 10:40pm EST tonight, I destroyed Noblesol's trident, and was close enough for the explosion to cause an impact. I got a message about my latency when that happened and the force got canceled out.
Interesting. We are aware of that possibility. We did some heuristics to try and minimize the chances of that, but we'll have to do more testing.