[NEW MERCENARIES] Please note that all new forum users have to be approved before posting. This process can take up to 24 hours, and we appreciate your patience.
So what exactly do the bars represent? The answer is not as obvious as it seems.
I am from Aus and joining US boats gives me 1-2 blue bars and unless the host is a potato and everyone lags, I generally get no lag at all. I can do the hooks in Abomination just fine, and I can even do Neam without any deaths fairly consistently; 2 deaths in the last 12 runs.
However, I know a few Aus hosts who give me 4-5 blue bars but lags (rubber banding type) even if it's a duo run.
And I also have experienced a few runs where the whole party was on 1 red bar the entire time but didn't lag at all.
So from what I experience, lag does not always correlate to bars, hence bars is not ping and color is not latency, so what do they actually represent?
And in case it matters, my graphics settings is on custom; model, shader, lighting and texture are high; shadow, animation, physics, particles are low; streaming, multicore enabled; the rest disabled.
Kommentare
The red color could indicate a delayed bar refreshing or something like that because it's usually just blue and red and nothing else.
But this is just my theory.
i've been in boats where the host had only two bars, and i've had no lag.
maybe it's time to merge eu and na... and open the game up to south/central america and the philippines +fight
bienvenidos and mabuhay
for me it's always been
2 bars = extreme lag
3 bars = playable with some lag spikes
4-5 bars = super smooth
if you lag at 4-5 bars its most likely your own internet connection acting up
Same as this. And performance can affect your bars as i have seen so you can have low lag but low fps and your bars wont be 5-4
And 1 bar is abysmal.
Also not to mention as an arisha player lag can affect your skills ( warp doesnt teleport you to proper position, warping stops midway, resonance fails to cast despite animation still activated, rb doesn't work properly... etc )
The above reflects my own experience. Whenever I have 1 bar, my inputs are always noticeably delayed (high latency) but the gameplay generally remains smooth and predictable (no loss). On the other hand, sometimes I have 4 or 5 bars and rubberband all over the place with highly unpredictable character movement (signs of probable loss or general circuit quality issues, irrespective of latency).
Hope that helps.
Being positive and thinking they do the measurements for the bars with test tcp packets and not icmp (ping) packets it should show the exact performance of the host. So one thing that remains is the minor frequent performance fluctuations (lag spikes) before the bars get updated or they are accidentally updated between the lag spikes (because lag spikes can be evenly repeating too), so you see it as if it was a full bar. Also if the packets are handled in thread pools that will make it even more complicated.
It doesn't happen so often and for long, so the bars more or less work fine.
You can also rubberband on 5 bars because it's not just the network delivery times that counts but also the host's and your machine's load that constantly fluctuates depending on player activity and countless other things, like the game's internal process threads that are waiting for each other or they are near deadlock/livelock situations. The latters are common slowing factors in multi-threaded games. They (or at least the deadlocks) show no sign of cpu load because they do the opposite of that. A livelock can consume the cpu but it depends on the implementation. And it's a pain in the a** to find out where they come from. And they are usually difficult to reproduce.