search

raziel23x / skyrim-plugin-decoding-project

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

Parsing error for DIAL MainRecord leads to removing INFC SubRecord #143

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1.Copy as override 000E9083 from FalloutNV.esm
2.Save as new plugin
3.Check the new plugin content with an hexeditor.

What is the expected output?
The full DIAL record

What do you see instead?
You are missing the INFC record(s)

What version of the product are you using? On what operating system?
3.0.31 on Windows 7 x64

Please provide any additional information below.
FNVEdit complains a lot about that!
Not tested with Fallout 3 yet.

Original issue reported on code.google.com by HuguesLe...@gmail.com on 22 Aug 2013 at 11:45

GoogleCodeExporter commented 9 years ago 
Error: record DIAL contains unexpected (or out of order) subrecord INFC 43464E49
FNVEdit has incorrect DIAL definition. However INFC is not used in FNV afaik.

Original comment by zila...@gmail.com on 22 Aug 2013 at 12:59

GoogleCodeExporter commented 9 years ago 
Isn't that the only game with this record ? It would be strange for them to add 
it and not use it, though it doesn't seem to do much effectively.

Original comment by HuguesLe...@gmail.com on 22 Aug 2013 at 1:21

GoogleCodeExporter commented 9 years ago 
http://code.google.com/p/skyrim-plugin-decoding-project/issues/detail?id=83

Original comment by zila...@gmail.com on 22 Aug 2013 at 1:31

GoogleCodeExporter commented 9 years ago 
Ok. That was "before my time". Strange I never tilted on them earlier if they 
were complaining since the beginning.

I would say that after or before the two wbRArrayS, there should be an optional 
"simple" INFC ?

Also having the "bad" INFC effectively pointing to a Navmesh for its INFO is 
"funny". It would seem some part of the Geck forgot to clean up behind itself.

Original comment by HuguesLe...@gmail.com on 22 Aug 2013 at 1:52

GoogleCodeExporter commented 9 years ago 
You can test it in GECK.
Add INFC definition before FULL, copy that DIAL, and then open and save in GECK 
to see if it'll be removed or repositioned after FULL.

Original comment by zila...@gmail.com on 22 Aug 2013 at 2:02

GoogleCodeExporter commented 9 years ago 
It looks also to be repeatable... so that would be a wbRArrayS.
The parsing error is gone. I'll look in GECK tonight.

Original comment by HuguesLe...@gmail.com on 22 Aug 2013 at 2:23

GoogleCodeExporter commented 9 years ago 
So I can remove the error by adding this :
    wbRArrayS('Info Connections', wbFormIDCk(INFC, 'Info connection', [INFO])),
    wbRArrayS('Info Indexes', wbInteger(INFX, 'Info connection Index', itS32)),
but this turns out to make the containing INFO pretty much uncopyable as the 
contained INFO is obviously leftover garbage. Maybe we could add an AfterLoad 
that removes the record(s) if they are not a valid INFO  ?

Original comment by HuguesLe...@gmail.com on 22 Aug 2013 at 10:07

GoogleCodeExporter commented 9 years ago 
Perhaps, AfterLoad for CELL removes invalid XCLRs for example if they point to 
invalid regions (however it is commented out for some reason I don't remember).

Original comment by zila...@gmail.com on 23 Aug 2013 at 4:21

GoogleCodeExporter commented 9 years ago 
In this case, I will have to check the DLC for such record, and what happens 
when you remove an INFO from a QUEST after giving it a INFC, if I ever find out 
how to do that.
Moving priority to normal :)

Original comment by HuguesLe...@gmail.com on 23 Aug 2013 at 7:41

GoogleCodeExporter commented 9 years ago 
That INFC parsing error has been there for years and noone ever complained :)

Original comment by zila...@gmail.com on 23 Aug 2013 at 7:56

GoogleCodeExporter commented 9 years ago 
Hidden as of r1441

Original comment by HuguesLe...@gmail.com on 29 Oct 2013 at 3:39