Forum Discussion
I just learned about someone who's running into the same trouble OP has mentioned. What you just described makes sense.
However, I am curious about the 30hz on community servers. When I go and host, I'm given the option to host locally. I am assuming that means my PC is the host (with a relay system).
So, I have two questions I'm curious if you know:
- Do locally hosted community servers also send at 30hz?
- If they happen to be faster, is there a way a user can differentiate between which community servers are locally hosted or not?
I want to add onto your statements with some speculation (READERS: ITS WHAT COULD BE HAPPENING, NOT NECESSARILY IS):
When I've done multiplayer code with games that have physics, I would rollback the entire physics world to the last ACKed frame when the client detects a desync between itself and the server. Then, I would replay all player inputs + step the physics world until we get back to the present frame. I would often find this is the most CPU intensive mechanism in the entire client. Old school games such as Quake would only rollback the player's character, which isn't good enough in many games today.
So if Battlefield is doing something similar (and I have a decent feeling they are since there's vehicles), if you're already dropping frames, this mechanism could trigger a death spiral.
Ok now just some mostly unrelated fluff about netcode:
I really hope the devs release some kind of video describing their netcode techniques with BF6, it's quite interesting to me. Lately I've gained a lot of interest in doing all gameplay on a fixed tick, decoupled entirely from the renderer, this does indeed though have a tradeoff in that it can introduce input lag. But, in an FPS game you don't need to necessarily correct the client's rotation during a desync, so mouse motion and weapon firing can be done at a variable framerate, so it's really just the position of the character that would have a bit of input lag. The camera could be moved instantly by extrapolating, and certainly a few techniques you can use between those fixed frames. Further, I prefer doing it using an Entity Component System, because it makes it far easier to spread the load across several threads and actually take advantage of the CPUs design, without making it a pain in the **bleep** for developers to reason about.
PushThruCombat - Commenting to add that during the issues, there is a "step" graph that also spikes. I believe your theory is correct. I believe some CPUs cannot cope with this in a full 64 player chaotic match, causing the death spiral you speak of. It seems like if your system EVER drops one frame it cannot catch back up. This makes perfect sense because the game runs fine upon starting a match, but crashes and burns when anything (physics/explosion happens). Then it is stuck in the spiral and the result is an unplayable experience on any graphics settings.
What would be an actual fix for this, as you seem very knowledgeable.
About Battlefield 6 Technical Issues
Recent Discussions
- 30 minutes ago
- 34 minutes ago
- 38 minutes ago