I had a bit of unpleasant surprise yesterday.

I had an actor that started an idle sequence triggered from a dialogue tree. Up until yesterday he'd been just fine. Then he started getting a six or so second delay before doing anything. And the irritating thing was I hadn't really changed anything.

The catch was in the "really" of course. I have a large, complex function in a quest script - let's call it foo() and my quest fragment was something like

SSG_Quest_S q = GetOwningQuest() as SSG_Quest_Sq.foo(akSpeaker as actor, game.getPlayer(), true)

Anyway, I wanted to add some notification lines and traces to that, so I thought I'd encapsulate it in the main quest scripr

SSG_Quest_S q = GetOwningQuest() as SSG_Quest_Sq.salesman_foo(akSpeaker)

and have the quest script define:

function salesman_foo(actor a)	foo(a, game.getPlayer(), true)endfunction

So I did that, and that extra function call cost me six seconds of lag. I put it back the way it was and the delay went way.

So I'm assuming that in general, calling Script.foo() from inside Script.bar() must suspend the script thread and give all the other running scripts a slice before resuming. Which is a little worrying.

I also don't understand why I don't get this sort of delay for utility functions called internally. I have code that loops over arrays calling multiple local functions on each element. If I lost the thread for each of those calls my code would take forever. So is there some other explanation for the delay in this case?

If not, how best to code around the problem? Big, multi-parametered functions would seem preferable to writing complex code in tiny fragment boxes. I just wish I understood why this one call suffered such a penalty when internal script calls usually seem so cheap.

What's best practice here?

Funny you should mention it; I'm kind of having a similar issue, with a companion (scripted & packaged up) in a sub-quest. I'm not seeing 6 seconds, or anything like it, but I am seeing 1 second or so (a noticeable glitch before the script and packages kick in).

Before I moved the Follower to it's own quest, I wasn't seeing any issue. This would also be before 1.6 ... and that always makes me wonder with all of the changes and the hassle that brought with it.

I was wondering whether Quest Priority could be a factor? I intended to up my sub-quest prioroity to see if scripts within it were slower to run, as other higher-priority stuff was going on (which would kinda make sense .... although I would have expected more posts on here, about it, if that was the case).

[edit]

Hit wrong button. I was trying to correct a couple of typos.

Just so this isn't a totally wasted post... Quest Priority is interesting. Does it get passed on to scripts?

I wasn't using a sub-quest here but just calling one function from another, both defined in the same script. Still, that's not to say there couldn't have been other things going on elsewhere. But even then, I was starting with a new character, fresh out of LAL, so I'd not have expected too much happening in the background that I wasn't aware of...

I really want to understand what's going on here.

Definitely worrying, and not what the http://www.creationkit.com/Threading_Notes_(Papyrus) say. But does the lag improve significantly if you use a Player property instead of Game.GetPlayer() in salesman_foo()?

Hmmm... don't know. I was just moving the game.getplayer() call rather than adding one, so you wouldn't expect it to have a bearing.

It's definitely worth the experiment, though. Let me get this thing put back together again and I'll try it and see what happens.