At least in BF1 you could rent servers, this game started off broken and has become the quite probably the worst game of the franchise so far.
No probs. My discord channel is linked in my sig. We mainly do game dev stuff there, so if you have questions or just want to hang out drop on by.
@RevOverDrive
DICE could do with you expertise buddy. I’m sure you can sort out the game for them!
Will do, thanks very much pal
When then this happen have not played in a month, came on to play the new map and german server is laggy mess and characters are freezing and shots don’t register. They better bring back the servers in the UK or not buying the next game. Battlefield needs decent servers.
I’m talking about renting servers from a UK family run business like Multiplay instead of EA who gets them from Amazon. It’s a completely different relationship that the renter has with a company like that. Plus renting a server off EA you still get the same netcode.
Whatever science you want to blind us with it doesn’t change the fact that there are less data centres now and the “netcode” is only going to change in order to cope with that strategy if at all.
Maths and science that explains what’s best for players doesn’t have any influence with big businesses or they wouldn’t have changed it from BF2 to the way it is now.
Rev0verDrive said:
DICE/EA do not have any control over data routing whatsoever. You need to contact AWS for more information on their routing.
The following links provide “reachability” IP’s for testing Ping and Tracert for AWS EC2 and GameLift servers.
http://ec2-reachability.amazonaws.com/
https://docs.aws.amazon.com/general/latest/gr/rande.html#gamelift_region
Further information on AWS GameLift : https://aws.amazon.com/gamelift/faq/
Data Centers use “Peering”. Buying direct connections to many tier 1 providers, such as Verizon, AT&T, Sprint, GTT/tinet, Verio/NTT, CenturyLink, and Telia, and choosing the best path to reach clients through a proprietary system.
You may also want to ask AWS directly about their Peering.
The route in is typically the route out, unless there’s congestion, or the route out is the better option.
Each Gateway (HOP) along the route can redirect packets onto alternative routes.
Ping in-game does not use ICMP. Each game data packet you send is timestamped in the header. The server and the client read those timestamps to calculate RTT.
((float) send time - (float) receive time) * 2 + (float) processing time = ceil(Ping).
The travel time of an ICMP packet is irrelevant. ICMP does not have a payload ..aka Game data. Game data packets (relevant) are what’s used for ping and they are UDP.
*** Note
-
The network graph is only updated once per second. Processing ping, loss etc is low priority. This may add ~1ms to overall ping values displayed.
-
IP Fragmentation … https://en.wikipedia.org/wiki/IP_fragmentation
Although game developers try to keep payloads as well as overall packet byte sizes low they can still be fragmented in route. If a packet is fragmented it can add toward ping times.
FYI there are multiple virtual connections (UDP) as well as multiple direct connections (TCP).
- Game Session, EA Backend, MM
- Client → Server movement updates (primary game data)
- Client → Server RPC’s (kit changes, healing etc)
- Server → Client movement updates/corrections (opponent and self - various update rates)
- Scoreboard
- Network graph
- text Chat
- Kill feed
- voip
- etc …
I highly doubt the issues at hand are caused by AWS (hardware,software,network infrastructure etc). And I’m highly confident AWS wouldn’t allow overburdening/misuse of a physical server (their hardware). So you can pretty much eliminate them and their service from the equation.
As far as a netcode change … no clue. I wouldn’t know for a fact unless DICE or Mischkag posted about it. Which I haven’t seen other than TTD replication tweaks (February patch). But as a whole I don’t think any major component from the BF1 netcode has changed in BFV.
As noted in other posts the best way to narrow down / troubleshoot the issues is to have all players on the server at low and stable pings (sub 60ms). This will be doable come rental release. You’ll just need a large group of players dedicated to testing. I’m already confident in the results.
Additional note…
Shots and Damage receival aren’t tick based. They are RPC event based. This simply means they are processed and sent immediately…not batched and sent at ticks.
Link to section: Well there is a noticeable difference which occurred exactly when they switched from UK to Frankfurt servers, where server performance feels worse than you would expect simply because of being re-routWell there is a noticeable difference which occurred exactly when they switched from UK to Frankfurt servers, where server performance feels worse than you would expect simply because of being re-routed to Germany. I think being consumers we don’t expect to be on the receiving end of the consequences of this decision, the cause is something that Dice should be looking into. Whilst it might be unlikely that the actual AWS hardware is the cause, I wouldn’t eliminate it altogether unless comprehensive testing is done.
If it is ISP routing or hop related, then it must impact a number of mainstream internet providers because alot of UK players have noticed it AND other European players who previously use to play on UK servers. Naturally there is little we can do about that, but Dice can by reverting back to UK servers. This is also the logical remedy if it concludes that Battlefield servers are going to pot when the high/unstable pings have a negative impact on the game, given every European player is now in Frankfurt we have already seen the mean ping increase, this what I think the root of the problem is, but Dice aren’t going to go back on this decision because they value match making times above the quality of gaming experience. The sticky experience from the Frankfurt servers has been acknowledged by a wide range of players using them.
This one is for RevOverdrive. Often the term netcode is thrown around, but am I right in saying it is basically a generic term for anything related to gaming networking, particularly the synchronisation between the server and the client, and there more there are many possible causes for bad netcode to be present?
The ticks you refer to above are sent at the tick rate of the server, so the higher the tick rate the more responsive experience you will have? Lesser tick rates increase the likely hood of the “one frame kill” experience?
I’ve seen bad synchronisation with this game beyond any doubt, no idea what the causes it but would throw me off playing any game. One example of this is when I am shot at from mid/long range by a player (G43 for example). I’ve received hit indicators from each shot and damaged taken off my health the instant I see the muzzle flash. I can then track the tracer fire of the shot in slow-mo frame by frame, but I cannot evade the shots and they’ve already inflicted damage according to the server. Same occurs in tanks, taking damage from shots which go over or behind me after moving yet I take the damage of the shot. There are other examples but I wanted to mention one than is not often spoken about or perhaps not even recognised.
Tonight the game has hit new lows in playabilty. Stutter, lag, rubber-banding, hit reg all over the place even in SC
Yup
I made a concerted effort to not bother tonight and probably for the foreseeable future.
Having a blast on apex and planet side 2
Renting from Multiplay, NFO, GameServer.com etc doesn’t result in “different” netcode. The only upside is you get more choice in server hosting locations. Which potentially lowers your ping. But it’s only better if “ALL” players on the server have a low ping. You can rent a server in NY, Dallas, Chicago, London etc, but if you allow for global play (no ping limit) you’ll experience the same issues 100% of the time.
BF4 offers 3rd party rentals from private GSP’s, yet you still get: insta deaths, one frame deaths, hits behind cover, denied hits etc. But this only happens when the server is inundated with bad connections. You take a BF4 server and ping limit it and it’s flawless.
For BF4 you can use Latency Manager plugin for procon. https://forum.myrcon.com/showthread.php?5782-Latency-Manager-(1-0-1-16)-January-2017
=============
When rentals come for BFV you can easily start one up for free and kick players over 60ms to test this.
If that’s too much math and science for you I don’t know what else to tell you.
Rev0verDrive said:
DICE/EA do not have any control over data routing whatsoever. You need to contact AWS for more information on their routing.
The following links provide “reachability” IP’s for testing Ping and Tracert for AWS EC2 and GameLift servers.
http://ec2-reachability.amazonaws.com/
https://docs.aws.amazon.com/general/latest/gr/rande.html#gamelift_region
Further information on AWS GameLift : https://aws.amazon.com/gamelift/faq/
Data Centers use “Peering”. Buying direct connections to many tier 1 providers, such as Verizon, AT&T, Sprint, GTT/tinet, Verio/NTT, CenturyLink, and Telia, and choosing the best path to reach clients through a proprietary system.
You may also want to ask AWS directly about their Peering.
The route in is typically the route out, unless there’s congestion, or the route out is the better option.
Each Gateway (HOP) along the route can redirect packets onto alternative routes.
Ping in-game does not use ICMP. Each game data packet you send is timestamped in the header. The server and the client read those timestamps to calculate RTT.
((float) send time - (float) receive time) * 2 + (float) processing time = ceil(Ping).
The travel time of an ICMP packet is irrelevant. ICMP does not have a payload ..aka Game data. Game data packets (relevant) are what’s used for ping and they are UDP.
*** Note
-
The network graph is only updated once per second. Processing ping, loss etc is low priority. This may add ~1ms to overall ping values displayed.
-
IP Fragmentation … https://en.wikipedia.org/wiki/IP_fragmentation
Although game developers try to keep payloads as well as overall packet byte sizes low they can still be fragmented in route. If a packet is fragmented it can add toward ping times.
FYI there are multiple virtual connections (UDP) as well as multiple direct connections (TCP).
- Game Session, EA Backend, MM
- Client → Server movement updates (primary game data)
- Client → Server RPC’s (kit changes, healing etc)
- Server → Client movement updates/corrections (opponent and self - various update rates)
- Scoreboard
- Network graph
- text Chat
- Kill feed
- voip
- etc …
Yes, Netcode is a blanket term that covers all code/algos/events communicated through the network between client/server. Any function and or class involved with the replication of data between the client and.or server is netcode related, thus covered under that term.
Tickrate is the heartbeat of the server. It determines the highest frequency in which data can be replicated. It mainly stipulates the rate/frequency in which the client (us) update the server with our movement inputs. Such actions are not immediately sent to the server on client execution. They are batched and sent at tick. Thus the movement and position of all players in view (on your screen) are subject to delay. Tickrate, replication rate, your ping, their ping.
Higher tickrates decrease the delay between input replication from you to the server. This increases the servers precision in movement and position calculations. The lower the delay (higher tick) the greater the precision. Yet this only really benefits low ping vs low ping game play.
30Hz Tick has a 33.33ms interval, thus you only update the server with your movement inputs once every 33.33ms. 60Hz tick has a 16.67ms interval… A reduction of 16.667ms in delay. 120Hz …8.33ms
Calculating the exact delay between 2 players depends on the tick rate, replication interleave frequency and both players pings. For example on a 60Hz BF server with both you and your opponent having 10ms pings and you’re within 30m of each other your ballpark delay is 27.667ms
(Tickrate 60Hz (16.667 delay) + 5ms UTT, + 5ms UTT, + ~1ms processing).
The vast majority of delay here is the replication rates and server processing. 16.667 + 1
Take the same scenario but increase your opponents ping to 250.
(16.667ms + 5ms + 1ms + 125ms) = 147.667ms delay
The vast majority of the delay comes from your opponents latency. 125ms to be exact.
Only within 30m will you get updated at the full 60Hz. Beyond 30m the replication interleave frequency degrades (as noted in earlier post with pics).
Bad synchronization/Desync is a byproduct of latency. The only “Fix” is to lower pings off all players on the server below a set threshold. The best threshold is sub 2* tick interval.
====================
Not all replication is tick bound. Shooting, infield kit change, grabbing ammo/meds. These are event based which basically means when you execute the action a packet is sent to the server immediately upon execution. The only delay here is your latency (50% ping …UTT). So for example you take a shot, your client immediately sends the server a packet so it can replicate that action to other players. Thus they see you fire a shot. If the server determines a hit then it immediately sends damage info to the hit player and ui updates to you (blood splatter).
One frame hits as you described are latency based. If your opponent has a 250 ping and you a 10ms ping then you immediately have 130ms of delay on hit notification on your end. That’s not counting server processing, your client processing the packet, GPU rendering and input delay (gpu → monitor). This is typically around 21ms +.
So basically at the end of the day you need to look at your opponents ping. Divide it by 2 to get his/her Update Travel Time (UTT). This value shows the absolutely base minimum amount of action delay between you and them.
30ms = 15ms UTT, 100ms = 50ms UTT, 200ms = 100ms UTT etc.
So when a dude with a 200 ping fires a shot by the time the server receives his shot packet it’s already been 100ms.
=============
Covering the logic behind hit detection and why high ping players shots “legitimately” hit and count requires its own post…thread actually.
DICE made guns more accurate in BFV. Bullet spread was virtually eliminated in BFV and replaced with the new recoil system.
Most guns in BFV have low recoil so most bullets are landing on target. Causing 5-6 bullets to slam into players and kill them in 200 milliseconds. Getting 5 damage indicators in the span of 200ms is going to feel like a insta-death.
The insta-death feeling happens in BF1 too, but usually from prone LMG players using bipods. Allowing them to fire full auto with minimal recoil and spread.
With BFV’s more accurate weapons, it’s like everyone is shooting laser beams at 600+ rounds per minute. By the time you get the first damage indicator, a train of bullets are right behind it ready to slam into you.
To allow players time to react to damage indicators, either recoil or spread needs to be increased. The rate of fire on weapons reduced. Or bullet damage reduced.
Personally, I would add more spread and reduce the rate of fire.
@Rev0verDrive Thank you for taking the time to share your knowledge and explain things like tickrate. Reading your comments is helping me to develop a basic (very basic) understanding of topics that normally go over my head.
Thanks for the input, I appreciate the info there RevOverdrive 
Glad it helps. Always welcome to join discord. I have plenty of in engine demos that cover most topics.
The strange thing about this is: even on small game modes (16-32 players) and all having a ping below 60ms the game feels like crap, ttd bug still happening and shots not registering, footsteps missing, etc.
There might be one or more players with lots of latency variation, but all below 60ms ping.
So maybe a ping limit/kicking all players with ping above 60ms might fix everything …
What else can it be?
Also strange is: I changed the DNS of my PS4 from the one of my ISP to a different one (the fastest/best that came out of an app to test that) and the game feels a lot better, even menus load faster etc, what does that tell you?