TES4Edit 3.0.22a throws an assertion failure when cleaning PGRD records from files.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Load the attached file.
2. Run the standard cleaning process. Note it removes numerous path grids.
3. Attempt to save the file.

What is the expected output?
The file should save and TES4Edit should exit.

What do you see instead?
[00:00] Saving: Roads of Cyrodiil.esp.save.2012_10_05_03_11_09
[00:01] Error saving Roads of Cyrodiil.esp.save.2012_10_05_03_11_09: Assertion 
failure (D:\Projects\TES5Edit\wbImplementation.pas, line 13369)
[00:01] Errors have occured. At least one file was not saved.

What version of the product are you using? On what operating system?
October 5 build of 3.0.22a.

Please provide any additional information below.

Version 3.0.15 does not identify any dirty edits in this file. Testing seems to 
indicate that whenever a path grid (PGRD) record gets removed as dirty, the 
assertion failure pops up and the file will not save.

Original issue reported on code.google.com by arthmoor on 5 Oct 2012 at 10:15

Attachments:

• [Roads of Cyrodiil.esp](https://storage.googleapis.com/google-code-attachments/skyrim-plugin-decoding-project/issue-63/comment-0/Roads of Cyrodiil.esp)

[GoogleCodeExporter]

Original TES4Edit doesn't remove duplicate PGRI connections in PGRD, but 
TES5Edit does.
I don't know who is right here - are you sure that those ITM pathgrids are 
indeed dirty edits and you didn't alter them yourself while making Roads of 
Cyrodiil?

Original comment by zila...@gmail.com on 5 Oct 2012 at 1:09

[GoogleCodeExporter]

Yes, I'm sure. I usually go through by hand to dump path grids I know I didn't 
touch but figured I'd see if it would turn up anything new that I might have 
missed.

It's not an issue that it found things to remove. The only issue is it won't 
let me save the results due to the assertion.

Obviously that's not a problem with Fallout and Skyrim since they don't use 
PGRD anymore.

Original comment by arthmoor on 5 Oct 2012 at 9:46

[GoogleCodeExporter]

Well, there is something more than simple PGRD cleaning. TES4Edit 3.0.15 
doesn't perform ANY internal records modifications (that options is off) 
including that PGRI duplicates cleaning. Thats why it never detected them as 
ITM.
So what should we do about that?
1) Enable modifications and try to fix the bugs which will improve ITM 
detection but screw the existing BOSS database on ITM counts. Mind you there is 
possibly a good reason why Elminster left that options off for Oblivion.
2) Turn modifications off by default for Oblivion to emulate "3.0.15" mode 
since it prooved to be reliable and stable by hundreds of people in 2 years.

Original comment by zila...@gmail.com on 6 Oct 2012 at 6:39

[GoogleCodeExporter]

Before answering any of that, what does the assertion failure mean? That's the 
only thing I was concerned with.

I like that it's finding more dirt, that means it's possible to release even 
cleaner mods. So if that assertion can be fixed it isn't an issue anymore.

The ITM counts in BOSS can be dealt with if necessary.

Original comment by arthmoor on 6 Oct 2012 at 6:51

[GoogleCodeExporter]

Assertion is a manual created exception when the provided condition is false. 
Tesedit has a lot of assertions everywhere so even if some single variable has 
an unexpected value, it stops to prevent any data corruption.
That assertion when saving occures due to a inconsistency in saved data (saved 
record size does not match expected size). It can possibly be caused by any 
internal modification, not only PGRD (and perhaps not even by PGRD). I'll try 
to see whats going on there later, until then I disabled internal modifications 
to be safe.

Original comment by zila...@gmail.com on 7 Oct 2012 at 7:39

[GoogleCodeExporter]

Original comment by zila...@gmail.com on 13 Oct 2012 at 6:00

• Changed state: Accepted

[GoogleCodeExporter]

Zilav: Did'nt you choose option 2 in post #3 ?

Original comment by HuguesLe...@gmail.com on 5 Jul 2013 at 2:32

[GoogleCodeExporter]

Yes. TES4Edit has been working without issues with disabled internal fixup for 
several years. I don't see any reason to turn it on now, especially when there 
is no way for us to check all the possible bugs.
However PGRD fix can be applied with disabled internal editing flag if it 
works. TES4Edit was asserting on save last time I checked it.

Original comment by zila...@gmail.com on 5 Jul 2013 at 4:03

[GoogleCodeExporter]

So the issue is still unfixed. I was not sure.
It looks like when elements are removed from a container during 
creation/initialisation, the change is not reported correctly upward. So on 
save the dcDataEndPtr and the dcEndPtr are not correct!
I hacked something into TwbContainer.RemoveElement but that fires up the 
warning about Unused Data!

Original comment by HuguesLe...@gmail.com on 5 Jul 2013 at 7:35

[GoogleCodeExporter]

Don't bother with it, I suppose Elminster switched it off because of too much 
problems with too little gain.

Original comment by zila...@gmail.com on 5 Jul 2013 at 8:23

[GoogleCodeExporter]

Do you know of a similar case in Skyrim or Fallout ?
Right now I am worried that it would fail in the same way. That's why I am 
diging.

Original comment by HuguesLe...@gmail.com on 5 Jul 2013 at 8:26

[GoogleCodeExporter]

No, it's specific to Oblivion and PGRD only. I highly doubt that Bethesda will 
bring pathgrids back in FO4.

Original comment by zila...@gmail.com on 5 Jul 2013 at 8:32

[GoogleCodeExporter]

Anyway, what I have done will be uploaded as part of the next Exp branch 
update. :)

Original comment by HuguesLe...@gmail.com on 5 Jul 2013 at 8:56