FNVEdit breaks the NAVI record when adding a new master

[GoogleCodeExporter]

What steps will reproduce the problem?
0. Requires one to have all DLCs as the file below has them as dependencies.
1. Download  MMUE 11a from http://www.nexusmods.com/newvegas/mods/45104
2. Create a simple empty esp, does not matter, named test.esp
3. Put test.esp at lower load order index than "Mission Mojave - Ultimate 
Edition.esp" using a tool of your choice.
4. Open FNVEdit, select just test.esp  and "Mission Mojave - Ultimate 
Edition.esp", load them. No significant errors should be shown.
5. Perform a check of "Mission Mojave - Ultimate Edition.esp", should result in 
1 warning FNVEdit does not know about.
6. Add test.esp as a master of "Mission Mojave - Ultimate Edition.esp". Perform 
another error check on "Mission Mojave - Ultimate Edition.esp", should give the 
same error as in step (5).
7. Save the modified "Mission Mojave - Ultimate Edition.esp".
8. Load "Mission Mojave - Ultimate Edition.esp" and see the error log.
9. Perform an error check on Mojave - Ultimate Edition.esp, see the same errors 
in NAVI.

What is the expected output?
The modified file should have the same content and errors as the original, 
except the new master and the renumbering of the FormIDs.

What do you see instead?
Errors in NAVI.

What version of the product are you using? On what operating system?
r1859

Please provide any additional information below.
One can compare the modified "Mission Mojave - Ultimate Edition.esp" with an 
original copy and see that those NULL entries were mod-added navmeshes (as 
opposed to master added navmeshes), so the FormID renumbering which occurred 
when a new master was added did not properly modified the NAVI with the new 
FormIDs, but somehow reset those FormIDs.

This issue may share the same root cause with Issue 123.

Original issue reported on code.google.com by clampa...@gmail.com on 15 Dec 2014 at 6:55

[GoogleCodeExporter]

The doors are not written properly. The door count is set to 0 but the door(s) 
ID are written back to disk.

Original comment by HuguesLe...@gmail.com on 15 Dec 2014 at 11:03

[GoogleCodeExporter]

Looks like simply accessing the NAVI record between adding the master and 
saving the plugin will hide the issue

Original comment by HuguesLe...@gmail.com on 21 Dec 2014 at 1:54

• Changed state: Started

[GoogleCodeExporter]

This one is getting frustrating :(

My current diagnostic is that modified SubRecordArrays that contain a struct 
containing an array containing only unchanged (SubRecord ?) members do not 
properly update their data. For some reason the array counter is reset to 0 but 
the SubRecord size (and data) remains correct.

Original comment by HuguesLe...@gmail.com on 7 Jan 2015 at 10:07

[GoogleCodeExporter]

A few words about the impact of the issue.

While normally the NAVI can be fixed in GECK, I am having issues with GECK when 
trying to load MMUE with many added masters. Simply put, GECK won't even start 
when I have MMUE in load order. It may be caused by the many BSA's of the mods 
in my load order, or simply by the many masters. I was not able to pinpoint the 
issue with GECK. However, while this is not the GECK bug-tracker, the end 
result is that I cannot fix the broken NAVI, so I am forced to somehow make 
FNVEdit work properly with that file.

I have tried your workaround and it worked for 2 masters (added in the 
load-order order as masters). However, when I added one more master (3 in 
total) and sorted the masters, it did caused the issue again.

Original comment by clampa...@gmail.com on 8 Jan 2015 at 4:59

[GoogleCodeExporter]

I think I got it: During CheckCount, the badly written arrays were not 
initialized yet (no csInit), so cntElements was empty. Adding a call to DoInit 
before using cntElements looks to solve it.

Original comment by HuguesLe...@gmail.com on 13 Jan 2015 at 1:05

[GoogleCodeExporter]

Should be fixed by r1873

Original comment by HuguesLe...@gmail.com on 13 Jan 2015 at 7:30