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. None of these are affected by FPS in any meaningful way.Īny 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. manual timing via Utility.GetCurrentRealTime() polling to wait for something to happen) manual delays via Utility.Wait()/WaitMenuMode() (often combined with some form of timers via StartTimer()/StartTimerGameTime() So if timing is important then your script must use one of the following: 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". In reality I don't think it's a big deal. 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.
![fallout 4 fps fix mod fallout 4 fps fix mod](https://img.republicworld.com/republic-prod/stories/promolarge/xhdpi/6crvhlbajs8qrbal_1600753912.jpeg)
![fallout 4 fps fix mod fallout 4 fps fix mod](https://cdn.mos.cms.futurecdn.net/Dzna5Ks9j8DK8aM4UGFUzj.jpg)
#Fallout 4 fps fix mod code
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. 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).
#Fallout 4 fps fix mod free
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. 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 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. 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. More accurately, the engine can do one native delayed function call per object per frame. 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. Basically any time a script has to either request/submit some data from/to the engine (i.e.