Open GoogleCodeExporter opened 9 years ago
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
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
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:
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
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
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
Good. I made INFO sorting optional in 3.0.31
Original comment by zila...@gmail.com
on 11 Aug 2013 at 4:03
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
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
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
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
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
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
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
Original comment by HuguesLe...@gmail.com
on 22 May 2014 at 11:29
Original issue reported on code.google.com by
ginnunga...@free.fr
on 9 Aug 2013 at 2:39Attachments: