Assertion when copying INFO in TES4Edit

[GoogleCodeExporter]

I get "Assertion failure (D:\Projects\TES5Edit\wbImplementation.pas, line 
11051). " when trying to copy a Dialogue ligne.

I get the same error on : 

DLCBattlehornCastle.esp (French Version) :
    GREETING 0X00DE20
    GREETING 0X013416
    GREETING 0X013916
    GREETING 0X0142EE

DLCVileLair.esp (French Version) :
    HELLO 0X007970

In past, I get the same Error With FNVedit in the same condition.

Bug report attached.

Original issue reported on code.google.com by ginnunga...@free.fr on 9 Aug 2013 at 2:39

Attachments:

• TES5Edit_bugreport.txt

[GoogleCodeExporter]

Thanks for report.
I can't reproduce this with the current svn version and english 
DLCBattlehornCastle.esp, so assuming it is fixed already.
Lets keep it open just in case the bug returns somehow in upcoming 3.0.31

Original comment by zila...@gmail.com on 9 Aug 2013 at 7:43

[GoogleCodeExporter]

I can eventually give you Esps used with my error. Or, I can test With your SVN 
version for confirm that this was fixed, where can I find it ?.

Original comment by ginnunga...@free.fr on 9 Aug 2013 at 8:07

[GoogleCodeExporter]

I did a test : 
- With DLCVileLair.esp English version and the same target ESP, I get also the 
error.
- With DLCVileLair.esp and a different target ESP, I don't get the error.
==> The error come only with DLCVileLair.esp + My target ESP.

So, I joined my target ESP to this comment (For Vile Lair and Battlehorn 
Castle).

Original comment by ginnunga...@free.fr on 10 Aug 2013 at 1:46

Attachments:

• TargetESP.7z

[GoogleCodeExporter]

I know where the possible error is. It occures when sorting INFO records inside 
DIAL by previous info record in PNAM field. I disabled it for FO3/FNV that's 
why you don't see such error there anymore, but it is the first time reported 
to cause problems for Oblivion too.
I'll make it optional in 3.0.31 via "Options" menu.

Original comment by zila...@gmail.com on 10 Aug 2013 at 5:07

[GoogleCodeExporter]

OK, thanks.

There is a solution for copying my lines waiting the 3.0.31 ?

Original comment by ginnunga...@free.fr on 10 Aug 2013 at 5:57

[GoogleCodeExporter]

I succeed to copying my lines. But that was tedious : 
- I removed my lines from the PNAM field in other lines in the target file.
- I Copied my lines.
- Save and close.
I needed to repair the PNAM on lines I removed it : 
- I tried to copy the PNAM field on all lines, but I get another "Assertion 
failure" when saving the file.
- I tried to copy the PNAM and save/quit one line by one line. That worked.

Original comment by ginnunga...@free.fr on 11 Aug 2013 at 3:25

[GoogleCodeExporter]

Good. I made INFO sorting optional in 3.0.31

Original comment by zila...@gmail.com on 11 Aug 2013 at 4:03

[GoogleCodeExporter]

Will you please make it optional for FO3/FNV too?

When you sort INFOs, is that also the order they are Saved In The Plugin when 
you save it? If so, is it possible to sort them the way the Geck/CK actually 
save them in the plugin? Like this under the DIAL record:
1. First INFO - find the INFO with PNAM of 0 or from a master
2. Second INFO - find INFO with PNAM that points to First INFO
3. Thrid INFO - find INFO with PNAM that points to Second INFO
4. etc

The reason I ask, is if INFOs are not stored this way in the plugin, then the 
GECK/CK throw PREV INFO errors when loading it. Mostly this causes problems for 
people working on projects where the order of the INFOs in the esp, in the 
GECK/CK, has been changed in regards to the master. Updating the master from 
the esp breaks the INFO chain unless there is a way to sort the master after 
PNAM's have been edited.

Original comment by rickerhk...@gmail.com on 3 Sep 2013 at 2:32

[GoogleCodeExporter]

It is completely disabled for FO3/FNV in 3.0.30, so you want to make it 
optional?

Original comment by zila...@gmail.com on 3 Sep 2013 at 3:38

[GoogleCodeExporter]

I can't speak for Tes4Edit, but in FO3/FNV, the only time I can think that 
anyone would need INFOs to be re-sorted in a master would be after updating a 
master from a plugin - ie: dragging the PNAM subrecord fields from the esp to 
the master, where the esp has over-ridden the master. So an option would be 
good, and default to Off. Even a script to do it would be good - maybe better - 
more flexible? To select the affected topics and run the fixup script.

Original comment by rickerhk...@gmail.com on 4 Sep 2013 at 1:21

[GoogleCodeExporter]

To write a script I need to understand how INFO sorting works. The way you 
desribed it is not how xEdit sorts them. It also checks INFOs in all overridden 
plugins, checks QSTI field in DIAL, builds some linked list, etc.
When I tried to fix it last time it took me way too long to even understand 
whats happening, so I just disabled it. And in 3.0.31 it is disabled by default 
but can be turned on back in options.
If I ever come back to that code, I'll fix directly instead of writing a script 
:)
Hlp also wanted to check it himself, but I guess he is busy with own projects 
atm. 

Original comment by zila...@gmail.com on 4 Sep 2013 at 5:44

[GoogleCodeExporter]

On Fallout3/NV my main concern was sometime getting assertions when copying or 
modifying INFO records. But, as I haven't written any dialogue quest in months 
(years now :) ?) I don't even know if the issue persist.

Original comment by HuguesLe...@gmail.com on 4 Sep 2013 at 10:44

[GoogleCodeExporter]

Then I'm not sure what you mean by sorting INFOs. Is it for display purposes? 
If that is the case, then I have not missed it since you turned it off :)
I'm talking about how the INFOs are serialized in the plugin. The order in 
which they are saved is important to the Geck and needs to be re-arranged if 
PNAM subrecords are modified in xEdit. Basically the order that you see INFOs 
listed in the Geck is the order that they are serialized in the plugin - 
always. If you modify the order in the Geck (move INFOs up or down), then the 
plugin reflects that.
Now I recall that way back in 3.0.15 didn't do what I want either, even with 
sorting enabled.
The problem I'm describing only occurs when you have a pair of plugins, where 
the INFO order of the master has been overridden by the esp. Dragging the PNAM 
fields from the esp to the master, breaks the INFO serialization rule in the 
master, resulting in 'Previous info not found' errors when subsequently loading 
the master in the Geck. The merging tool we have for fallout does not address 
this issue.
I will make example plugins and a write up with screenshots to explain the 
problem better so hopefully a fixup script can be made.

Original comment by rickerhk...@gmail.com on 4 Sep 2013 at 1:43

[GoogleCodeExporter]

No I'm talking exactly about sorting by PNAM when saving plugin, xEdit did that 
but it caused errors sometimes so I first disabled it, and now made optional.
Example plugins won't help since as I've said the sorting algorithm used by 
xEdit now is more complex than merely checking PNAM.

Original comment by zila...@gmail.com on 4 Sep 2013 at 5:29

[GoogleCodeExporter]

Original comment by HuguesLe...@gmail.com on 22 May 2014 at 11:29

• Added labels: Defect-TES4Edit
• Removed labels: Defect-TES5Edit