ini setting for script processing?

Post » Wed Apr 01, 2015 2:52 pm

I've got a bit of a problem with my Mod, it seems... It's a little Script-heavy, I guess, although I have managed to cut it down a LOT from what it originally was when I first began. On its own, it works perfectly and everything is nice and fluid, but once I add in other Mods (only running about 40-50 Mods at the moment, most of them shouldn't really be Script-Heavy), I find that it seems to start "struggling"...

Some parts work perfectly and exactly the same, but a few things like running Scripts on an Alias seem to be taking up to 20-30 seconds.

Since this is a Mod I'm not planning to release, I was wondering if there were any ini settings that control how much memory or whatever is allocated to processing Scripts, and if I could increase that? I've already reduced the main script from around 3,000 to just over 1,000 (excluding whitespace), and most of the other scripts should only be running under certain conditions...

But right now it is making half the Mod "unplayable" in the sense that it is taking so long for basic things to actually register with it... :/

User avatar
Tessa Mullins
 
Posts: 3354
Joined: Mon Oct 22, 2007 5:17 am

Post » Wed Apr 01, 2015 4:50 pm

try setting this in Skyrim.ini:
[Papyrus];fPostLoadUpdateTimeMS=500.0 <-- Line commented out with the default settingbEnableLogging=0bEnableTrace=0bLoadDebugInformation=0fUpdateBudgetMS=800fExtraTaskletBudgetMS=800fPostLoadUpdateTimeMS=2000iMinMemoryPageSize=256iMaxMemoryPageSize=512iMaxAllocatedMemoryBytes=2457600
Second section is the modified add ins which fixed this snails pace processing of scripts for me.
User avatar
Chloe Yarnall
 
Posts: 3461
Joined: Sun Oct 08, 2006 3:26 am

Post » Wed Apr 01, 2015 4:04 pm

That is awesome! :D

I have a "Play Shader" effect I'm using to show if the NPCs have been updated... I load an area, and they all start glowing like candles :D

Thank-you :D

User avatar
Robert Jackson
 
Posts: 3385
Joined: Tue Nov 20, 2007 12:39 am

Post » Wed Apr 01, 2015 5:31 pm

http://www.reddit.com/r/skyrimmods/comments/2gwvwl/guide_papyrus_ini_settings_and_why_you_shouldnt/ is a fairly well articulated post on why you shouldn't change those settings.

User avatar
Marcia Renton
 
Posts: 3563
Joined: Fri Jan 26, 2007 5:15 am

Post » Wed Apr 01, 2015 5:56 pm

The settings suggested in this thread are harmful to your game. The reddit thread posted by Didact gives lots of good reasons why.

If you must tweak the settings, only do so in very small amounts. You will get more benefit out of doubling your framerate then you will adjusting ini settings.

You can also use the profiling tools to find out why your script is so slow and fix it.
User avatar
ImmaTakeYour
 
Posts: 3383
Joined: Mon Sep 03, 2007 12:45 pm

Post » Wed Apr 01, 2015 5:40 pm

I don't think I'm going to be able to double my framerate, haha :P

Hmm, it really doesn't seem to be an issue with the script itself... Loading just this mod, it flows perfectly and I can get it all working perfectly even with a 'RegisterForSingleUpdate(0.1)' (which is obviously unnecessarily fast); the problem is once I add other Mods, even though I don't believe most of my other Mods are particularly script-heavy... No framerate issues are coming up, or anything... (apart from the shadow thing I mentioned in QQ,QA, but that seems to be totally unrelated, because of messing with TimeScale in a separate Mod). It's definitely things like filling aliases that seem to be 'crawling' and then running the scripts on those aliases (which right now are just adding items and a spell to the NPCs), and immediately on starting a game getting a huge delay in running of MagicEffectScritps (i.e., spell cast, but the script did not run for a good 20+ seconds later... That lasting for the first few minutes of gameplay, and then seeming to ease out).

Thanks for the info, though :)

@Michele,

What's your experience, out of curiosity? I've not seen any issues *yet*, but from looking at that thread, I can see where a few issues might come up in time... I'll keep an eye on it for now, and see what happens... At least if anything weird does happen, I'll know where to look :)

User avatar
Kelly Upshall
 
Posts: 3475
Joined: Sat Oct 28, 2006 6:26 pm

Post » Thu Apr 02, 2015 12:48 am

Save yourself a lot of grief and slow down and try to get your head wrapped around this. It took me a long time to get the script delay issues under control. It was extremely frustrating and I almost quit modding Skyrim because of it. However if you understand the issue and put in some extra work you can make it tolerably manageable.
When I first started modding Skyrim years ago my combat scripts would take 2 or 3 seconds to complete. My mod has features no one else has (or even want to try to do) because I am creating a combat simulator (I am a real life melee weapons practitioner for 30 years with our organization's highest rankings...er at my peek anyway :tongue: ) and basically completely overhauling the vanilla combat system.
After 3 years of massaging the scripts and using every trick possible to “speed up” the execution I have gotten the script “speed” down to 0.2 to 0.3 seconds (at worst on rare occasions 0.5). That is still horrible for combat modding (were combat events occur in 18 to 20 milliseconds) but the way I apply them in my mod it is “acceptable”.
For example damage done to an actor is a drain effect and not instantaneous. But then that is actually more realistic for combat simulation anyway. So it is “acceptable”.
If you are not already aware SmkViper is the VIP programmer that created this scripting system for Bethesda. So it would be in your best interest to not brush off what he is telling you so quickly.
That said, I have in fact used higher than normal settings for my [Papyrus] INI settings for the last several years and I have never had any issues. But I also do not load hundreds of mods nor use mods that devour the frame rate such as HD graphics mods.
The first thing you need to understand is that the scripting speed is directly connected to the frame rate. Some functions only cycle once per frame! So for example if you use a while loop with such a function you could easily delay your script several seconds.
So the very first thing I suggest you do is remove any graphics mods (or any mods) that effect frame rate that you can live without. Then look at your scripts for any looping functions or functions that go thru long lists until done or are repeated over and over.
Move any thing you want done quickly to the top of your script and things that are ok to be delayed to the bottom. Functions at the top of the script run FIRST and so can get done faster than those at the bottom especially in very long scripts. For example all my calculations for my notifications (such as converting large float variables x.xxxxxxxxxxxxxxxxxxxxxx to a familiar %x.xx format) and any record keeping for later is done LAST in my scripts.
NOW (finally) you raise your INI settings is small bumps until you get to an acceptable speed with the smallest change.
Edit: oh and be sure to condition the scripts so they only run when absolutely necessary! My combat scripts do not run unless the actors are in combat and around the player for example. I think you may already know that from your description but I felt I should include this anyway. There are many more tricks like this but they get complicated. The above should do the job for you!
Edit 2: actually I really wish all other non combat modders would do the same and stop their scripts during combat....
User avatar
SUck MYdIck
 
Posts: 3378
Joined: Fri Nov 30, 2007 6:43 am

Post » Wed Apr 01, 2015 6:17 pm

I will also add that using excessivly large INI values may make things work in the short-term but it also allows for a huge number of problems to queue up in the background. When enough problems accumulate they will eventually overwhelm your system and everything will come to a crashing halt (quite literally).

One thing that warning thread didn't explain was the "fPostLoadUpdateTimeMS" setting. That's the amount of script time allocated at each loading screen and it's the one setting that's fairly safe to raise. A value of 2000 means scripts will get a full two seconds to get everything in the new cell initialized. If you were seeing an initial spike of script delays that level out over time you might try leaving that value fairly high (and realize that the consequence is longer loading screen times) while lowering the rest.

If you must start experimenting with the Papyrus INI values I would recommend you start with:

fPostLoadUpdateTimeMS=1000fUpdateBudgetMS=1.4fExtraTaskletBudgetMS=1.4

If that helps, but not enough I would try:

fPostLoadUpdateTimeMS=2000fUpdateBudgetMS=1.8fExtraTaskletBudgetMS=1.8

You can raise the PostLoad value separately from the other two and if just raising it is good enough, then that's what you should do. You can determine for yourself just how much delay at the loading screens is acceptable, but the absolute highest I would consider for the other two values is 3.6 (which is three times the original value and probably far too large). Remember that if you're wanting to run at 60 FPS you have under 17 ms for the game to run scripts, make condition checks on spells and AI packages, do the physics calculations, and render all of the graphics each frame. The developers thought that giving the scripting system about 7% of the time was a good choice.

User avatar
Nauty
 
Posts: 3410
Joined: Wed Jan 24, 2007 6:58 pm

Post » Thu Apr 02, 2015 3:12 am


You're doing something slow, or you're fighting with your other mods for processing time. Use the profiling tools to find out why and where.


There is no "keeping an eye on it". Those settings are wrong. Restore them to their defaults. I wouldn't recommend doing more then doubling the default values, and only if you've already exhausted all other options, as people in here are telling you.


Actually, the order in which functions themselves show up in a script doesn't matter. That order isn't even preserved by the compiler or the game. Your advice is correct for the order of code inside a function though :smile:
User avatar
Bigze Stacks
 
Posts: 3309
Joined: Sun May 20, 2007 5:07 pm

Post » Wed Apr 01, 2015 5:45 pm

You can corroborate this by disassembling the script. The code order will be completely different from what you wrote.

Btw SmkViper, does the compiler change the structure simply to speed up compiling time or does it actually do some optimisations? The reason I ask is because I was comparing the differences between a script compiled normally and one compiled with the -optimize flag. The most significant difference I noticed was the -op code had a different order, but the .code remained identical. The temp variables count in the .localTable mostly remained the same, I think there was a reduction of 6 lines overall; from 912 to 906 for the optimized script.

User avatar
Sakura Haruno
 
Posts: 3446
Joined: Sat Aug 26, 2006 7:23 pm

Post » Wed Apr 01, 2015 5:14 pm

AH! thanks for the clarification. Most 90% of my scripts are now inside of various custom functions with only something like this to trigger them:

Onhit()

GoDoItNow()

endevent

That is why I though it applied to the entire script.

Er... I have a strange question for you as you created this system. If your team needed it, would it have been possible to make a special function (or command or what ever the term is , sorry I am a better fighter than a programmer even at my advanced age now) that would force the entire script to run in 1 or a few frames?

User avatar
Lovingly
 
Posts: 3414
Joined: Fri Sep 15, 2006 6:36 am

Post » Wed Apr 01, 2015 7:44 pm


The order of functions in the compiled data is (essentially) random and has no bearing on speed.

The Papyrus compiler was written mostly with an eye towards correctness (and even then it still has a few bugs people have found) - how many script instructions are emitted has less of a bearing on speed then the number of outside or native functions you call. As such, the optimization flag only does some very simple optimizations. For example I think it can figure out that 2 + 2 is 4 and replace the addition, and that 2 cast to a float is 2.0 and remove the cast. It was never heavily used, so I make no promises for the correctness of the code emitted with the optimize flag.

If you're really that worried about it, you can always hand-optimize the assembly and re-assemble it.


No, actually. Or at least, "yes" with a giant asterisk. The post-load update time essentially does this because it knows the game isn't doing anything else while the loading screen is up. Native functions can only be safely run in a few different "slots" in the frame, and not all of them are safe to run in all slots, so if you need, say, slot A, then B, then A again, it can't run that third function until the next frame when the slot opens up again.

And this assumes no one else is messing with the object you want to talk to at the time, thus preventing you from running while it holds the lock.

We're getting a little off-topic for this thread though.
User avatar
Dan Scott
 
Posts: 3373
Joined: Sun Nov 11, 2007 3:45 am


Return to V - Skyrim