the Sim Settlements forums!
Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!
SS2 with unlocked fps mod?
- Thread starter Josiah77
- Start date
- Messages
- 2,608
Papyrus Scripts are designed to run in a 60 fps allotment. To high of rate and you might hurt script performance.
adirondack9
Member
- Messages
- 75
My understanding is that game processing scripts are allocated just a few millseconds per frame to execute. They aren't linked to fps like the physics scripts. If they don't complete within that 1 or 2 millseconds then they queue to the next frame. Effects might be things like a settler not immediately responding to a job assignment or evena crash. There is a mod with more and better info about this in its description -
SKK Script Lag latency detector
Read the posts for this mod.Baka ScrapHeap - Script Memory Limit Expander
Some events triggera lot of scripts e.g. crossing the cell border of a settlement. The cpu load will be higher and if the cpu has been diverted to producing fps then script processing may suffer and potentially cause a crash pr fps will stutter.
- Messages
- 1,574
The high FPS fix mod takes care of the game mechanics side of increasing fps. I use the FPS fix mod as a replacement to load accelerator though and keep in game FPS capped to 60 , and in loading screen and black screens unlocked to it loads the game faster. My tv looks like ass though at anything higher then 60 FPS since it’s a 4k60 tv from a few years ago anything faster results in screen tear for me. I’m trying to replace it this year with a 4k120 oled.
There is no reason to cap at 60 if using High FPS Physics Fix at Fallout 4 Nexus - Mods and community (nexusmods.com) which works quite nicely, in fact more fps gives more time for active scripts to run and can help out script performance considerably. This sounds counter intuitive but consider that scripts supposedly have a set amount of time to run per frame, if you increase the frame rate then that increases the number of "windows" they have to run so long as you don't increase the frame rate so high that the window is no longer there (I've read 2.5ms). Frame times don't drop to under 2.5ms until a little over 350fps. This is why many people play uncapped in 3d and 350 is a good number to cap load screens at. I don't know of any reliable way to show this in terms of SS2 but transfer settlements will export the same settlement twice as fast at 120fps than it will at 60fps, and export time at 30fps is about half as fast as 60fps.
- Messages
- 2,608
This say otherwise
Post in thread 'Understanding CTDs in The Triangle of Death (Sanctuary, Abernathy Farm, and Red Rocket)' https://simsettlements.com/site/ind...abernathy-farm-and-red-rocket.6964/post-51354
No it doesn't aside from correcting me on the number of ms per frame, so its 1.2ms by default according to that. You seem to be thinking that rendering and running scripts can't occur simultaneously, they absolutely can and do as they are entirely different threads. So long as you don't run your fps so high that the 1.2ms (default) window per frame isn't shortened (this would have to be 700+fps) then the scripts are going to have time to run assuming you aren't using hardware from 1980.
a quote from one of the posts in that thread:
"According to SmkViper (here: http://forums.bethsoft.com/topic/14...lag-going-over-10000-ms-sometimes/?p=23340131 ), raising the frame rate actually reduces the amount of time the scripting engine has to process everything it needs to process in a single frame. So, at 30 fps, a new frame is being rendered once every 33.34ms. At 60fps, a frame is rendered every 16.67ms. At 144fps, a frame is rendered every 6.9ms. Remember, the default for “fUpdateBudgetMS” and “fExtraTaskletBudgetMS” (the number of milliseconds per frame Papyrus VM gets to work) is 1.2ms (2.4ms if you use the Performance values)."
---This is just bad logic. At 30fps the script window is open 30 times per second, at 144fps the window is open 144 times per second. Thats 72ms of runtime vs 345.6ms of runtime, which one is better? The transfer settlement times back this up, I don't know how SS2 city plan building is setup but I'm willing to bet its considerably faster at higher fps as well, unless KG throttled it for one reason or another.
- Messages
- 2,608
Apparently you didn't read this part, and maybe you should read it all again including your quote, you may think its bad logic but that doesn't make it wrong.
Lock your windows. Lock your doors. Lock your scripts. Lock your frame rate
Once a thread starts running a parent or child script, it “locks” that script until it is done processing, which prevents other scripts from accessing it and reading its variables. If the scripts are massive rats-nests of hundreds of different child scripts that all have to generate/update their variables every time (like WorkshopParentScript, unfortunately for us), and they use functions (these are the algebra/calculus equations that the Papyrus scripting language represents) that get the job done but run slowly (remember, slowly here is a more than a millisecond or so), this locking means that the parent script could take literally minutes to run. This means it could take many, many, many frames for Papyrus VM to eventually run the final parent script and perform the action you asked it to perform.
Frame rate is the key. Remember, Creation Engine was designed with a target and maximum frame rate of 60 frames-per-second for computers, and 30 frames-per-second for consoles.
If you are running too many scripts, they will eventually start to back up, which increases memory usage, which crowds out other things like the rendering sub-system, which slows down the framerate, which backs things up even more, until this cycle eventually chokes out the Creation Engine and, boom, crash to desktop. This is even worse if you are asking the rendering engine to render a bunch of high-resolution (i.e., lots of triangles), complex graphics.
Brute force only buys us time.
Lock your windows. Lock your doors. Lock your scripts. Lock your frame rate
Once a thread starts running a parent or child script, it “locks” that script until it is done processing, which prevents other scripts from accessing it and reading its variables. If the scripts are massive rats-nests of hundreds of different child scripts that all have to generate/update their variables every time (like WorkshopParentScript, unfortunately for us), and they use functions (these are the algebra/calculus equations that the Papyrus scripting language represents) that get the job done but run slowly (remember, slowly here is a more than a millisecond or so), this locking means that the parent script could take literally minutes to run. This means it could take many, many, many frames for Papyrus VM to eventually run the final parent script and perform the action you asked it to perform.
Frame rate is the key. Remember, Creation Engine was designed with a target and maximum frame rate of 60 frames-per-second for computers, and 30 frames-per-second for consoles.
- No matter how powerful your computer, Creation Engine cannot give Papyrus VM more than 2.4 milliseconds (1.2 milliseconds for consoles and users who do not modify their .ini file) out of every frame to run scripts.
If you are running too many scripts, they will eventually start to back up, which increases memory usage, which crowds out other things like the rendering sub-system, which slows down the framerate, which backs things up even more, until this cycle eventually chokes out the Creation Engine and, boom, crash to desktop. This is even worse if you are asking the rendering engine to render a bunch of high-resolution (i.e., lots of triangles), complex graphics.
Brute force only buys us time.
- No matter how powerful your computer, Creation Engine cannot give Papyrus VM more than 2.4 milliseconds (1.2 milliseconds for consoles and users who do not modify their .ini file) out of every frame to run scripts.
As for memory issues, Buffout takes care of them. All I can say is try it for yourself rather than depending on information that came out prior to highfpsfix and buffout's release. I would do a city build test to give you numbers but at this point I've played the SS2 questline to death and won't install it again until the next chapter comes out.
Anyway happy gaming, "its bad logic but that doesn't make it wrong", nothing more I can say here.
- Messages
- 4,447
This reminds me of when I installed Load Accelerator and edited the ini file. I thought "Why are they limiting load screen fps to 300?"
It turns out if you disable the fps limit, (to use the given analogy) render guy can to 2 extra lines of code, (fps spike) script guy spins in circles and gamer guy wonders why he gets random CTD on fast travel.
Moral of the story: if you use Load Accelerator or High FPS Fix, make sure you set an fps cap that is reasonable for your graphic card's power level.
i.e. I use 350fps as a cap for load screens with a GTX 1070. I suppose I could go higher, but I like stability.
It turns out if you disable the fps limit, (to use the given analogy) render guy can to 2 extra lines of code, (fps spike) script guy spins in circles and gamer guy wonders why he gets random CTD on fast travel.
Moral of the story: if you use Load Accelerator or High FPS Fix, make sure you set an fps cap that is reasonable for your graphic card's power level.
i.e. I use 350fps as a cap for load screens with a GTX 1070. I suppose I could go higher, but I like stability.
Last edited:
- Messages
- 4,447
@HyperLordBender recommended the Papyrus ini settings NOT be used.
As for fps, my gut tells me that playing a game where most systems are tied to fps that going over the default 60 fps is asking for problems. It falls into the YMMV category.
As for fps, my gut tells me that playing a game where most systems are tied to fps that going over the default 60 fps is asking for problems. It falls into the YMMV category.
sranger
Active Member
- Messages
- 188
This is a very important and heavily debated topic, because if a higher fps = less script latency statement is to be valid, this can solve many of SS2's performance woes.
This is a test-case from Skyrim SE, but knowing that Skyrim SE was basically a test port for FO4's new engine, one can assume they are very similar in how papyrus/CE works.
This test shows that playing at a higher framerate did reduce script latency lag. The tester was using a test mod that stressed the engine with 3200 operations and wich each event taking 1.2 MS (the full vanilla papyrus budget window).
In a 2022 world where FO4 has the High FPS physics fix, it is my understanding that playing at a higher framerate does indeed reduce script lag. Like what poster @Nosimo said, each frame has that papyrus budget window allocated to run scripts. If you have a higher framerate, you have more windows of time for that script to fully finish running.
This is also backed up by Nosimo's more casual testing of Transfer Settlements, which brings up a settlement plan up from scratch which is very script intensive (lots of vanilla workshop calls + setting up power grids). in a higher FPS envrionment he noticed the build time to be much shorter.
All the data and knowledge thus far seems to on the side of Higher FPS is better for script latency performance. Unless there are tests done that prove otherwise, I think this is where we should stand by.
Opinions, extrapolations, and interpretations of how the Creation Engine works are going to differ but hard data is hard data.
This is a test-case from Skyrim SE, but knowing that Skyrim SE was basically a test port for FO4's new engine, one can assume they are very similar in how papyrus/CE works.
This test shows that playing at a higher framerate did reduce script latency lag. The tester was using a test mod that stressed the engine with 3200 operations and wich each event taking 1.2 MS (the full vanilla papyrus budget window).
In a 2022 world where FO4 has the High FPS physics fix, it is my understanding that playing at a higher framerate does indeed reduce script lag. Like what poster @Nosimo said, each frame has that papyrus budget window allocated to run scripts. If you have a higher framerate, you have more windows of time for that script to fully finish running.
This is also backed up by Nosimo's more casual testing of Transfer Settlements, which brings up a settlement plan up from scratch which is very script intensive (lots of vanilla workshop calls + setting up power grids). in a higher FPS envrionment he noticed the build time to be much shorter.
All the data and knowledge thus far seems to on the side of Higher FPS is better for script latency performance. Unless there are tests done that prove otherwise, I think this is where we should stand by.
Opinions, extrapolations, and interpretations of how the Creation Engine works are going to differ but hard data is hard data.
- Messages
- 1,574
That’s a nice test there and great outcome. On Fo4 I run the high FPS mod that allows uncapped 350fps when traveling or black screen or loading. That explains why the fast travel is so much smoother with the mod running I do cap to 61 gives a net 60 FPS for normal play but that’s because my tv doesn’t support higher frame rates but I can see where using the mod to decouple FPS from the physics and stuff would make the scripting a lot smoother as well.
just ordered an oled 4K 120 refresh rate tv so maybe I’ll try boosting the FPS to that 120 and use vrr to help with making it less juttery and see how the game plays. I don’t run a lot of script heavy mods though just basically ss2, gun4hire, and the advanced needs 76.
honestly I really hope bathesda ( and the company that optimized the new creation kit engine) fixed a lot of these problems with the new 2.0 creation engine, I know they will use what’s familiar but hopefully it’s all updated to the newest programs and latest tech so it’s not so hard for mods to run on.
just ordered an oled 4K 120 refresh rate tv so maybe I’ll try boosting the FPS to that 120 and use vrr to help with making it less juttery and see how the game plays. I don’t run a lot of script heavy mods though just basically ss2, gun4hire, and the advanced needs 76.
honestly I really hope bathesda ( and the company that optimized the new creation kit engine) fixed a lot of these problems with the new 2.0 creation engine, I know they will use what’s familiar but hopefully it’s all updated to the newest programs and latest tech so it’s not so hard for mods to run on.
sranger
Active Member
- Messages
- 188
Yes the 350 fps increasing your loading times has a lot to do with more windows to run scripts. Basically each frame has an allocated budget to do papyrus work, and then the rest of the frame time is for other game systems.
I suspect during loading screens the bottleneck is script calls and that's why you see such an improved loading speed in high fps. Typically the higher fps you go, the trade-off is that you give less time for the rest of the game systems to do everything else. So seeing such huge increase in speed means that there is far more scripting work to do than any other kind of engine work during loading screens.
One can probably assume something similar while using SS2 in settlements.
- Messages
- 4,447
You can increase Papyrus VM performance by increasing fps and/or increasing the ini settings
So, it comes down to your graphics card. The more powerful the card, more resources can be devoted to the Papyrus VM without reducing gameplay to a slideshow. Removing the fps limit during a load screen is no big deal due to the game only having to render the load screen. The best test for figuring out how high you can go with fps would be downtown. If you can keep a steady fps, you most likely have fps at a good value, otherwise I would lower it and test again.
An interesting fun fact: Even though I have read in many different places that the Papyrus VM and other game systems are not supposed to affect fps, I have found that when a quest starts up, it can cause fps drop. (this is a quest in a test mod I have) I don't know what exactly causes this behavior, just that if I delay the quest start by 0.5 sec, I no longer see the fps drop. This same behavior can be seen when exiting vault 111 for the first time. When you get to the end of the catwalk past the vault entrance door just before the stairs. I get around a 10 fps drop for a split second. (GTX 1070, default game settings) There is a trigger box there that forces a quick save when you leave. I haven't yet tested to see if its an F4SE or UFO4 Patch thing.
fUpdateBudgetMS and fExtraTaskletBudgetMS The trade off is less time for other systems to do their job. While these changes can increase VM performance, the caveat is it is a hard setting. Its fine when VM load is heavy but when it is light and the game is trying to load your 4k textures, the engine is unable to reduce VM time to increase graphics performance so you will most likely experience fps drop and/or stutter.So, it comes down to your graphics card. The more powerful the card, more resources can be devoted to the Papyrus VM without reducing gameplay to a slideshow. Removing the fps limit during a load screen is no big deal due to the game only having to render the load screen. The best test for figuring out how high you can go with fps would be downtown. If you can keep a steady fps, you most likely have fps at a good value, otherwise I would lower it and test again.
An interesting fun fact: Even though I have read in many different places that the Papyrus VM and other game systems are not supposed to affect fps, I have found that when a quest starts up, it can cause fps drop. (this is a quest in a test mod I have) I don't know what exactly causes this behavior, just that if I delay the quest start by 0.5 sec, I no longer see the fps drop. This same behavior can be seen when exiting vault 111 for the first time. When you get to the end of the catwalk past the vault entrance door just before the stairs. I get around a 10 fps drop for a split second. (GTX 1070, default game settings) There is a trigger box there that forces a quick save when you leave. I haven't yet tested to see if its an F4SE or UFO4 Patch thing.
- Messages
- 1,574
Yeah also why when sleeping your FPS goes crazy down to 1 sometimes 20 then back to 60 when your about to wake up.
- Messages
- 1,574
so on the catwalk FPS drop my theory on this is when you take that last step out of the vault and get that FPS hit is when the commonwealth loads, before this happens you had came from the sanctuary world space prewar. Can’t prove it but I think instead of loading the commonwealth while your sleeping in the pod it loads last min on the way out just before the vault exit.
that’s all theory on my end though as the more texture mods and other mods you have the hit can be much larger then 10 FPS.
side note I’ve also seen the FPS hit on quest start during a game that had a lot of script heavy mods besides ss2 installed.
sranger
Active Member
- Messages
- 188
at least for me , quicksaves in general cause a quick fps dip, so the vault 111 catwalk thing isn't a surprise for me.