Animations take a long time to start

[Omnishade]

If you have a lot of mods and animations, SL scenes take a long time to start. I was wondering what it's determined by. Number of animations or just the number of script heavy mods running? I'm usually trying to reduce my animation count by deleting animations I don't want to use from the animation lists, which is tedious work, so if the amount of animations doesn't make SL faster, I can stop doing that.

[anjenthedog]

I don't "know", (I 'm not Mr Authoritas) but from observation, and a ~bit of moldy background programming and database management experience, some seems to be a matter of action hierarchy (which background operation goes first?), some to script bottlenecking (there sure are a lot of us actions standing in line waiting to be processed), and a lot to what appears to me to be a sub par database handler. presumably in Skyrim itself. It chokes when personal inventory item counts are high, when chest counts are high, when loading up various lengthy  lists, etc. It's clunky. And slow.

 

That's not to be confused with the normal delay associated with actor positioning.

Edited September 14, 2023 by anjenthedog
digital dyslexia (typo) and clarification

[traison]

16 hours ago, RoninDog said:

If you have a lot of mods and animations, SL scenes take a long time to start. I was wondering what it's determined by. Number of animations or just the number of script heavy mods running? I'm usually trying to reduce my animation count by deleting animations I don't want to use from the animation lists, which is tedious work, so if the amount of animations doesn't make SL faster, I can stop doing that.

 

Both, more animations = more script work, more scripts = more script work. Apparently the script budget value in the ini is not the only budget (time) allocation limit for scripts. I only found out about this recently. Papyrus Tweaks is a mod that can apparently adjust the otherwise hidden 2nd budget value. I increased it massively myself, but I'm not a good candidate to tell whether it works or not because I didn't have noticeable script lag to start with.

 

However, in your case since you already have a performance issue, I'd recommend you start with a papyrus profiler and only then consider whether editing the budget values is a good idea. Simply increasing the budget to hide the issue is like getting coughing medicine for your cold. Its not efficient, and it doesn't fix the underlying issue; and if you're not lucky, that underlying issue will come back to bite you in the ass later (i.e. pneumonia).

 

Edit: Oh and, if you do get Papyrus Tweaks, consider disabling all other features except for the budget hack. Some of the other settings are quite risky and could potentially cause a lot of issues if they aren't implemented perfectly.

Edited September 15, 2023 by traison

[wareware]

Get Papyrus Tweaks NG and OsmelMC's Sexlab Utility Plus.

 

 

[Omnishade]

On 9/15/2023 at 1:49 PM, traison said:

 

Both, more animations = more script work, more scripts = more script work. Apparently the script budget value in the ini is not the only budget (time) allocation limit for scripts. I only found out about this recently. Papyrus Tweaks is a mod that can apparently adjust the otherwise hidden 2nd budget value. I increased it massively myself, but I'm not a good candidate to tell whether it works or not because I didn't have noticeable script lag to start with.

 

However, in your case since you already have a performance issue, I'd recommend you start with a papyrus profiler and only then consider whether editing the budget values is a good idea. Simply increasing the budget to hide the issue is like getting coughing medicine for your cold. Its not efficient, and it doesn't fix the underlying issue; and if you're not lucky, that underlying issue will come back to bite you in the ass later (i.e. pneumonia).

 

Edit: Oh and, if you do get Papyrus Tweaks, consider disabling all other features except for the budget hack. Some of the other settings are quite risky and could potentially cause a lot of issues if they aren't implemented perfectly.

 

I had a look at Papyrus Tweaks and I don't see what's harmful with it. It has one tweak that increases the 100 operations per task which was made for a standard computer in 2011. Maybe the default of 500 is a bit much to start with, but anyone should be able to use 200 if they have a reasonably good machine in 2023. Is that the budget hack you're referring to? Also, since it's an SKSE plugin you can disable anytime.

 

I don't know about the other settings, but looks harmless on paper, and the experimental settings are disabled by default. That means the author must have tested them.

Edited September 17, 2023 by RoninDog

[anjenthedog]

Pardons for any hijacking here... I think it's on topic but if not sorry to the OP for distraction

 

Saw this thread read it. Checked out Papyrus Tweaks. I've seen before it was over my head earlier, isn't so much now, considering installing.

 

@traison

 

Based on your comment above, I presume you bumped iMaxOpsPerFrame well beyond 500?

 

What benefit did it produce for you? (beyond the obvious "it increases the iMaxOpsPerFrame buffer size").  Was it a "dev level" adjustment (development headroom) or "play" based decision?

 

You also suggested we disable "all the others" beyond (presumably) the VMTweaks settings. Which ones, in your experience, must still remain set true? Or is it your advise we just set all settings false other than the specific VMTweaks portion of the settings?

 

.... would you be wiling to share your settings for PapyrusTweaks.ini? It might make those answers more clear with a minimum of effort on your part.

 

Lastly, just for horsepower perspective, are you operating on an SOA system (latest proc, beaucoup memory, SOA GPU, etc) or on a "more modest" system?

 

Edited September 17, 2023 by anjenthedog

[traison]

1 hour ago, anjenthedog said:

Based on your comment above, I presume you bumped iMaxOpsPerFrame well beyond 500?

 

750, an arbitrary number. I feel like this was safe to adjust because most likely what it is is just an ops counter. As in, each time the cpu/code executes a papyrus operation/instruction the counter is decreased by 1. So the worst effect this is going to have is delaying something else, like rendering.

 

1 hour ago, anjenthedog said:

What benefit did it produce for you?

 

None, because I didn't have performance issues to begin with. I based my decision on getting this mod, and adjusting the budget on a reddit thread where someone claimed the budget was massively decreased for the later game entries such as Skyrim SE/AE (and possibly Fallout 4). To a point where, when they attempted to run a simple do-nothing papyrus loop with 40,000 interations, it took like 30 seconds for it to complete it; compared to the second or two it took in Skyrim LE. This seemed like a "fix" implemented by Bethesda to ensure script-heavy (or badly made) mods would not tank performance - it makes their game look better, and allows noobs to click and install all the shiny things they can find. I see why they would do it, but I hate them for hiding it from us that want to take responsibility over our actions.

 

1 hour ago, anjenthedog said:

You also suggested we disable "all the others" beyond (presumably) the VMTweaks settings.

 

SkyrimSE.exe is a complex system. Throw in 500 mods, some of which contain dlls that make their own bytecode edits and you basically got a system that no one has true control over anymore. Combine that with say for instance "bFixDelayedScriptBreakage". What does this option do?

 

"Fix scripts that don't load right away breaking completely if they reference an invalid object type (Ex: SuperSecretScript has a function that takes InvalidScript as a parameter)."

 

This fix sounds like its going to change the way scripts are loaded by the game engine. If you enable this, you need to keep in mind that if you start to have weird issues related to scripts that this may very well be why.

 

How about "bSpeedUpNativeCalls"?

 

"Speeds up native calls by desyncing them from framerate and instead syncing script calls to a spinlock, greatly improving script performance while still preventing concurrent execution of native calls"

 

Again a fix that's going to be messing with threading most likely. This one seems to offload native call handling to a separate thread, which to me says: unless a thread syncing method was implemented between this new thread and Papyrus this is going to cause massive issues. I believe the Bugs tab on the Nexus had a few issues reporting this causing ctds when enabled. Its marked as experimental though so, guess its your own fault for enabling it if you do.

 

It really comes down to if it ain't broke, don't fix it.

 

1 hour ago, anjenthedog said:

are you operating on an SOA system (latest proc, beaucoup memory, SOA GPU, etc) or on a "more modest" system?

 

I didn't buy into the 4000-series scam by nVidia, and I am also not interested in modern (glorified casino/gambling) games. I switched to AMD from Intel on the cpu side because Intel seemed to be unable to pull their pants up for the longest time after they got caught with them down when AMD launched Ryzen years ago - a sign of a lazy company that got incompetent during their time at the top. This is a 6 month old system, but it's worth (new) about 1500€ without peripherals. Compared to my previous system, where the cpu alone was already half that, I'd say it's "modest".

 

1 hour ago, anjenthedog said:

would you be wiling to share your settings for PapyrusTweaks.ini?

 

Copy paste this mess into Notepad++ and set the language to "INI file". Makes it readable.

 

Spoiler

[Fixes]

;Fixes ToggleScripts command not persisting when saving/stack dumping
;Scripts will now stay turned off when toggled off, and on when toggled on.
bFixToggleScriptsCommand = false

;Fix unintentionally allocating script pages when getting largest available page, but out of memory.
bFixScriptPageAllocation = true

;Fix crash when passing in NONE object to script function Actor.IsHostileToActor().
bFixIsHostileToActorCrash = true

;Fix scripts that don't load right away breaking completely if they reference an invalid object type (Ex: SuperSecretScript has a function that takes InvalidScript as a parameter).
bFixDelayedScriptBreakage = false

[VM Tweaks (Tweaks that directly alter the script engine)]

;Maximum papyrus operations per frame. Higher number means better script performance on average
;Has a very minor impact on framerate, and varies from script to script. (Default: 500, Vanilla value: 100). Recommended Range: 100-2000. Set to 0 to disable
iMaxOpsPerFrame = 750

;Modify how long Papyrus can be "overstressed" before dumping stacks, in milliseconds (Default value: 15000, Vanilla value: 5000).
;Set to 0 to disable the stack dump check, or -1 to disable this setting.
;See https://www.nexusmods.com/skyrimspecialedition/articles/4625 for information on what a stack dump is
iStackDumpTimeoutMS = 15000

;Enables loading of doc strings from scripts into the engine. Requires `bEnableDebugInformation` to be true in this INI
bEnableDocStrings = true

;Enables Skyrim to load debug information of scripts. This completely overrides bLoadDebugInformation in Skyrim.ini and is provided here for easier configuration
bEnableDebugInformation = true

[Logging Tweaks (Tweaks that affect script logging)]

;Disables `File " % s " does not exist or is not currently loaded.` logs from being printed when calling Game.GetFormFromFile().
;This only disables the logging of the error, the error itself will still occur
bDisableGetFormFromFileErrorLogs = false

;Improves Base Type Mismatch error to show inheritance hierarchy of scripts; Also clarifies if the script was a genuine mismatch, or if the script doesn't exist
bImproveBaseTypeMismatchLogs = true

;Improves several error logs relating to incompatible arguments to better clarify what is incompatible
bImproveValidateArgsLogs = true

;Disable "Property %s on script %s attached to %s cannot be initialized because the script no longer contains that property" log messages.
;This only disables the logging of the warning, the warning itself will still occur
bDisableNoPropertyOnScriptErrorLogs = false

;Disable "Cannot open store for class "%s", missing file?" errors being logged.
;This only disables the logging of the error, the error itself will still occur
bDisableMissingScriptError = false

;Adds a summary of events when dumping stacks to log
bSummarizeStackDumps = true

[Experimental]

;(Formerly bRunScriptsOnMainThreadOnly)
;Speeds up native calls by desyncing them from framerate and instead syncing script calls to a spinlock, greatly improving script performance while still preventing concurrent execution of native calls
bSpeedUpNativeCalls = false

;(Formerly sMainThreadClassesToExclude, requires bSpeedUpNativeCalls=true)
;List of script classes to exclude from being sped up by bSpeedUpNativeCalls.
;It is strongly recommended to leave at defaults unless you absolutely know what you're doing
sScriptClassExclusions = UI, ConsoleUtil, PO3_SKSEFunctions, MfgConsole, MFGConsoleFunc, Input, Debug, Utility, PapyrusTweaks, Quest

;(Formerly sMainThreadMethodsToExclude, requires bSpeedUpNativeCalls=true)
;List of script method prefixes to exclude from being sped up (ex: "Equip" excludes "EquipItem" and "EquipItemByID", but does NOT exclude "UnequipItem".
;It is strongly recommended to leave at defaults unless you absolutely know what you're doing
;as a lot of modifying functions like `EquipItem` do not work properly if executed more than once in a single frame.
; Defaults exclude everything except for read-only functions (ex: GetFormFromFile, HasKeyword, IsLoaded, etc.)
sScriptMethodPrefixesToExclude = Activate, Add, Advance, Allow, Attach, Apply, Block, Cast, Change, Clear, Close, Complete, Create, Damage, Delete, Disable, Disallow, Dismount, Dispel, DoCombatSpellApply, Draw, Drop, Enable, End, Equip, Evaluate, Fade, Fail, Fire, Force, GetAnimation, GetQuest, Hide, Hold, Ignore, Increment, Keep, Kill, Knock, Learn, Load, Lock, Mod, Move, Mute, Open, Place, Play, Pop, Precache, Process, Push, Queue, Quit, Regenerate, Register, Release, RemoteCast, Remove, Request, Reset, Restore, Resurrect, Revert, Save, Say, Send, Serve, Set, Shake, Sheath, Show, Start, Stop, Teach, TempClone, Tether, Toggle, Translate, Trap, Trigger, Try, Unequip, Unlock, UnMute, UnPause, Update, Unregister

;(VR-ONLY) Pauses all non-playroom scripts while in the VR playroom, so mod scripts only initialize once you actually enter a save/new game.
;This is only experimental as it intentionally alters script behavior
bDisableScriptsInPlayroomVR = false

;Stops the game from resetting when loading a corrupted save
;This will NOT fix a broken save, just allows you to load the save no matter what information is lost. ONLY USE AS A LAST RESORT TO RECOVER A SAVE YOU HAVE BEEN WARNED!!
bBypassCorruptSaveMessage = false

;Allows the Script Engine to use as much memory as needed, with no cap. This makes `iMaxAllocatedMemoryBytes` in Skyrim.ini useless/infinite
;Note: Skyrim already ignores memory limit when stressed, this setting just keeps it ignored.
bIgnoreMemoryLimit = false

 

Edited September 17, 2023 by traison

[anjenthedog]

I agree with your espoused  *philosophy. I 'm just a bit slower on digesting intricacies of "the code" ... And yeah... I *figured you were on a ~conventional system, just wanted to make sure (orange vs oranges and all that), to avoid becoming glimmered by the unachievable, if you catch my drift (can't drive  a car with launch control, or shift gears with paddles, unless you have one that has them),... "using the brakes", on the other hand is a bit more universal

 

Thanks for all the useful info!

[traison]

@anjenthedog Slight update on the "what benefits came out of upping the instruction limit" question. I've noticed MCM is in general extremely fast now, as in, instant reaction to user input. Also, registering animations with SLAL is at least twice as fast, maybe faster. No noticeable drop in frame rate during any of this, or during gameplay. May have to increase that number even more now...

[anjenthedog]

@traison Thanks. Something to look for next time I play. I used the settings you shared. And while it hasn't palpably affected my game otherwise (I'll admit, I wasn't paying attention to MCM behavior), it didn't harm it either.