Are they going to set the servers to a minimum of 60Hz now they have figured out many of the problems with the netcode? (no its not perfect but its far better than playing on 30hz still).
personally I think it should be the minimum standard from day 1.
There has been no confirmation on server tick rate for the game.
45 will be already enough, everything higher is only needed for competitive players
I think 45Hz will be the standard with options of 30,45,50,60 etc depending on your platform.
We saw in BF4 that 45Hz was the max safe zone for new gen console. Seeing that BF1 will have more destruction and new physics, lighting etc you can expect the min specs to be higher.
On the PC side you need to understand that the tickrate dictates the minimum FPS you need to maintain. This is because your damage send frequency is based on your FPS.
Playing at 72 FPS means you send damage data to the server at 72Hz. This is regardless the servers tickrate. Now say you are playing at 50 FPS on a 60Hz server. You are sending at 50Hz which is 10Hz lower than the tick. Death behind cover etc.
Hopefully Dice has corrected this for BF 1 and forces damage data to be sent at no less than the server tickrate.
Beyond this we have to look at player hardware limitations. I know I will have to get a new gpu for BF 1. I’ve milked my current to the last.
A lot of RSP’s currently don’t offer 60Hz tick on 64 slot BF4 servers due to the high hardware requirements to run that effectively.
I would not be surprised if 30 or 45Hz is the norm, especially on larger slot servers, but considering all the “netcode” improvements DICE LA have made via BF4’s CTE I would not see 30Hz as being downgrade, so to speak.
If 60Hz was forced I can already hear the future threads from people with slow datacapped Internet complaining in the distance. But yeah, nothing has been announced yet so we can either speculate on the future or just wait for it to be announced.
Server stability is the only major concern thus far I have for BF1. Even with all the improvements to BF4 the game is noticeably different depending on the server quality.
Base hardware testing should run as follows.
64p, largest or most demanding map, 32p with <= 75ms ping, 32p >= 150ms ping, 2 rounds back to back.
They should have a pretty solid baseline for hardware. Then bump that base by at least 15% for overhead.
*note this shouldn’t be done on a LAN. Need to see real connection issues and packet loss.
There were plenty of tiered real life tests done for this as part of the High Tick Rate CTE Initiative. You may still be able to find the results on the CTE Subreddit.
Yeah I remember those. Good tests, but there wasn’t any hardware or resource upgrades made on the GSP level. I do understand the limitations and boundings of the EA/DICE/GSP contracts. As well as the Hardware/resource cost increases to the consumer etc.
Just saying these tests need to be done again in light of the upgrades in the game.
A 64p 30Hz server requiring 27.3ms to process a tick is quite gross.
I think the aim was to increase the tick * without* any hardware upgrades. I personally have not seen any RSP that has been able to comfortably run a 64p server @ 60hz.
That said, who knows what fiurther upgrades DICE have made to the network stack etc for Frostbite
The where a few post holiday performance software patches (server side) aimed directly at resource management if I’m remembering correctly.
I haven’t either. NFO won’t even lease 60hz over 48p.
I’m sure there’s been a nice clean up done and they’ll get it right.
Yeah, tick rates should be universal according to “time” and not “FPS”, but I don’t know enough about this to put my .02 cents.
Just my thoughts, which are not rational, just random… for entertainment ONLY+
Let’s say you are running your game at 120 FPS on a 40Hz server, which is 3 times lower. Could the tick rate decide that 120/40=3… and somehow send information accurately regardless if the FPS doesn’t match? Something done on the client end, not the server? So if the sever updates at 40 times a second, can the client take that into account and somehow update at the same rate, knowing 40+40+40=120 so take the upcoming data, with the current data and give you an in-between rate based on the known speed and trajectory that is set for the weapon and the players actual speed in-game? Or, is that too hard to achieve knowing what we know about the game’s physics?
Just trying to wrap my thoughts into words:
This is even worse than the above thought…LOL
Sorry if this next segment is confusing, just trying to explain what I’m thinking using a keyboard instead of a drawing.
“So instead of using the sent information from the server tick rate in the “first set of 40 frames” (40/120 interval), calculate the upcoming interval, from the “third set of 40 frames” (120/120 interval) , and process it at the middle interval… which is the “second set of 40 frames” (80/120)… in other words, let the client decide when it’s best to process the data so it matches his frame rate to the tick rate according to his settings without losing any data based on the upcoming refresh rate? So in the above scenario, the tick rate is 40, but the client is 120, so process it at the clients 60 FPS mark, which is half of frame rate!”
Again, its hard to put into words, my apologies.
lol!!!I would not see 30Hz as being downgrade!!!hello planet earth!!!
What you would want is to get away from using FPS as a dictator and force outbound (client to server) damage data at the tick rate frequency.
Little more in depth insight … 60Hz example
You only receive data at 60Hz when in the High Frequency Update cone (HFU), outside the HFU is still 10Hz. Damage data coming to you is at 60Hz. The client also sends base info to the server @ 60Hz. Only your outbound damage data is currently based on your FPS.