Game speed tied to fps?

[Artrysa]

I heard that the game speed is tied to fps. Is this a one to one ratio? Like 60 fps is normal speed, 120 is double? I play on 120 but it doesn't really feel like it should be half what is it now.

[Wolfsun]

FPS and the way rag doll falls work are tied to each other. If FPS goes over 60 then rag doll falling graphics supposedly go crazy. There is a mod on nexusmods.com that will fix that.

[mikk011]

Most long time BGS players strongly recommend sticking with 60fps. Physics and scripting are tied to framerate in this engine. Every time you increase your fps, you decrease the update time available for these, which can and does lead to errors (bouncing objects, wonky ai behavior etc).

Working edits and mods exist to run higher framerates, but are totally use at your own risk, and if cumulative errors muck up your save they cannot be repaired. And if you run higher fps without the fixes you will experience dropped or broken scripts and weird physics even sooner.

[sdack]

Terminals and lock-picking will also go crazy. I.e. the bobby pin will move too fast and become uncontrollable.

High FPS Physics Fix and Load Accelerator - https://www.nexusmods.com/fallout4/mods/44798

Not only does the mod fix this issue, but it also comes with a load accelerator and it increases the text speed on terminals (text displays quicker, maglock doors open faster, etc.), which is a nice feature.

[Vomit Heart]

Game runs at 214 fps average for me with the High FPS Physics Fix and have not had a single bug.

[Artrysa]

Wait, so it is mostly just the physics engine that gets problems from high fps?

[ZarahNeander]

Originally posted by Vomit Heart:

Game runs at 214 fps average for me with the High FPS Physics Fix and have not had a single bug.

The problem is the way, scripting is tied to fps. Basically every vsync the scripts get a certain amount of time to do thier thing. More fps == less time. This isnt a problem, as long as you dont run script heavy mods (i.e sim settlement). But if a script doesnt have enough time to finish, it schedules the unfinished part to the next vsync. If this happens often enough, the engine start to choke and eventually crash

[hawkeye]

The game speed is constant like other games. But there are some issues that going above 60 fps can cause. The Havok physics engine sometimes misbehaving is one.

The script issue is not strictly-speaking a 60 fps issue but more an issue caused by insufficient cpu performance, regardless of the fps above or below 60 fps. The recommendation for Skyrim SE was to cap fps to a level below the maximum fps that the hardware could reach.

These issues are more correctly frametime issues and not fps issues. Frametime is the time it takes to draw one frame. Fps is an average over time.

[=EGC= kansasterry]

To help with scripting issues/limits

Baka ScrapHeap - Script Memory Limit Expander
https://www.nexusmods.com/fallout4/mods/46340

[Scyobi_Empire]

"It just works"

[Artrysa]

Originally posted by Scyobi_Empire:

"It just works"

They're fun games, but ♥♥♥♥ me is it ever a mess.

[Lucifer69]

Basically any time a script has to either request/submit some data from/to the engine (i.e. any native function call that is not non-delayed, which is to say like 80-90% of them), the script has to wait until the next frame for that function call to finish. More accurately, the engine can do one native delayed function call per object per frame. If you have some script that runs 10 delayed functions, you guessed it, that'll cost a minimum of 10 frames, provided no other scripts are running on the same objects. If you're at 10 FPS that'll be 1.0 second, 60 FPS it's 0.167s, 144 is it's 0.069s and so on.

Multiple scripts on the same object are even worse, basically each delayed function call takes a "ticket" and the engine handles each call in the order it was made; so, two 10-function scripts that start running on the player simultaneously, for example, will typically run "function A, call 1", "function B, call 1", A/2, B/2, A/3, B/3...and so on to A/10, B/10.
If there were a 10-call (A) and 100-call (B) function in the same circumstances, calls from functions A and B will behave similarly: A/1, B/1, A/2, B/2...until A/10 finishes around frame 20, and function B is free to run B/11, B/12 etc uninterrupted, finishing around frame 110.

There's also another overall limitation on how long the engine will dedicate to the Papyrus VM per frame, shared across all currently running scripts, which is typically 1.2-2.4ms (fUpdateBudgetMS + fExtraTaskletBudgetMS ini settings). This is typically only relevant when there are either a lot of scripts running code simultaneously (like 30+), or some compute-heavy pure Papyrus threads going on, but that sort of code is rare.

Technically it would probably be best to scale these down with framerate because the default settings were targeting max 60 FPS, where Papyrus is allowed up to 14% of overall frame time. At 144 FPS that's bumped by 2.4x to 34%. In reality I don't think it's a big deal.

The inherent instability of the game's framerate + interference from other scripts means that any sanely written script cannot rely on inherent script engine delays to work because you can never know how long a script is going to take to execute other than "at some point in the future". So if timing is important then your script must use one of the following:

--events
--timers via StartTimer()/StartTimerGameTime()
--manual delays via Utility.Wait()/WaitMenuMode() (often combined with some form of
--polling to wait for something to happen)
--manual timing via Utility.GetCurrentRealTime()

None of these are affected by FPS in any meaningful way.

Any other delay in a sanely written script is pretty much just an annoying thing that you have to put up with because FO4's script engine is, generally speaking, very slow—and it follows that increasing FPS, which speeds up the script engine, is strictly a positive thing. As far as I know, all official scripts can handle whatever FPS without issues, so the only place where faster scripts might break something would be in (very) poorly written mods.

TL;DR; Yes, scripts are faster at high fps and it's a good thing.