(You would need a quantum computer for FO4 to render that fast in the 3d world).Īs for memory issues, Buffout takes care of them. The only time Script guy has a problem is if render guy does a line a coke and starts completing jobs faster than the 1.2 ms it takes script guy to do a job. If render guy is lazy and only does 15 jobs a second then script guy can only do 15 jobs a second. If render guy does 144 jobs a second, then script guy can do 144 jobs a second. Script guy is only allowed to do a new job when Render guy starts a new job. Script guy and render guy have to work in sync. Script guy takes a static 1.2 ms to finish a job.
Render guy is given however much time he is needed to complete the job. Think of it this way, two guys are working, script guy and render guy. 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. 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. ini file) out of every frame to run scripts. 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.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. 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.įrame rate is the key. 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. 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. 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.Īpparently 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. At 30fps the script window is open 30 times per second, at 144fps the window is open 144 times per second. 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)." At 144fps, a frame is rendered every 6.9ms. At 60fps, a frame is rendered every 16.67ms. So, at 30 fps, a new frame is being rendered once every 33.34ms. "According to SmkViper (here: ), 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 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.Ī quote from one of the posts in that thread: 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. Click to expand.No it doesn't aside from correcting me on the number of ms per frame, so its 1.2ms by default according to that.