• Fallout 76’s Physics are tied to Framerate
    103 replies, posted
Reminds me of the good ol' days of C&C: Red Alert. On a 133MHz Pentium chip: Runs a'ight. On a friend's 733MHz Pentium III: the slowest units are suddenly teleporting across the map and tanks are machine guns.
So how does one display loose objects in their abodes? Is it entirely impossible now?
I haven't seen any of the house stuff. Are houses like separate loading zones? Well I can imagine 2 scenarios: 1 - Things will load in the position they were in when you entered the zone, but if you move them around only you will see it. 2 - Object positions won't sync or save at all, and every time you enter your house will be free of random objects But idk. Does anyone know?
Or "fast mode" in Simtower. Mid-90s PowerPC Mac: Reasonable speed. 333 Mhz PII: Okay days only take a few seconds. Its a little fast. Sandy Bridge i5: Annnnnnd that's a decade simulated in five seconds.
So thats what was causing it? Fucking hell i thought my game was haunted or something every playthrough
Imagine a dude running around at mach speed because he's looking at the ground like a Goldeneye speedrunner
I remember unlocking the FPS being an issue in GTA. GTA2, to be specific. Which is from 1999. And even back then it was kind of inexcusable given other games ran just fine at above 30 fps! It's pretty amusing Bethesda decided that fixing this outstanding issue was too much effort for a multiplayer title where having a higher running speed is massive advantage over other players. It's like they took don't fix what isn't broken to mean don't fix whatever's broken, just ship as-is because nobody cares anyway.
Saints Row 3's multiplayer does this, too. Synchronization is tied to framerate - the farther apart the framerates between the two people playing are, the more out of sync they become. I played Saints Row 3 on my beefy gaming computer that was able to pull 90+ fps easily, with my friend on his gaming laptop that struggled to pull 45. With us both in a car, whoever is driving would stop - but for the other person, the could would continue on for nearly 4 full car lengths, hitting everything in its way, before suddenly rubberbanding to where it had stopped. We had to solve that by having me turn on VSync to limit me to 60 fps, and he had to lower his settings to minimum to get to 60 fps. Once we did, game played like a dream. But we shouldn't have had to do that. I'm getting nightmare flashbacks to Freelancer multiplayer. In a nutshell, the server did no verification at all for Freelancer. It just assumed all clients were running identical logic. Combine that with modding, and if you had a client tell the server that there's 60 alien battleships outside the starting planet, the server would just go "yep that sounds good" and tell all the other clients about the 60 alien battleships outside the starting planet. I use Freelancer as an example of how to not do server/client netcode, to this very day.
I wonder if this is one of those things where the people who originally wrote the creation/gamebryo engine have long left bethesda, and they are stuck band-aiding things together because there are no employees with deep-level understanding of the game engine. Also this game has some really annoying marketing, my goodness
I will gladly pay 60 moneys for Fallout 76 in exchange for that sick miniature MG42.
Also an issue in VC and SA, where unlocking the FPS makes you unable to finish some missions as the cars/boats go slower. Haven't heard of it being a problem in IV / V though.
III/VC are fucking nuts on super high FPS https://www.youtube.com/watch?v=MoZKBEk_yTc This is VC running at 400-600FPS for example
It's simpler to code
no, you disable iPresentInterval because Bethbryo's implementation of vsync is horrible, and then you force vsync in the driver
This game literally exists because there was financial demand for it.
I remember playing San Andreas when dual cores were just coming out for the first time, and when I loaded it up on my brand new Athlon 64 x2 the game ran at super speed and was basically unplayable until someone released a dual core patch for it. Good times.
Oh yeah, that's true, I totally forgot! I got Vice City to run at 300 fps on my shitty laptop and everything was broken. Even the clock ran too fast. Fadeouts would generally not just work, car handling turned super sticky and made drifting and reversing impossible and all the stunt jumps were completely undoable because physics were also tied to the framerate and you could hit a ramp at full speed and barely get any air out of it. Rockstar really is a special case when it comes to PC versions of their games.
I think they saw PUBG and Fortnite and went to the drawing board and went right, how can we slap together something out of what we already have to closely resemble that
Hell even modern insanely popular games have problems with this, for example a rank up mission in the popular f2p game Warframe had the objective that you had to out dps a constantly regenerating target while enemies were chasing you around, but if you had like 40 fps or under you literally couldn't out dps it, and if you unlocked your framerate you could almost oneshot it
Why isn't anyone mentioning that framerate independent physics has been a thing since, like, 2003 with the source engine? That makes it an even bigger embarrassment Imo.
That's not entirely true. There are source games that have a locked tickrate: https://files.facepunch.com/forum/upload/218604/db3eeebf-6199-41c4-881a-ac5c5613e3d3/image.png Source Multiplayer Networking
well it's framerate independent, isn't it?
I'm not sure what you're trying to say, it doesn't go against the statement that the in-game simulation rate is independent from the graphical refresh rate.
That doesn't contradict what they said, in fact that is the very method that source uses to decouple physics from framerate. Tick rate is a constant "this is how many ticks are called per second." It's independent of framerate so if you have a tick rate of 60 but you get 20fps, the engine still gets 60 ticks per second to perform the relevant updates.
Yes, but if you change the simulation's frame rate in TF2, spawn doors will open at a different speed. Thus the physics are not framerate independent. But after your post I realized he wasn't referring to the physics framerate at all and I misinterpreted his post. My bad.
As far as I can tell, dropped items in Fallout 76 spawn as little bags no matter what. At least, that was my experience in the beta. Which would mean that you can't decorate your homes with inventory items at all.
Maybe we can put stuff on on shelves inventory and then those items will be displayed? I mean if we got no way to decorate our CAMPs with junk then why do we have so many interesting looking junk items and so many different variations even of something like the teddy bear.
I think it's worth noting that Bethbyro games have never really 'officially supported' the whole playstyle of dropping interesting inventory items off at your home. The reason I say this is because, aside from weapon/armor display racks, even in singleplayer it has infamously been a massive headache trying to stack items on shelves and display physics objects. The engine just simply isn't designed for it, so it wouldn't overly surprise me if Beth honestly doesn't intend on players displaying random junk objects in their home when it comes to multiplayer. The junk is all detailed and varied because Bethbyro games just have heaps of detailed and varied junk. They're meant to be immersive singleplayer worlds, not multiplayer ones. All that being said, if it doesn't exist in the game already, I'm sure 76 will eventually update to include a mod very similar to Fallout 4's OCD decorator, where players can convert junk into furniture items. It's the only way I can see displaying physics objects feasibly working in this engine.
Kinda late here but one reason is it can prevent jittering. Say you're walking in the game and the physics tick rate is 50 Hz, but your framerate is 60fps. You're going to get frames where the physics hasn't ticked yet so the player hasn't "moved" from the last frame, thus making it look jittery. Of course for this example there are basic ways around the issue, and in the example you mentioned (and is FO76 here) it's just a case of bad programming.
Screwing up physics by changing the tick rate does not mean they are tied to frame rate. It just means that they're tied to the tick rate, which isn't really a problem because the tick rate doesn't change based on performance like frame rate does and is usually never meant to be changed from it's default value.
Sorry, you need to Log In to post a reply to this thread.