Hi guys,

I've had little luck in finding answers via search, so I was wondering if there are any best practices when it comes to avoiding dialogue lag (lag experienced when the game is trying to load dialogue -- I've encountered it in Julan Ashlander Companion, and I've heard there are a few other mods that have it). What is most likely to cause this lag? Is it tied most to having too many topics, too many dialogues within a single topic, or too many scripts?

For instance, let's say that I've got a branching dialogue that includes around 200 possible lines within a single topic. Each line calls a script to generate player responses. The script may make between 1-20 if-then checks, set a couple of variables, and it may call one additional script that will also make if-then checks. Is this example likely to create dialogue lag?

Finally, is there any advantage to using globals over quest variables for your dialogue checks? I prefer to use quest variables to keep things tidy, but again, I don't want to commit myself to building these dialogues a certain way only to find out that my approach is horrendously laggy.

I have not played Morrowind in years. When I did, I did not experience lag when the dialogue window was open as I have heard reported. There was a time when some players complained about it when running most/all the LGNPC mods at the same time and there was an implicit notion that it might have been the result of overwhelming the dialogue tree with entries. The LGNPC project itself doubles the number of entries and players that use our mods likely use other plugins such as quest and companion mods that add considerable dialogue to the game. However it has been some time since I have heard this complaint so if it was a function of memory or processing power perhaps newer machines are not taxed as much.

My only first-hand experience with lag when viewing the dialogue window occurs while working in the editor. There the issue appeared to be the result of the number of filters assigned to a given dialogue entry. Lag would occur while moving through the list of entries that had a large number of filters. This is particularly noticeable (frustrating) when moving entries higher or lower in the list. I do not know if this is in any way related to lag in-game, but it does seem plausible. I have never tested this hypothesis.

I took a quick look at Julan Ashlander Companion and I noticed many entries that had four or more filters and lagged while I was in the editor. Of course, one thing might not have anything to do with the other. I know that LGNPC Pax Redoran and Vivec Redoran have heavily-filtered dialogue entries. The worst offender is Less Generic Bloodmoon (and probably Less Generic Tribunal). In his Less Generic mods, Ostar did not merely create new entries, he routinely added new filtered to official dialogue to prevent some NPCs from using the topic. Often this meant that an entry would use every filter slot available and navigating the entries in the editor was very tedious. Again, I have not proven that this profusion of filters would affect how quickly dialogue is processed while playing, but I have not dismissed it as a reason either.

If there is any credit to my suggestion that excessive filters create lag when in dialogue with an NPC, then to alleviate the problem you should avoid the extraneous use of filters. Checks for if NPCs are living or dead and checks for items in the player's inventory are likely to be more taxing then checks for journal indexes and global variables. If an entry is tightly filtered then subsequent choices need not include most of the initial filters. If you check Dead: Bolvyn Venim >= 1 in one entry there is no need to add the filter Dead: Bolvyn Venim = 0 in the next - he is most certainly alive if the previous check failed. If you check Item: Gold_001 >= 100 in one entry, the following entry need not check Item: Gold_001 < 100 since it is certain to be true. Such strategies as those may help reduce lag when the dialogue window is open.

I do not expect your use of scripted dialogue (in unto itself) would create dialogue lag. Of course, if you are checking conditions that are system-intensive such as inventory checks then that could slow things down.

In my mind, journal indexes and global variables are effectively equivalent - one is no better than the other. In fact, I consider journal IDs as 'free globals' and sometimes create dummy journal entries (ones not intended to be added to the player's journal) just to use the index as a filter. This requires the use of SetJournalIndex - a Tribunal function - so it does create a dependency on one of the expansions.

In order of filtering speed, I'd say:
global variables
JournalIndex (not much difference, e.g. about 1-2 FPS difference for 10000 global variable/GetJournalIndex calls per frame in scripts)
simple, not array/list traversing functions e.g. not cell, not class
more complex/list traversing functions e.g. dead, detected, and especially item (inventory based), proportional to list (NPCs, inventory...) to traverse size

Dialog filter may or not may be smart (e.g. skip testing condition 2 if condition 1 is false), would need testing but probably better put faster/more likely to trigger condition first anyway

In any case, like with player inventory related things, the more dialog entries you load, the more noticeable is the delay, not much you can do about it.

People are afraid of global variables vs journal I think mostly because they stay in save if you uninstall the mod, but cleaning them is a 1 click mash operation eventually

[EDIt] and I agree with cyran0, if editing dialog is lagging in CS, it is likely to lag also in game in a heavily dialog-modded setup

If you want an example of laggy dialogue, there's none worse than my Tea Giving add-on in the Tea Mod. It was so bad (on my old PC that was only a year younger than Morrowind itself) that I put a big warning about using it in the readme. A combination of inventory checks + hundreds of choice filters, and the fact that if you had any tea in your inventory you could offer it to anyone, meant every time you opened dialogue with any NPC it would freeze the game for several seconds while waiting for the dialogue window to pop up. It's still available for download along with the Tea Mod, but it's the perfect example of what not to do when adding tons of dialogue.


As for journal entries vs. global variables, I stick to journal entries for any linear event that the player might want to keep track of in their journal. Global variables are better for flagging events you want to be unintrusive or want the player to be unaware of, because if you use SetJournalIndex to trigger an event without a corresponding journal entry, that data isn't saved. If the player doesn't complete the quest to trigger an actual journal entry before they reload the game, the journal index will be reset back to the last journal entry they triggered, which can screw up quests. The game takes the highest triggered index value and wants to stay there, so triggering an earlier entry will add a journal entry if it wasn't added before, but won't set the index back down--using lower-indexed entries is a great trick for giving the player new information without triggering different question conditions though. So for pseudo-quests you want to be able to repeat, global variables are the way to go, because they can be set to anything and retain the last value set.

Thank you all for your feedback. I'll go ahead with my original implementation plan, then, since my filters will mostly be limited to checking the speaker, choice, and globals (which will be set in scripts before the conversation begins).

You can have empty journal entries (that really show as "EMPTY" in the editor, not containing whitespaces) for that purpose. They remain selected after reloading, yet they don't alert the player with popup windows.

Also, global variables are perfect to get/set/exchange information between different mods (as long as they are set to initial 0 value in CS and set only by scripting commands), as they can simply be declared to work. I am not sure Journal entries can be used the same way/so simply.

Global variables are perfectly reliable and perhaps the only way to detect with certainty that another mod is loaded. I have enjoyed success detecting if a stage in a quest has been attained in another mod. All that need be done is to duplicate the journal ID - no entries are required (or even advised). So long as the other mod's journal is set up properly another mod can check how far the quest has advanced. By that I mean it should hold true with the use of empty journal entries as described by Kir.

The only problem with empty journal entries is some third party utilities will delete them while cleaning. I ran into this problem with a blank journal entry I left in one mod for compatibility with another. Tes3cmd's clean function removed the journal topic completely, causing error messages. Just something to be aware of.