[LE] Performance with long Utility.WaitGameTime()?

[WhiteWolf424242]

Hello,

 

It has been my general understanding that long wait times in scripts should be done with single updates, and Utility.WaitGameTime() should only be used only for short delays.

 

However, I have a scenario where multiple scripts are attached to the same object (a quest), and both should "do something later", but with different set time intervals.

As far as I know, each object can be registered for one update at a time, and each attached script then receives the same OnUpdate() event when that happens.

So I cannot independently register these scripts, and I don't want to rebuild another quest just to move the other updating script to it.

 

So how bad is it actually to have a script with a moderately long Utility.WaitGameTime()?

I thought that the script with the longer sleep period (random between 1-7 in-game days) would be kept on RegisterForSingleUpdateGameTime(), and the other script which has a bit shorter sleep time ( random between 12-36 ingame hours) would be used with Utility.WaitGameTime().

Also, this script is not an automated occurrence, it only executes on player commands ("ask an npc to do something"-type), which doesn't occur very often (quite rarely actually, some users will maybe never use this option).

 

Is this something that will eat fps and fry low-end cpu's and lengthen papyrus exectuion time to ages.... or there's not much to worry about?

I think not, but I thought I'd ask before committing to this solution.

[Evangela]

All that will happen to that script is that other function calls will not take place until the waiting period is over.

 

Consider this when deciding how long you want the operation to wait in terms of game time: By default, 1h and 12m real time is equal to 24 hrs game time (RT = GT / TimeScale).

Edited March 7, 2021 by Rasikko

[WhiteWolf424242]

Thanks, but that was not entirely my question. What I would like to know is how big of overall papyrus performance impact to expect from having such a paused script in the pool.

 

Anyway, I tried it in the meantime and I don't see a terrible performance drop with this script on. So unless someone advises otherwise, I guess this is fine.

[maxarturo]

The difference between the 2 are:

- RegisterForSingleUpdateGameTime() = Adds a 'Mark' in the game's time line, something like an alarm clock, and once the 'Register' has been called and the script has finish it functinons the script is no longer Active until the 'Alarm Clock' fires.

Disadvantage = Too many 'Register' functions can cause a file save corruption when that mod is uninstalled, and the 'Register' functions have not ended.

* Register functions are influenced by the in-game 'Wait' function.

- WaitGameTime() = Once the 'Wait' function is called the script will stop there and it will start 'To Count' the time which the 'Wait' function has, the script will not go into an 'Inactive State'.

Disadvantage = Too many 'Wait' functions will cause a performance issue, and it's something you cannot control since there is no way to know how many mods on the player's load order are using the 'Wait' function, just for this circumstance it's wise to avoid using long 'Wait' functions.

* Wait functions are not influenced by the in-game 'Wait' function.

Have a happy modding.

Edited March 10, 2021 by maxarturo