When you say lag you most likely mean latency is massive (input delay). This is because nowadays it uses "Dynamic Turn Rate" control and this means you have no way of setting a minimum boundary, meaning if the game decides you have a "poor connection" it will put TR to 8 meaning your best scenario will be TR8-Low ("Low" being the latency settings you can manually set).
Blame Blizzard for adding such a crappy system.
It might work using VPN to fool the system. MAYBE.
On April 27 2022 17:21 MeSaber wrote: When you say lag you most likely mean latency is massive (input delay). This is because nowadays it uses "Dynamic Turn Rate" control and this means you have no way of setting a minimum boundary, meaning if the game decides you have a "poor connection" it will put TR to 8 meaning your best scenario will be TR8-Low ("Low" being the latency settings you can manually set).
Blame Blizzard for adding such a crappy system.
It might work using VPN to fool the system. MAYBE.
Oh so that’s what turn rate is?
So you could be say, locked into the equivalent of a 300ms response as the best case for a whole game, based on what it determines your turn rate is upon initial connection? Even if your ping improves to something more playable that game?
Is there a reason or a benefit of doing it this way? I don’t recall encountering a game doing this, or at least not one where the turn rate or equivalent is displayed to the user.
Ive actually no idea how Turn Rate is implemented.
Turn Rate = Information speed.
Latency Setting = basically a buffer of information. Higher latency settings = more buffering = worse response. Like saying "Lets settle for 500ms response and try to keep buffer filled for this amount of latency. If buffer at any point gets empty it will "lag" and if lagging enough time the lag screen will popup.
I could be very wrong about this but thats my guess :D
Dynamic turn rate is pretty garbage for the following reasons: - it starts with too high of a turn rate so the game is not smooth, not fastest speed (unless it's TR24 low). In practise, I start with TR20 low which is too much, so I need to fix it and set it to high lat, and after a while the turn rate will improve to TR24 high lat, which in my case is the desired outcome. However, there are other cases where it's more annoying, example: a player starts with TR12 low, as it's not smooth speed, he changes it to high lat; after a while, turn rate improves to TR14 high and then TR16 high and AGAIN the game is not smooth. So basically whoever set these bars is at fault, for the numbers were wrong, too high. - DTR is too much lag spike dependant. If you have a lag spike, where your connections gets worse, let's say, from 200 ms to 270 ms for a 0,1 second, DTR will fall. If the situation repeats, you downgrade to TR8 low basically. The sensor is too sensitive.
As for the statements above, turn rate does improve, but i'm not sure if it can improve all the way up from TR8 to TR24 though.
On April 27 2022 20:05 Bonyth wrote: Dynamic turn rate is pretty garbage for the following reasons: - it starts with too high of a turn rate so the game is not smooth, not fastest speed (unless it's TR24 low). In practise, I start with TR20 low which is too much, so I need to fix it and set it to high lat, and after a while the turn rate will improve to TR24 high lat, which in my case is the desired outcome. However, there are other cases where it's more annoying, example: a player starts with TR12 low, as it's not smooth speed, he changes it to high lat; after a while, turn rate improves to TR14 high and then TR16 high and AGAIN the game is not smooth. So basically whoever set these bars is at fault, for the numbers were wrong, too high. - DTR is too much lag spike dependant. If you have a lag spike, where your connections gets worse, let's say, from 200 ms to 270 ms for a 0,1 second, DTR will fall. If the situation repeats, you downgrade to TR8 low basically. The sensor is too sensitive.
As for the statements above, turn rate does improve, but i'm not sure if it can improve all the way up from TR8 to TR24 though.
The first point here is pretty accurate (and I'll explain more below). As for the second point, this explanation was sort of my expectation too, but from doing a lot of testing, DTR being bad isn't actually related to it being too "spike-dependant". It tends to adjust fairly quickly to spikes (up or down) and doesn't really get stuck for those reasons. DTR is bad because it almost universally picks latencies that are not consistently achievable given the players in the game.
Unless all of the players in the game can achieve TR24 to each other (~126ms roundtrip latency) or you're absurdly lucky with where the latency falls, the values it chooses will cause micro-stutters multiple times a second. These stutters are largely why players feel that e.g. TR12 is terrible to play on, imo, and why Koreans will refuse to play on anything but TR24. On ShieldBattery, we moved away from DTR entirely because it is unable to deliver a good experience, and I think people have generally been a lot happier with our solutions.
I'll have a longer form post about this at some point (and BW netcode in general), but I did take a video of a modded version of the game that illustrates micro-stutters, and that pretty clearly shows how bad the choices of DTR can be:
EPT
![[image loading]](https://i.imgur.com/HagxdDc.jpg)
