Closed GoogleCodeExporter closed 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
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
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
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
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
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
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
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
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
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
Hidden as of r1441
Original comment by HuguesLe...@gmail.com
on 29 Oct 2013 at 3:39
Original issue reported on code.google.com by
HuguesLe...@gmail.com
on 22 Aug 2013 at 11:45