search

raziel23x / skyrim-plugin-decoding-project

Automatically exported from code.google.com/p/skyrim-plugin-decoding-project
1 stars 3 forks source link

Error on reading non existent optional struct of variable size (ie VMAD fragments) #142

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1.Open Dawnguard.esm
2.Copy as override info [020034C7] into new file
3.Save and reload: You "gain" an empty fragment.

What is the expected output?
Absent fragment, same as original.

What do you see instead?
An existing but empty fragment.

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

Please provide any additional information below.
With the exp version, you get complaints about 'struct with negative size'
By checking esModified I think I can determine whether we have a missing or an 
empty struct.

Original issue reported on code.google.com by HuguesLe...@gmail.com on 14 Aug 2013 at 12:15

GoogleCodeExporter commented 9 years ago 
Now I need to track down where and when I added the GetDefaultSize to confirm 
the new version of the check did not reintroduce this bug. (again :) )
I'll upload later from home:

Current fix is NOT working. Copying sets the esModified flag.

Original comment by HuguesLe...@gmail.com on 14 Aug 2013 at 12:19

GoogleCodeExporter commented 9 years ago 
Looks like the original issue was issue 134

Original comment by HuguesLe...@gmail.com on 14 Aug 2013 at 12:29

GoogleCodeExporter commented 9 years ago 
If it is hard to fix, then it is not a big issue at all. I tested it in CK and 
game, and yet to see any side effect of this zero fragment.

Original comment by zila...@gmail.com on 14 Aug 2013 at 1:32

GoogleCodeExporter commented 9 years ago 
Yes it is getting on my nerve ! :) I did solve the "negative" struct which was 
my original problem, so I could leave it at that. But this also made me 
realized than we are "confusing" missing fields and empty fields. For example 
the missing fragment should show up as greyed not as <empty> ! Do we need to 
create a IwbAbsentDef ?

Original comment by HuguesLe...@gmail.com on 14 Aug 2013 at 2:17

GoogleCodeExporter commented 9 years ago 
Well, actually it is a good idea. I'm just afraid it can cause more issues than 
benefits. Some of the recent updates where things started to break suddenly out 
of nowhere in random places were disturbing.
What will be the difference between current IwbEmptyDef and IwbAbsentDef? 
GetDefaultSize already returns 0 for empty fields.

Original comment by zila...@gmail.com on 14 Aug 2013 at 4:00

GoogleCodeExporter commented 9 years ago 
A) I agree, let's stabilize, (and I still have to merge the refactoring and the 
saves, both of which wait for "stability" :) )
B) They would show up grey, not <empty> by reusing the previous ToString. ie 
use wbEmpty in wbDefinitions... and wbAbsent in wbImplementation.

Original comment by HuguesLe...@gmail.com on 14 Aug 2013 at 4:14

GoogleCodeExporter commented 9 years ago 
Can't see how showing '' instead of '<Empty>' will help with this issue of zero 
fragment after copying :)
Better just to Result := '' in TwbEmptyDef.ToString while leaving '<Empty>' 
only in SortKey.

Original comment by zila...@gmail.com on 14 Aug 2013 at 4:33

GoogleCodeExporter commented 9 years ago 
Fixed in current 3.0.33 apparently :) Must be part of the changes made by 
Elminster.

Original comment by HuguesLe...@gmail.com on 12 Sep 2014 at 12:16