Difference between revisions of "Category talk:Editing Dialogue"

Jump to navigation Jump to search
3,379 bytes added ,  09:48, 28 January 2007
no edit summary
imported>JOG
(Description of bug in Addtopic Box)
imported>Blade9722
Line 29: Line 29:


--[[User:JOG|JOG]] 03:24, 15 July 2006 (EDT)
--[[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:
1) 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
2) 'Add Topics test 1.esp' being loaded last
#TestNPC1: TestTopic1 available after GREETINGS (correct)
#TestNPC2: TestTopic1 (and not TestTopic2) available after GREETINGS!!!!!
3) '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.
Anonymous user

Navigation menu