This mainly helps with killing any potential infinite recursion. This is the maximum stack depth the VM will allow before forcibly killing function calls on that stack. Note that it is possible to exceed this value temporarily while loading a save game due to slightly different allocation ordering. Increasing this value may improve performance in high-stress situations with lots of scripts running, but will use more memory. If an allocation would push memory usage over this limit, the VM will instead wait for more memory to be freed. This is the maximum amount of memory the VM will allocate in total for stack frames. Larger values may cause the memory allocator to allocate differently, decreasing performance for large stack frames. Smaller values may force the VM to allocate more pages for large stack frames. This is the largest amount of memory the VM will allocate for a single stack page, in bytes. Smaller values will waste less memory on small stacks, but larger values will reduce the number of allocations for stacks with many small frames (which improves performance). This is the smallest amount of memory the VM will allocate for a single stack page, in bytes. If the quest initial stage has a lot of scripting then it may need the extra time to run before the load screen is pulled down.
This also may depend on the story manager since quests may not start until the load screen finishes if they are started up right before the player hits a load door. Adjust this setting if a cell with very complicated scripting is not getting quite set up in time by the time the player loads.
Adjusting the time will adjust your visible load screen time. This setting controls how much time is added onto the load screen to do additional script processing in case the cell being loaded into needs to set itself up. Increasing this value may improve script performance in high-stress situations at the expense of framerate.įPostLoadUpdateTimeMS If the game is not stressed, this time will not be used. This time is on top of the time that the tasklets normally get in their own thread, but because that thread is shared they may end up being starved if other systems are highly stressed.
FALLOUT 4 PAPYRUS LOG CODE
This setting controls how much time taken out of another game thread is taken up by running script tasklets (the code that runs the raw script byte code). However most of the time the VM won't take this entire time slice and increasing the value will have no effect.įExtraTaskletBudgetMD If a lot of function calls are being made and a lot of scripts are running, increasing this value may improve script performance at the cost of reduced game framerate. This loop mainly controls function dispatch.
FALLOUT 4 PAPYRUS LOG UPDATE
This setting controls how much time the main Papyrus update loop gets. However all of the settings are listed here for completion. The only ones users usually need to mess with are bEnableLogging, bEnableTrace, bLoadDebugInformation, bEnableProfiling, and sTraceStatusOfQuest. Most of the settings won't need to be changed. If you end up messing something up you can always copy this block back into your ini file (or delete the block entirely): The following block shows the defaults for all the various settings.
0 kommentar(er)
