Difference between revisions of "Category talk:Editing Dialogue"

Category talk:Editing Dialogue (edit)

Revision as of 09:48, 28 January 2007

3,379 bytes added , 09:48, 28 January 2007

no edit summary

Anonymous user

imported>Blade9722

@@ Line 29: / Line 29: @@
 --[[User:JOG|JOG]] 03:24, 15 July 2006 (EDT)
+--[[User:Blade9722|Blade9722]] 09:48, 28 January 2007 (EST) (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:
+<pre>
+Created a new plugin:
+Create new NPC, TestNPC1
+Create new quest, priority 65
+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
+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.
+Place NPC into a cell (The Tiber Septim Hotel, not that it should make any difference).
+Saved Plugin as 'Add Topics test 1'
+Made another plugin but with different lines of dialogue and 2's instead 1's. Saved
+</pre>
+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:
+) Neither 'Add Topics test 1.esp' and 'Add 'Add Topics test 2.esp' being loaded last
+#TestNPC1: only rumors after GREETINGS
+#TestNPC2: only rumors after GREETINGS
+) 'Add Topics test 1.esp' being loaded last
+#TestNPC1: TestTopic1 available after GREETINGS (correct)
+#TestNPC2: TestTopic1 (and not TestTopic2) available after GREETINGS!!!!!
+) 'Add Topics test 2.esp' being loaded last
+#TestNPC2: TestTopic2 available after GREETINGS (correct)
+#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:
+#Plugin1 adds topic1 which FormID is ##111111
+#Plugin2 adds topic2 which FormID is ##222222
+#Plugin3 adds topic3 which FormID is ##333333
+Now, if the load order is this:
+Oblivion.esm
+Plugin1.esp
+Plugin2.esp
+Plugin3.esp
+The following FormIDs are assigned to the topics:
+topic1: 01111111
+topic2: 02222222
+topic3: 03333333
+And this is OK. Unfortunately, if you check the reference of the addtopic field is:
+for topic1: 03111111
+for topic2: 03222222
+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:
+#Plugin1 adds topic1 which FormID is ##111111
+#Plugin2 adds topic2 which FormID is ##111111
+#Plugin3 adds topic3 which FormID is ##111111
+The following FormIDs are assigned to the topics:
+#topic1: 01111111
+#topic2: 02111111
+#topic3: 03111111
+This is the beloved mods isolation, which prevents many conflicts.
+Unfortunately, if you check the reference of the addtopic field is:
+#for topic1: 03111111
+#for topic2: 03111111
+#for topic3: 03111111
+This is making topic3 taking the place of topic2 and topic1 also, as happened in my testbench.