Category talk:Editing Dialogue

There seem to be some problems when using the Add Topic box for GREETINGS. That is, that if many mods add a line to the GREETINGS topic, even if it's unique to their mod (unique NPC, Quest etc..), the outputs of the Add Topic box only seems to function for the last mod in the load order that alter the GREETINGS topic. The lines of dialogue will play fine, but the topics will not be added properly if they use the Add Topic Box, unless it is the last one in the load order.

This is quite a hinderance as practically every quest mod will want to add something to GREETINGS. It is possible to get around this by always adding topics you want the NPC's to have immediately having spoken to them via scripts, but not every quest mod already done does this and it is causing some issues --Elessar VPR 22:34, 30 May 2006 (EDT)

Further testing seems to confirm this, see the post by JOG here and this thread --Elessar VPR 16:14, 6 June 2006 (EDT)

Bug in AddTopic-Box

When you add new infos to existing topics (e.g. GREETING) then the AddTopic box only works for the mod that is loaded as the last one (and doesn't get its FormIDs changed.)

I sniffed a bit in the ESP with a Hex-Editor and found out that the entry for the info-line contains the FormID of the topic that is added in the Add-Topic-box.

When a plugin isn't the last in the list, the FormID of this new topic is adapted (e.g. 01001234 to 02001234)

But the FormID that is stored in the Addtopic-data for the new line in the GREETINGS-topic is not changed. The game still looks for a topic with the FormID 01001234 but can't find it and thus the topic isn't displayed.

This doesn't happen for choices, and the AddTopic box works fine with new topics, so I assume the bug is that the routine that changes the AddTopic-entries decides whether to change the entry or not by looking at the FormID of the topic in which the line is spoken, while it should look at the contents of the Add-Topic box.

You can also reproduce this in the Construction Set. Addtopic-entries in GREETINGS or other topics from Oblivion.esm will be gone in the non-active plugin

--JOG 15:59, 6 June 2006 (EDT)

Retrieved from "http://cs.elderscrolls.com/constwiki/index.php/User_talk:Kkuhlmann"

--JOG 03:24, 15 July 2006 (EDT)

This bug is ever worse: it is not only preventing topics to be played, but also can cause spamming of topics to the wrong NPC.

In order to understand the problem, I simply replicated Elessar_VPR Testbench:

1. Created a new plugin:
2. Create new NPC, TestNPC1
3. Create new quest, priority 65
4. Create and add new topic, (TestTopic1) to quest, then add a line to be said with GetIsID set to the new NPC in the conditions
5. Add GREETINGS to the topics list and add new greeting line with GetIsID condition again set to new NPC. In the Add Topics box for the new greeting line I add TestTopic1.
6. Place NPC into a cell (The Tiber Septim Hotel, not that it should make any difference).
7. Saved Plugin as 'Add Topics test 1'
8. Made another plugin but with different lines of dialogue and 2's instead 1's.
9. Saved

What happened is that, for a lucky chance, TestTopic1 and TestTopic2 where saved with the same FormID (I mean the "root" part of FormID, after the first two "count" bytes).

Here's the result:

1) Neither 'Add Topics test 1.esp' and 'Add 'Add Topics test 2.esp' being loaded last

1. TestNPC1: only rumors after GREETINGS
2. TestNPC2: only rumors after GREETINGS

2) 'Add Topics test 1.esp' being loaded last

1. TestNPC1: TestTopic1 available after GREETINGS (correct)
2. TestNPC2: TestTopic1 (and not TestTopic2) available after GREETINGS!!!!!

3) 'Add Topics test 2.esp' being loaded last

1. TestNPC2: TestTopic2 available after GREETINGS (correct)
2. TestNPC1: TestTopic2 (and not TestTopic1) available after GREETINGS!!!!!

There's a simple explanation for this, and it can be easily checked with the CS. If you use addTopics button:

if the topic which is being added belongs to Oblivion.esm, all is working fine, as the AddTopic field correctly adresses the formID, which of course starts with '00' (for instance 00123456).

if the topic which is being added belongs to the plugin, unfortunately the Addtopic field, instead of addressing the formID on the base of the plugin load order, it place the plugin total count number as the first two bytes, independently from what plugin belongs the topic.

I explain better with this practical example:

1. Plugin1 adds topic1 which FormID is ##111111
2. Plugin2 adds topic2 which FormID is ##222222
3. Plugin3 adds topic3 which FormID is ##333333

Now, if the load order is this:

1. Oblivion.esm
2. Plugin1.esp
3. Plugin2.esp
4. Plugin3.esp

The following FormIDs are assigned to the topics:

1. topic1: 01111111
2. topic2: 02222222
3. topic3: 03333333

And this is OK. Unfortunately, if you check the reference of the addtopic field is:

1. for topic1: 03111111
2. for topic2: 03222222
3. for topic3: 03333333

This is making topic1 and topic2 unavailable.

Instead, if by chance there's the same FormID 'root' in different plugins, for instance:

1. Plugin1 adds topic1 which FormID is ##111111
2. Plugin2 adds topic2 which FormID is ##111111
3. Plugin3 adds topic3 which FormID is ##111111

The following FormIDs are assigned to the topics:

1. topic1: 01111111
2. topic2: 02111111
3. topic3: 03111111

This is the beloved mods isolation, which prevents many conflicts.

Unfortunately, if you check the reference of the addtopic field is:

1. for topic1: 03111111
2. for topic2: 03111111
3. for topic3: 03111111

This is making topic3 taking the place of topic2 and topic1 also, as happened in my testbench.

--Blade9722 09:48, 28 January 2007 (EST) (EDT)

Result Scripts and Conditions

It seems that the game is checking the conditions after the execution of each line in the result scripts. If a line changes the conditions to false, then the remaining lines will not run.

For instance :

condition :

( run on target ) GetItemCount MyItem == 0

result script :

player.AddItem MyItem 1
player.EquipItem MyItem 1

after the first line, the condition turns to false ; The item will not be equipped because the next line will not run.

--Thorskin 22 may 2008