I have referred to the Comprehensive Dialog Thread countless times over the years with special attention to JOG’s observations for reliable performance and compatibility, and yet I still do not know with certainty how it should be approached. Perhaps I am particularly dense, so you may have to explain it to me as if I was a child.

When I first read it a few years ago, I interpreted the information in that thread to mean that the asterisks flagging the original dialog above and below the point of insertion should be left; that these entries update and preserve the ‘pointer’ to the next or previous entry (depending on which side of the splice that entry is found). It seemed to make sense to me and form so strong an impression that I am puzzled now by the results I see when more than one mod alters the same topic. Re-reading the thread reinforces that impression, but I cannot find a definitive “never clean away the asterisks on either side of the insertion point”. In some posts it sounds like it is optional: a matter of convenience to avoid scores of nit-picking error messages.

LGNPC mods add considerable entries to existing dialog topics. There is no point debating the merits of creating new topics versus using old ones–this is what LGNPC must do. It also cannot be helped that these entries may have to replace the top or bottom official entry (some topics only have one or two entries). While testing two LGNPC mods together as they were designed to run, both mods observing the convention of leaving the changes on the original entries, there were (for me) unexpected changes in the order of the original dialog relative to the modded entries.

I read the thread again to see if I was missing something obvious. I checked how recognized experts in using dialog managed their mods (leaving the asterisks as I had expected). Still there is no load order of the two LGNPC mods where one does not break the other.

I wrote three test mods to better isolate the mechanics of the dialog database. Mods DialogA, DialogB and DialogC each add three new entires A1, A2, A3, B1, etc., for the same existing topics in a variety of different ways. They were made by creating a new entry, A3, at the insertion point and then copying that to create A2 and copying A2 to make A1. Sometimes the mods insert their dialog at distinctly different points (not always an option in practice), other times overlapping (the lower splice point of one is the upper splice point of another), and also cases inserting at the same point. These might be in between existing dialog entries or at the very top or bottom of the list, half were cleaned of the asterisks and the rest left with the splice points flagged as changed (as I long supposed was the preferred method). My results support an idea very different from what I had come to understand. Certainly this does not take into account irregularities introduced with more complicated mods created by different authors, but I expect that would diminish the reliability of either method. Here are my findings when all three mods are loaded at the same time in the editor:

I describe how the entries were made by the three mods relative to each other and the master file (Morrowind only). To save space, I will show from left to right the entries as they appeared from top to bottom. ‘---’ represents an original entry ‘-1-’ represents the original top or bottom line and ‘-2-’ represents the original second from top or bottom line. The time stamp of the mods from oldest to newest is A, B, C.

*Different insertion points, near top/bottom
top: -1- -2- A1 A2 A3 --- --- --- B1 B2 B3 --- --- --- C1 C2 C3 -2- -1- bottom
*Different insertion points, near top/middle/bottom [cleaned]
top: -1- -2- A1 A2 A3 --- --- --- B1 B2 B3 --- --- --- C1 C2 C3 -2- -1- bottom
*Same results, not unexpected and quite acceptable (but not always an option with ‘small’ topics and uncertainty about how other mods are created.

*Different insertion points, at top/middle/bottom
top: A1 A2 A3 -1- -2- --- --- B1 B2 B3 --- --- -2- -1- C1 C2 C3 bottom
*Different insertion points, at top/bottom [cleaned]
top: A1 A2 A3 -1- -2- --- --- B1 B2 B3 --- --- -2- -1- C1 C2 C3 bottom
*Same results, but not recommended for other reasons.

*Overlap: A near top, then B then C
top: -1- -2- -3- -4- C1 C2 C3 --- B1 B2 B3 A1 A2 A3 --- --- bottom
*Overlap: A near top, then B then C [cleaned]
top: -1- -2- A1 A2 A3 -3- B1 B2 B3 -4- C1 C2 C3 --- --- --- bottom
*Surprisingly, the cleaned version preserves the order of the entries as intended. The un-cleaned results are totally unacceptable.

*Same insertion point, near top
top: -1- -2- C1 C2 C3 --- B1 B2 B3 A1 A2 A3 --- --- --- --- bottom
*Same insertion point, near top [cleaned]
top: -1- -2- C1 C2 C3 B1 B2 B3 A1 A2 A3 --- --- --- --- --- bottom
*The cleaned version appears more reliable (if the stray third original line is broadly filtered it would break the dialog for Mods A and B ).

*Same insertion point, near bottom
top: --- --- --- --- C1 C2 C3 -2- B1 B2 B3 A1 A2 A3 -1- bottom
*Same insertion point, near bottom [cleaned]
top: --- --- --- --- C1 C2 C3 B1 B2 B3 A1 A2 A3 -2- -1- bottom
*Again the cleaned version appears more reliable.

*Same insertion point, at top
top: C1 C2 C3 -1- B1 B2 B3 A1 A2 A3 -2- --- --- --- bottom
*Same insertion point, at top [cleaned]
top: C1 C2 C3 B1 B2 B3 A1 A2 A3 -1- -2- --- --- --- bottom
*Even in this less desirable scenario, the cleaned version gives the more reliable output.

*Same insertion point, at bottom
top: --- --- --- -2- -1- C1 C2 C3 B1 B2 B3 A1 A2 A3 bottom
*Same insertion point, at bottom [cleaned]
top: --- --- --- -2- -1- C1 C2 C3 B1 B2 B3 A1 A2 A3 bottom
*No difference between cleaned and un-cleaned order of entries.

*The last two sets were repeated for topics with only one original dialog entry with the same results (except that there was only one original entry in the mix).

Am I missing something here? Are there some other variables that I am not taking into consideration in my tests that accounts for these results that seem at odds with the conventions I believe we have been embracing for years?

I checked the info-ID for all the new dialog and the original dialog at the insertion points. I output the information to check the previous and next line pointers, but I don’t think that was useful. Although all the pointers found their object in the linked list, I suspect that the very process of loading all three mods updated the pointers so they would be consistent with the current order of the dialog entries. I do not expect that to happen when three mods are loaded in the game. The only way I can detect that is as I have with my first test of actual mods. I am trying to devise a system of filters that might reveal what is going on, but it is beginning to look like a great deal of work if it is at all possible to measure what I want.

I should also point out that every LGNPC mod released to date cleans the asterisks at the insertion points. I had been in the process of changing that practice, but now I am not so certain that I should. Admittedly, there are those occasions that one LGNPC mod creates a conflict with another, but careless modding can answer for some of those instances. Generally they play well together.

If no reliable method for ordering dialog entries is known, I fear that LGNPC mods can not be made truly compatible with each other–to say nothing of compatibility with other mods. Merging all LGNPC mods into one esp could solve the internal compatibility issue, but besides being unwieldy (imagine searching through three hundred unfiltered entries under ‘latest rumors’ to find the one for a particular NPC that needs some adjustment that cannot be managed when the database is filtered–it will definitely slow production), it still does not mean that those best efforts cannot be undone when played along side a mod created by a different author.

Anybody?

Interesting. I also tend to leave the altered original lines, but thought the benefit was in minimising 'string changed' warnings, rather than a means of avoiding conflicts.

I was able to replicate your 'Overlap' results using the Abolitionists topic. However, if you reverse the load order such that A is the newest & C the oldest mod, the correct results are returned. The oddities you're experiencing in this case would then seem to be a product of how MW handles load order wrt dialogue.

If we examine what's happening in your first case:
1) MW first applies the changes from Mod A;
2) MW then applies the changes from Mod B;

• This overwrites A's changes to line -3-,
• The line -3- PNAM now links to line -2- rather than A3, ie there should be no lines between -2- & -3-,
• This forces lines A1-A3 to the bottom of the current chain, after the last entry in B (-4-)

3) MW then applies the changes from Mod C;

• This overwrites B's changes to line -4-,
• The line -4- PNAM now links to line -3- rather than B3, ie there should be no lines between -3- & -4-,
• This forces lines B1-A3 to the bottom of the current chain, after the last entry in C (-5-).

When I reverse the load order:
1) MW first applies the changes from Mod C;
2) MW then applies the changes from Mod B;

• This overwrites C's changes to line -4-,
• The line -4- PNAM now links to line B3 rather than -3-,
• This forces lines C1-C3 to the bottom of the current chain, after the last entry in B (-4-), ie retains correct relationship.

3) MW then applies the changes from Mod A;

• This overwrites B's changes to line -3-,
• The line -3- PNAM now links to line A3 rather than -2-,
• This forces lines B1-B3 to the bottom of the current chain, after the last entry in A (-3-), ie retains correct relationship.

If B were the newest mod you'd get yet a different outcome.

When you 'clean' these mods it eliminates the overwrites of lines -3- and -4-, so the intended relationships are retained, A1 follows -2-, B1 follows -3- and C1 follows -4-.

I didn't test all your other permutations, but presumably the same mechanism is at play.

So it would appear cleaning is the best approach when dealing with multiple mods altering the same dialogue topic, 'string changed' warnings be damned?

OldeCow, thank you for your detailed and well thought out post.

I follow your reasoning perfectly (thank you for including the info-IDs for previous and next lines). In the case where the three mods overlap each other in a predictable way, the changes they each make to the topic can be reconciled with each other by adjusting the load order as you have shown. This strategy has been used for years to make two mods compatible where one clearly breaks the other. It is possible (and with LGNPC likely) that such a change of load order might solve a conflict in one topic but create a new problem in a different topic. Unless the three mods ‘overlap’ in precisely the same way for each shared topic, then there can be no single load order that will resolve all conflicts.

Considering the example that we both analyzed:


You demonstrate very clearly that if the load order is reversed (in relation to the time stamp order) then the order would be:

top: -1- -2- A1 A2 A3 -3- B1 B2 B3 -4- C1 C2 C3 -5- -6- bottom

But if the three mods inserted new dialog for a second topic in this pattern:


Then the chronological load order would preserve the order for the second topic, but scramble the order (as we have already seen) for the first topic.

I did change load order, but I found that for the likely situation (where the insertion point is the same) changing load order only altered which mod’s dialog is best preserved and which two may be broken. You have inspired me to look more closely at changing load order. I have reproduced your results and verified your conclusion. In cases where each mod shares the same insertion point I have confirmed that changing load order merely favors the last to load at the expense of the other two. I should say that is the case if the entries on either side of the insertion are not cleaned, when cleaned it seems to behave as intended.

I am not dismissing your observations–I am most appreciative of your efforts and insights. In fact your methods suggests a more dynamic process within the dialog database as mods load than I previously considered. Some speak of the dialog string of an older mod being broken when a newer mod is loaded. I may have misinterpreted what this meant. I imagined pointers losing their references and blocks of dialog being set adrift at the mercy of chance. Or two new entries sharing a previous line or next line reference with equally chaotic results. That sounds ridiculous and far too random a process to be true. From your examination I form the picture of the newer mod usurping the previous and/or next line reference from the older mod. But dynamically the pointers update so that the older mod’s dialog block is still part of the linked list except that its pervious line has to be the next line of the younger mod. This thinking is consistent with the dynamics of when the mods are loaded together in the construction set. If I output the new dialog I can compare the info-IDs for each case where a different test mod is made active. The info-IDs are always shows a fluid progression from one dialog entry to the next so it appears that such a process does exist.
Applying this reasoning to when the three mods share the same insertion point and we can understand why the third original line appears between the newest mods block of dialog and the next two.



When ModC loads last it points to the common second line as its previous line and it in turn points to link C1. That means that it no longer points to A1 or B1. C3 points to the common third line as its next line. But it points back to C3 as it previous line and not A3 or B3 anymore. The common third line by default becomes the previous line to B1, that is the original dialog line that I have seen placed between the new dialog added by different mods and leads to possible conflicts. The rest follows in order B2, B3. Now since B3 no longer can point to the original line three as its next line it references A1. The rest follow suit and A3 is left to point to original fourth line as its next line.

Now that is not just the case where the original dialog on either side of the insertion point is not cleaned. I think the process for when they are cleaned is very similar. The last mod to load assumes the second line as its previous. But perhaps cleaning the original insertion points does not pinned them to a particular mod. B1 would ordinarily follow the original second line, but instead points to the last line (C3) that is in the position of the insertion point relative to how ModB was created. Since the original third line is no longer defined as the next line for ModC (not in absolute terms but only in relative terms), the original third line is not placed between C3 and B1 so the dialog string seems continuous as intended. So long as all mods that insert dialog at that point clean the original lines on either side of the insertion point they should follow in reverse of the load order until the original third line is reached.

Where problems might arise is when one mod cleans and the other does not. If the clean mod loads last it will not impose its absolute references to the pervious and next lines on the other mod, so they should not break each other. However it the load order is reversed, then the original third line displays between the two blocks of dialog introduced by the two mods and the second (cleaned) mod is potentially broken. I have tested this theory by creating a fourth mod ModD that cleans for a topic I did not previously clean and left marked as changed the insertion points for a topic that was cleaned for the other mods. The results are exactly has this reasoning predicted: when the un-cleaned mod loaded last its absolute pointers reset those of the older mod and pulled up the original third line (potentially breaking it).


*First case (ModA cleaned/loads first, ModD not cleaned/loads last):
top: -1- -2- D1 D2 D3 -3- A1 A2 A3 --- --- --- --- bottom
*Second case (ModA not cleaned/loads first, ModD cleaned/loads last):
top: -1- -2- D1 D2 D3 A1 A2 A3 -3- --- --- --- bottom

This suggests that cleaning works best, but only if all modders clean dialog in this way. Otherwise potential conflicts result with the result with which we are long familiar: the last mod to load wins.

The overlap is certainly the least desirable way to proceed, since it offers the least amount of control. I only included it for the sake of being thorough. The most desirable approach is where each mod inserts their dialog at different points. In such a situation there will be no conflict between any of the mods. However, that is not an option with topics that have few official entries, and one cannot depend upon it happening with the mods of other authors. My interest is to figure out how to preserve the order when each mod uses the same insertion point. This gives the most control (I know where each mod makes their changes) and since some topics have so few official entries it requires that the insertion be made at the same point–even at the very top line. I understand that this assures that there will be potential conflict between each mod adding entries to the topic. But if it can be predictable, and if it doesn’t elevate an official entry above one or more of the modded entries (an official NotLocal noLore-filtered entry would severely break a LGNPC mod), then at least all LGNPC mods could be made compatible with each other.


My preliminary conclusion also, but previous discussions seemed to endorse the exact opposite for more reliable performance and so I am reluctant to trust it. Have I completely mis-interpreted your argument, JOG, or is there something else that I have not yet considered?

First, I really like the level of detail that went into the experiments discussed in this thread. it's no nice to see actual data.

Dialog has always made me nervous. My current save has some weird dialog problems (that wassisname Fyr telvani dude won't discuss his daughters, I can't get the topic to finish the Caldera "stop the mining" quest. non-plugin NPCs who are suppose to follow the player stop doing and and only the use of the "give you orders" plugin works around the, etc. etc.) and I will never know which combination of plugins caused it.

I was going to add dialog to my Thoogera plugin (eventually it will be released, I'm still tweaking it) but I think now I'll skip the dialog.

I'm rather surprised this thread hasn't generated more discussion, given its importance. As it stands, I still have no idea what I should do with my dialogue when adding to existing topics/greetings, and I've been keeping an eye on this thread in the hope of finding out. It does seem that cleaning might be the way to go, but I'm a bit reluctant to do that while the experts are still uncertain.

So, y'know... if some terribly clever person wants to hand everyone the answer on a platter, do feel free to post it.

This is a very valid discussion, I think you guys for your work in determining the facts here. This is just one more bit of proof that despite popular opinion, Morrowind modding is not dead. There's still so much for us to figure out and perfect!
I don't really have anything much to add since I tend to create things that don't require much dialogue; therefore I haven't experimented much with it. Everything I do is generally simple a straight-forward. But I will keep a close eye on this and determine if I need to start "cleaning" the dialogue out of my mods.

Like many modders, I started out with a healthy respect for adding dialog. To be honest, it was little less than fear. I didn’t really understand how it worked so I was concerned that I might not recognize a mistake until it was too late. I know that is not a very reassuring admission from the administrator of the LGNPC project, but I suspect my apprehension is representative of many of us. Unlike scripts that tend to function predictably and reliably when used along side other mods, knowing how the dialog changes of one mod may affect that of another is less straightforward.

It was not my intention in this tread to reinforce modder’s anxieties about working with dialog (although that may account for it falling silent for nearly two weeks). Most modders need not worry very much about these compatibility issues. Much of modded dialog is narrowly filtered entries under new topics. Certainly there is a possibility for two modders adding the same new topic and creating a possibility of conflict (that’s way we include AddTopic to the results section of the entry that introduces the new topic). LGNPC’s situation is rather unique. We change dialog in official topics at a grand scale. Our concerns are of breaking official quests and even conflicts with our own mods. Still, if another mod decides to add a new rumor, there is the potential for problems.

Now that I am embarking on a grand effort to improve compatibility between LGNPC mods with each other and all mods in general I really want to know whether or not is advisable to clean the official entries on either side of the insertion point. This is not a project that I want to do more than once!

My attention-span is too short ATM to fully read and understand/reproduce your posting (I did my own tests over 4 years ago...)


So just a comment to the original dialogue:

When anyone refers to my research, "unclean" means "New dialogue uses old ID and old dialogue uses new ID" not "old dialogue using old ID is marked with an asterisk" (To see the ID enlarge the minimized "Info ID" column between "Info" and "Disp/Index")



The original dialogue isn't required as long as you only change the previous line or the next one, you can safely remove it with TESAME, but may get some error messages when loading the mod into the CS (just like when you load both Tribunal and Bloodmoon) Removing an original line that has both, a new following and a new previous line, will break your mod's dialogue-chain, of course, causing parts of your new lines being sorted in in the wrong sequence or ignored completely.

Along with the line and its ID, Morrowind stores the IDs of both, the next and previous line. The line IDs are stored as verbose text (not as longint like Oblivion) adding a line after an existing line changes the "Next-line"-entry for the old line, and thus it is changed and stored in the ESP as well.

When two mods add lines at the same position, and retain the modified original lines, then you'll have two versions of that original line, and you'll end up with conflicting pre/next informations which will lead to new dialogue being sorted in at the "wrong" place but not in the wrong sequence unless one of the mods has unclean dialogue (as I meant it).



I didn't do any research regarding the exact position of the new lines and the original lines like you did, though, I concentrated on the interactions between new dialogue-lines that are independent from the original lines but are added by two mods at the same place. (i.e. new greetings or rumors for new NPCs)

You never can be sure where exactly your new lines will be sorted in when there is more than one mod involved (see your research) Thus I'd say the safest way to insert new lines into an existing dialogue-sequence (i.e. its important that your line "A1" is placed before the original line "3") is not to touch the original dialogue at all, but add new dialogue far above it and include new copies of the original lines you wanted to retain.

I.E. not:

Old 1 (Uninvolved)
Old 2 (Uninvolved)
*A1
*A2
*A3
Old 3 (needs to come after A1-3 but before A4-5)
*A4
*A5
Old 4 (needs to come after A4-5)
Old 5 (Uninvolved)

But:

Old 1
*A1
*A2
*A3
*Copy of Old 3
*A4
*A5
*Copy of Old 4
Old 2
Old 3 (still existent but no longer used ingame)
Old 4 (still existent but no longer used ingame)
Old 5

I hate to be the first person to ask for the scaled-down version for dummies, but...

Would I be right in thinking that's a confirmation that cleaning changes from original dialogue is the safest way, plus a caution not to mix new and old dialogue but rather keep the new dialogue together at a single insertion point?

…and I don’t want to be the first one to try and interpret what JOG meant.

@Melian: While I did not read a confirmation of the ‘cleaning’ practice, it was not a condemnation of it. It does seems much safer to insert new dialog in a continuous block is possible and avoid having alternating new and official entries throughout the topic.

@JOG: Thank you for the clarification. I suppose I misread you old post, and as so often happens read into your words and explanation for my question rather than recognizing what you were actually discussing.

I do not like to tamper with original dialog except to insert my own dialog. The only occasion to change it would be to correct content or typos as has been done with the Unofficial Patch. I might alter the filtering to make a hole so my dialog might peak through, but I would not dream of moving it. It therefore seems unlikely that the circumstances would arise that ‘unclean’ dialog (as you mean it) would occur. I am not certain why a duplicate of an original entry would create a problem unless we are speaking of a ‘copy’ created rather than a ‘new’ entry, (and even then I am not certain). I will have to puzzle over that a little longer or test it in a way that is easier for me to see. However, I will accept the wisdom of moving such an entry away from the original.

This seems to reinforce the idea that cleaning the asterisks from the original entries is up to the modder’s discretion. I have heard some leave them to avoid the annoying error messages when loading the mod in the editor. However, my tests indicate that it still affects how two different mods, inserting dialog at the same point, will dovetail.

As I have stated before, LGNPC is fairly unique in the degree to which it impacts official dialog. Most certainly, different LGNPC installments will share insertion points on some topics (some generic topics only have one or two entries). Rather than try to avoid the impossible we will embrace the horror and insert new dialog at the same point in each topic. The following conventions will be observed:


Greetings are another matter. Presumably they are roughly sorted into categories that not all modders utilize (LGNPC mods are guilty of this). This lack of consistency makes it more difficult to predict how two different mods will work together. Fortunately, most modded dialog is filtered for NPC ID, but conflicts are certainly possible. Modders like to place their greetings high (Greeting1 for instance) to feel confident that another mod (or the official dialog) will not break their work. This increases the likelihood that their mod will break another mod or official quests. The latter is a real concern. LGNPC mods have done that in the past. Recent installments are more sensitive to how our additions affect existing quests. Dialog is filtered for individual NPCs to see what official dialog and greetings already exist for them and preserve those entries if they are important. But that does not mean errors are not made. Better is if we place greetings as low as is possible.

While it may sound like I am making a unilateral decision that dictates to other modders how they should organize their dialog that is not my intention. Still, I am happy if you think so since it is the best way to provoke further discussion on this topic. I cannot control how other modders have/will structured their dialog, so it is still possible that conflicts between mods will occur. These conventions are in the interest of making LGNPC compatible with each other. The common insertion point in particular since this makes load order a reliable predictor of how two mods will perform together (assuming that each mod cleans out the asterisks). An omission in my earlier tests was to see how a ‘cleaned’ mod interacts with a ‘non-cleaned’ mod when they each insert dialog at the same point. I will perform such tests if only to understand how the dialog string might be broken. It cannot be controlled, but at least it might make it easier to recognize real conflicts between mods.

Another important safety tip has to do with deleting a new line of dialog out of a block of new entries. Doing so will disrupt the previous line/next line references and cause the new entries below the deletion point to be move to the bottom. To safely remove a single entry move it well away from any new dialog and delete (and clean around) it.

For anyone curious about how I have come to this conclusion my tests result follow:


Results of deleting a single (or consecutive) line of new dialog from a block of new dialog.

I describe where the block (X1 X 2 X3) was inserted relative to official entries, and where the new entry (always X2) was moved before deleting. ‘Clean’ trials are those where the original entries on either side of the insertion point were cleans of the ‘*’. In all instances where the entry X2 was moved the original dialog affected was cleaned of ‘*’ except for the insertion points for non-cleaned trials. To save space, I will show from left to right the entries as they appeared from top to bottom. ‘---’ represents an original entry ‘-1-’ represents the original top or bottom line and ‘-2-’ represents the original second from top or bottom line.


*Inserted at top / X2 not moved:
top: X1 -1- -2- -3- --- --- -2- X3 -1- bottom
top: X1 -1- -2- -3- --- --- -2- -1- X3 bottom (cleaned)
Both are unacceptable.

*Inserted near top / X2 not moved:
top: X1 -1- -2- -3- X1 --- --- --- X3 -4- bottom
top: X1 -1- -2- -3- X1 -4- --- --- --- X3 bottom (cleaned)
Both are unacceptable, but non-cleaned is worse.

*Inserted at bottom / X2 not moved:
top: --- --- --- -4- -3- -2- -1- X1 X3 bottom
top: --- --- --- -4- -3- -2- -1- X1 X3 bottom (cleaned)
Both are acceptable, but this is a special case where new dialog cannot sink any lower.

*Inserted near bottom / X2 not moved:
top: --- --- --- -4- X1 -2- -1- X3 -3- bottom
top: --- --- --- -4- X1 -3- -2- -1- X3 bottom (cleaned)
Both are unacceptable, but non-cleaned is a little worst.

It is not a good idea to delete new dialog without first moving it way from other new dialog that you wish to keep in its current order relative to itself and the official entries.


*Inserted at top / X2 moved to top of new dialog block:
*Not performed–would be the same as inserted at top / X2 move to top.
top: -last- X1 X3 -1- -2- -3- --- --- bottom
top: -last- X1 X3 -1- -2- -3- --- --- bottom (cleaned)
Both are very unacceptable.

*Inserted near top / X2 moved to top of new dialog block:
top: -1- -2- -3- -5- --- --- --- X1 X3 -4- bottom
top: -1- -2- -3- X1 X3 -4- --- --- bottom (cleaned)
Both are unacceptable, but the non-cleaned is a little worse.

*Inserted at bottom / X2 moved to top of new dialog block:
top: --- --- -3- -2- -1- X1 X3 bottom
top: --- --- -3- -2- -1- X1 X3 bottom (cleaned)
Both are acceptable, but this is a special case where new dialog cannot sink any lower.

*Inserted near bottom / X2 moved to top of new dialog block:
top: --- --- -4- -2- -1- X1 X3 -3- bottom
top: --- --- -4- -3- -2- -1- X1 X3 bottom (cleaned)
Both are unacceptable, but the non-cleaned is a little worse.

*Inserted at top / X2 moved to bottom of new dialog block:
top: -1- X1 X3 -2- -3- --- --- --- bottom
top: X1 X3 -1- -2- -3- --- --- --- bottom (cleaned)
Cleaned trial is acceptable, the non-cleaned trial could break things for mod.

*Inserted near top / X2 moved to bottom of new dialog block:
top: -4- -1- -2- -3- X1 X3 -5- --- --- bottom
top: -1- -2- -3- X1 X3 -4- -5- --- --- bottom (cleaned)
Cleaned trial is acceptable, the non-cleaned trial could break things for master.

*Inserted at bottom / X2 moved to bottom of new dialog block:
*Not performed–would be the same as inserted at bottom / X2 move to bottom.
top: --- --- --- -3- -2- -1- X1 X3 bottom
top: --- --- --- -3- -2- -1- X1 X2 bottom (cleaned)
Both are acceptable, but this is a special case where new dialog cannot sink any lower.

*Inserted near bottom / X2 moved to bottom of new dialog block:
top: -3- --- --- --- -4- X1 X3 -2- -1- bottom
top: --- --- --- -4- X1 X3 -3- -2- -1- bottom (cleaned)
Cleaned trial is acceptable, the non-cleaned trial will break things for master.

Moving the new entry to be deleted may give satisfactory results if the conditions favor it (such as already having the new dialog block at the bottom of the tree). But as a general practice it should be avoided. Certainly there are occasions where it is necessary so do so under those circumstances that will give acceptable results.


*Inserted at top / X2 moved to top:
top: -last- X1 X3 -1- -2- -3- --- --- bottom
top: -last- X1 X3 -1- -2- -3- --- --- bottom (cleaned)
Both are very unacceptable.

*Inserted near top / X2 moved to top:
top: -1- -2- -3- X1 X3 -4- --- --- bottom
top: -1- -2- -3- X1 X3 -4- --- --- bottom (cleaned)
Both are acceptable.

*Inserted at top / X2 moved to bottom:
top: X1 X3 -1- -2- -3- --- --- --- bottom
top: X1 X3 -1- -2- -3- --- --- --- bottom (cleaned)
Both are acceptable.

*Inserted near top / X2 moved to bottom:
top: -1- -2- -3- X1 X3 -4- --- --- bottom
top: -1- -2- -3- X1 X3 -4- --- --- bottom (cleaned)
Both are acceptable.

*Inserted at bottom / X2 moved to top:
top: --- --- -3- -2- -1- X1 X3 bottom
top: --- --- -3- -2- -1- X1 X3 bottom (cleaned)
Both are acceptable.

*Inserted near bottom / X2 moved to top:
top: --- --- -4- X1 X3 -3- -2- -1- bottom
top: --- --- -4- X1 X3 -3- -2- -1- bottom (cleaned)
Both are acceptable.

Inserted at bottom / X2 move to bottom.
top: --- --- --- -3- -2- -1- X1 X3 bottom
top: --- --- --- -3- -2- -1- X1 X2 bottom (cleaned)
Both are acceptable, but this is a special case where new dialog cannot sink any lower.

*Inserted near bottom / X2 moved to bottom:
top: --- --- -4- X1 X3 -3- -2- -1- bottom
top: --- --- -4- X1 X3 -3- -2- -1- bottom (cleaned)
Both are acceptable.

Moving the new entry to be deleted to either extreme (and I expect any point well clear of new dialog block) will result in a clean removal of the unwanted new entry without scrabbling the order of the new entries relative to each other or relative to the official entries. The sole exception to this is if the block is at the top. In that case, the line(s) to be deleted should be move lower first. Another method suggested by Kateri is to export the dialog, remove the dialog line and reassign the previous line/ next line references across the breach before importing the dialog. Your call.


These outcomes can be explained with a discussion about previous line/next line pointers, but I doubt many of you care about that, and most of you who do can probably figure it out for yourself.

Thank you!

I do believe I'm getting a handle on in now. I had also misinterpreted JOG's old post in exactly the same way you did.

Greetings are of particular concern to me: Companions usually have greetings high up (0 and 1) so as to avoid all official dialogue (especially vampire/werewolf/nudity/crime) and allow 'telepathy' forcegreetings. Guard-class companions need greetings above official guard-class crime greetings, which really leaves modders with no room to move. Being better able to predict and understand how the mods will interact should make compatibility easier.


I'd be very interested in your findings. I did try to set up some tests myself, but I haven't managed anything useful (and I keep getting distracted!).


Another possibly-stupid question (sorry!)... When you say you deleted it, do you mean you deleted it (in the dialogue editor), or toggled the ignore flag (in details view)? I've never had a problem deleting entries, and after your post about the ignore flag on Emma's forum I tested it again, exported the dialogue, checked the next/previous IDs and so on - it was all correctly updated automatically in the CS. Toggling the ignore flag messed it up, though, because the next/previous IDs weren't updated.

Am I missing something here? Or maybe there's some other reason not to delete lines in the dialogue editor? (I'm only referring new dialogue, of course, not Bethesda dialogue!)

You are right I was unclear when I wrote of deleting dialog. I was referring to toggling the ‘ignore’ flag (or cleaning with a third-party utility such as TESAME). The embarrassing fact is that I have forgotten about simply deleting the entry in the dialog window with a right mouse click. I had fallen out of the habit of using it since it is not a viable way of ‘cleaning’ official entries. To remove the asterisks (or other unwanted changes) from official entries you would want to toggle ignore from the ‘Details’.

A couple quick checks shows that deleting your new entry in the dialog window had none of the adverse effects I wrote of even when deleted from the middle of a new block of dialog. This must be the preferred way of removing unwanted new dialog. I can only speculate about the difference between the two methods, but I suspect that ‘deleting’ the entry in the dialog window allows the previous line/next line references to update and be saves. Toggling ‘ignore’ and then loading the mod in the editor leave ‘loose-end’ references that result in the dislodging of the part of the dialog block that lost its reference.

The other tests I wrote of and you have inquired about have not been performed [very busy]. I should get to it in a few days and I will post my results.

Apparently I already ran those tests and they are pretty much as you would expect, the last mod to load wins. However if the cleaned mod loads last, it is pretty much a win for the other. The problem arises when the ‘non-cleaned’ mod loads last and moves the reference point for the ‘cleaned’ mod. It looks like this:

*Same insertion point near top of topic, ‘cleaned’ mod (modA) loads first, non-cleaned mod (modD) loads last:
top: -1- -2- D1 D2 D3 -3- A1 A2 A3 -4- --- --- --- bottom
*Same insertion point near top of topic, ‘cleaned’ mod (modA) loads last, non-cleaned mod (modD) loads first:
top: -1- -2- A1 A2 A3 D1 D2 D3 -4- --- --- --- --- bottom
The latter is acceptable so long as modA does not include broadly filtered entries that might prevent modD’s responses from displaying (usually not the case since the majority of modded dialog is filtered for ID).

Thanks so much your answers, and for taking the time to post all this, cyran0!

This thread should definitely be saved somewhere, if it hasn't been already. I know I'll be referring to it in future.

The thread is in Yacoby's ES Forum Archive, though it hasn't caught the recent posts yet as it only checks for updates every 3 months iirc.

Sorry, thread necromancy, but this strikes me as an important topic.

In the light of recent problems I have had, I have just reread this thread. Here is my best guess explanation of what happens. Say we have an original topic in Morrowind like this:


My mod adds a single line. The unclean version would be (*m indicates the line has been modified by me):

I guess when the mod is loaded, it inserts after line 1, as the top line in my mod points to Original line 1, and it overwrites Original line 2 and Original line 3, as they have the same IDs as Original line 2 (*m) and Original line 3 (*m) respectively. All well and good.


The clean version would be:

This is inserted after line 2, as the only line points to Original line 2. Morrowind must modify line 3 to point to this as the mod is loaded. This would give identical results.

Ah, but your mod adds a single line at the same point. The unclean version would be:

If lines 2 and 3 are overwritten, that would leave my mod line in limbo, but from the above Morrowind copes with that, putting your mod line in front of mine. I am guessing that it inserts all three of the above lines before mine, so original line 3 now appears in front of my mod line:


The clean version would be:

This would work properly (regardless of whether my mod was cleaned), as only the one line is being inserted. Say my mod was not clean:


Suppose instead, your mod added lines between original lines 3 and 4. This would be the unclean version.

Here is what Morrowind has after addng my unclean version again, before we add yours (the effect is the same if my version is clean):

As Original line 3 (*y) in your mod points to 2, it gets inserted after Original line 2 (*m). And as your mod includes line four, that also goes before my mod line, which is pushed down to the bottom.


Now if you had cleaned your mod, it would look like this:

This will get added after line 3, so gets inserted at the correct point.


What probably happens: As each dialogue line of a mod is loaded, Morrowind checks if that ID has already been used. If it has, the old one is deleted, and the next/previous pointers either side of it updated. Then the new line is the inserted after the line indicated by the previous pointer. The next pointer of the previous line is set to point to the new line and the next pointer of the new line is set to point to the line that the previous line used to point to, to give a continous linked chain.

This seems to all make sense (i.e., if I were writing the Morrowind software, this would seem a good way to write it), and to explain the results you were getting.
All this convinces me that cleaning dialogue is going to ensure your mod has a better chance of being compatible with earlier mods (whether the earlier mods were clean or not).

No need to apologize for adding more to our understanding of how the dialog database works.

I appreciate your theory about how the pointers might update as each mod loads in turn. I felt like I could predict what would happen when one mod’s changes interact with another but I never understand why (what mechanism would make it possible). I still have difficulty seeing how the pointers can update on the fly even though I can observe the outcome of it happening when I load two mods in the construction set at the same time. One could even merge the two and then export the data so all of the reference information is visible, but it will not reveal how the second mod to load, knew to point at the last line of the previous mod to load rather than the official line it was originally pointing. I suppose it must be something like how the pointers update as entries are moved relative to each other in the editor, those effects are immediate.

Thanks for your insights on this subject.