Same here, unfortunately. I'm also on 1.6.1170 AE. Other SKSE plugins, such as DescriptionFramework, MCMHelper, and MoreInformativeConsole, are spitting out their logs without a problem. I really, really want to make use of this tool. Author, can I provide any other information to help you debug?
Installed this yesterday, mainly because I am having a 'VM Overstressed' issue during any battle, lately. Not always, but often. Mod worked perfectly, created a log. However, during it's first run, no 'VM Overstressed' situation fired up... Anyways, will keep looking. In the meantime, one thing I noticed in the log is an excessive amount of XPMSEWeaponStyleScaleEffect.OnEffectStart entries. I am aleady using latest XPMSSE, fixed scripts, Papyrus stack fix & your optimised scripts in the end. Is this normal? Can I / should I do anythingin order to reduce it?
Thx in advance for all your wonderful mods & kudos of course!
The only thing you can probably still do is, if you don't actually use any of XPMSE's scripted features at all (for scripted variation in weapon styles / scales / placement of sheathed weapons), you can just use a lite version which has no scripts at all: https://www.nexusmods.com/skyrimspecialedition/mods/69583
But that won't be a great solution if you actually do want to make use of the mod's scripted features.
Thx for the insights! As a matter of fact, I am using IED / OAR and no weapon styles from XPMSSE And of course the physics part... The only thing that keeps me from switching to 'Basic' version of XPMSSE is the impact on my existing game...
p.s. Maybe a coincidence, ever since I installed your tool no 'VM Overstressed' has appeared hahaha
UPD 3/5 : By checking the 'Disable cloak spell' option in XPMSSE, the amount of Weapon styles script load was reduced by more than 50%... Just make sure to follow Groovtama's tip (tick the option while in qasmoke room).
out of curiosity this wouldnt measure the condition checks applied to a spell right? For example. If you have a spell effect* that is a "Constant Effect" with a simple script attached to it that just sets a global for example - that is put into a *spell and then you add a condition to that constant magic effect in the spell so that it only activates and works when the player is level 40 lets say and attach the spell to the player.
In this hypothetical this tool wouldnt show the polling that the vanilla game does right? like the vanilla polling that checks conditions and only if they are met then moves things forward thats handled differently and shouldnt contribute to script lag I always thought. Is that a true statement? Is there a limit to this were it eventually would cause lag? My assumption on this tool would be more about seeing how your papyrus scripts* contribute to script lag. So in my hypothetical it would only measure the single fire of the script to set a global which should be near non-existant impact. the conditions I set shouldnt matter or impact anything even if I had 100 conditions that condition check system by the engine will always check all conditions happening anyway as part of its polling.
Indeed, the profiler purely checks what scripts are doing, not what any other part of the game engine is doing (such as the game engine natively doing a lot of polling for conditions on spells).
In practice, conditions on abilities are really fast for the game engine to process though. I'm sure you could in principle break the game / slow its FPS down to a crawl by going crazy with lots of spells and lots of conditions on lots of NPCs, but unless you're intentionally trying to break the game, it should probably be fine.
Script lag is very different though. It's specifically *not* lag / reduction in FPS across the entire game. It's exclusively about the game's scripting engine becoming slow/unresponsive. This happens because the game engine uses a whole pile of all kinds of annoying "safety" checks and guardrails around the virtual machine used for scripts. These guardrails make it almost impossible to hurt the game's FPS through scripts (the game will simply refuse to run more than a relatively small number of scripting instructions per frame), but for the same reason you also start noticing really easily that scripts become unresponsive (the game engine refuses to run many of them, even if many of them need to run).
interesting - yea that was my guess. I actually looked more into it and it looks like at any given time (from what I can tell i could be wrong!) thousands of conditions are being checked just by vanilla - all the skills in the skill tree are being checked with 2 to 3 conditions for each for example, dialog is being checked based on conditions, quest startups, it looks like it has to be a pretty robust system to handle all the polling going around and is handled at the engine level and not in any kind of association to the papyrus system. albeit it looks like all bethesda conditions have a quick exit meaning it checks top down and if the player isnt level X or the player doesn't have perk X then thats a immediate fail and it moves to the next check. To really test and max this system I created a system were a constant effect spell put on the player has 102 magic effects each looking for a specific condition to be met before it fires the "Hello World" script to show a in game message. something simple so the lift is on conditions and nothing else. I set the conditions to check for player skill levels and found that triggering them one by one has the script fire within a second. Triggering them all at once same result. I actually had 2 sets of conditions to be honest the first to check level and the second to basically say after you fire once your done to keep it simple. I saw no performance impact and given that the polling system looks to be handling thousands I think even throwing in a hundred was a drop in the bucket compared to the rest of the game that its checking. I was curious if there was another way to measure this other then seeing how quick I get the in game hello world message. and monitoring FPS. I think if you maintain a quick exit like bethesda did with your conditions and make them straightforward and simple the sky might be the limit. I mean not exactly the limit like clearly there will be a limit but i think few people will need to trigger 204 conditions so to that end I tried to rig a impact and didnt get one on that system alone and wanted to know if there was another way I could measure it (102 magic effects on 1 spell each magic effect with 2 conditions = 204 conditions in this test - all 204 conditions were triggered at the same time via batch script i made).
I'm running this profiler through MO2 and using the nl_cmd console commands to start and stop profiling. But it's not actually outputting the log. I used the start and stop commands as instructed, and it shows the "Profiling started" and "Profiling stopped" popups in game, but nothing actually gets dumped out to the MyGames/SKSE/Logs folder. Anyone know what's happening? Is the log being put somewhere strange?
I guess you are using patch 1.6.1330 or later for the game? Those later versions of the game messed up something in how many SKSE plugins were finding the log directory.
I've just uploaded a new version which should likely fix this, but I have not tested it personally.
Hi. I did have a question. I have a mod thats causing a script to pop up a lot. I read on your github site...
"Note that it will not write any of this data to a file until you manually stop the profiling. So, if you quit your game (or it crashes) without having stopped the profiler, no profiling data will be retained. Papyrus profiling can be stopped with the following console command."
My question is if the game freezes, I wont be able to get any data from it correct? Not sure if console command works when it does.
Yeah, in that situation the default behaviour from the `StartPapyrusProfiling()` won't work well for you.
What you should probably do instead, is use the `StartPapyrusProfilingConfig(<filename>)` version, where you pass in a filename for some `.json` file with a non-default configuration, as described a bit further down the same page. In particular, you'll want to use a configuration where you set `WriteMode` to 1 instead of 0: that means the profiler will write to a file immediately for every single function call that runs in a script, rather than batching everything together and only writing at the end. So, in this way, you'll have a non-empty file if the game freezes and you terminate it without having stopped the profiler.
Thank you so much for this. I knew I had a bunch of scripted mods running in my build, but I never knew just how much or how little some of them impacted script lag, so I decided to give this a try. Many of them that I worried about being unecessarily script heavy were actually perfectly fine(Frostfall, Hunterborn, Last Seed, RASS, Wildcat, and others).
And others were surprisingly script heavy for their purpose(iHUD, Pulley's Butterfly, and others). I was able to find alternatives for them, or just remove the ones that had unecessarily high script usage. I was experiencing noticable HUD lag with iHUD and mistakenly thought the lag was due to other mods. This mod proved that idea wrong. I use a different HUD mod to toggle it and I get no HUD lad now! I also realized that a more optimal critter script fix wasn't in the correct place in my load order, so the less effective critter script fixes were causing more usage and lag than I realized. Making sure the better fix was the one being used helped fix a lot of script lag and stuttering that I was experiencing. Thanks again. This brings a lot of peace of mind so I'm not worrying and suspecting mods that are no problem and helped clarify a bunch of other issues along the way!
Just wanted to say thanks. This has helped me eliminate some very annoying script lags that I've never been able to narrow down (Wonders of Weather, Wet and Cold, XMPSE script lag...). Endorsed!
67 comments
no logs or any file related to papyrusprofiler
using latest version 1.6.1170 AE
Author, can I provide any other information to help you debug?
Installed this yesterday, mainly because I am having a 'VM Overstressed' issue during any battle, lately. Not always, but often.
Mod worked perfectly, created a log. However, during it's first run, no 'VM Overstressed' situation fired up...
Anyways, will keep looking. In the meantime, one thing I noticed in the log is an excessive amount of XPMSEWeaponStyleScaleEffect.OnEffectStart entries.
I am aleady using latest XPMSSE, fixed scripts, Papyrus stack fix & your optimised scripts in the end.
Is this normal? Can I / should I do anythingin order to reduce it?
Thx in advance for all your wonderful mods & kudos of course!
But that won't be a great solution if you actually do want to make use of the mod's scripted features.
Thx for the insights!
As a matter of fact, I am using IED / OAR and no weapon styles from XPMSSE And of course the physics part...
The only thing that keeps me from switching to 'Basic' version of XPMSSE is the impact on my existing game...
p.s. Maybe a coincidence, ever since I installed your tool no 'VM Overstressed' has appeared hahaha
UPD 3/5 : By checking the 'Disable cloak spell' option in XPMSSE, the amount of Weapon styles script load was reduced by more than 50%... Just make sure to follow Groovtama's tip (tick the option while in qasmoke room).
In this hypothetical this tool wouldnt show the polling that the vanilla game does right? like the vanilla polling that checks conditions and only if they are met then moves things forward thats handled differently and shouldnt contribute to script lag I always thought. Is that a true statement? Is there a limit to this were it eventually would cause lag? My assumption on this tool would be more about seeing how your papyrus scripts* contribute to script lag. So in my hypothetical it would only measure the single fire of the script to set a global which should be near non-existant impact. the conditions I set shouldnt matter or impact anything even if I had 100 conditions that condition check system by the engine will always check all conditions happening anyway as part of its polling.
In practice, conditions on abilities are really fast for the game engine to process though. I'm sure you could in principle break the game / slow its FPS down to a crawl by going crazy with lots of spells and lots of conditions on lots of NPCs, but unless you're intentionally trying to break the game, it should probably be fine.
Script lag is very different though. It's specifically *not* lag / reduction in FPS across the entire game. It's exclusively about the game's scripting engine becoming slow/unresponsive. This happens because the game engine uses a whole pile of all kinds of annoying "safety" checks and guardrails around the virtual machine used for scripts. These guardrails make it almost impossible to hurt the game's FPS through scripts (the game will simply refuse to run more than a relatively small number of scripting instructions per frame), but for the same reason you also start noticing really easily that scripts become unresponsive (the game engine refuses to run many of them, even if many of them need to run).
I've just uploaded a new version which should likely fix this, but I have not tested it personally.
"Note that it will not write any of this data to a file until you manually stop the profiling. So, if you quit your game (or it crashes) without having stopped the profiler, no profiling data will be retained. Papyrus profiling can be stopped with the following console command."
My question is if the game freezes, I wont be able to get any data from it correct? Not sure if console command works when it does.
What you should probably do instead, is use the `StartPapyrusProfilingConfig(<filename>)` version, where you pass in a filename for some `.json` file with a non-default configuration, as described a bit further down the same page. In particular, you'll want to use a configuration where you set `WriteMode` to 1 instead of 0: that means the profiler will write to a file immediately for every single function call that runs in a script, rather than batching everything together and only writing at the end. So, in this way, you'll have a non-empty file if the game freezes and you terminate it without having stopped the profiler.
And others were surprisingly script heavy for their purpose(iHUD, Pulley's Butterfly, and others). I was able to find alternatives for them, or just remove the ones that had unecessarily high script usage. I was experiencing noticable HUD lag with iHUD and mistakenly thought the lag was due to other mods. This mod proved that idea wrong. I use a different HUD mod to toggle it and I get no HUD lad now! I also realized that a more optimal critter script fix wasn't in the correct place in my load order, so the less effective critter script fixes were causing more usage and lag than I realized. Making sure the better fix was the one being used helped fix a lot of script lag and stuttering that I was experiencing. Thanks again. This brings a lot of peace of mind so I'm not worrying and suspecting mods that are no problem and helped clarify a bunch of other issues along the way!