Assertion when copying MGEF in TES4Edit

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Copy any MGEF from Oblivion.esm

What is the expected output?
ITM record

What do you see instead?
Assertion in MGEF decider when accessing sortkey.

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

Please provide any additional information below.
Original report 
http://forums.nexusmods.com/index.php?/topic/37310-name-tes4view-advanced-esp-vi
ewer-and-conflict-detector/?p=8445349
Now it occures in 3.0.30 too.

Original issue reported on code.google.com by zila...@gmail.com on 13 Jul 2013 at 9:11

[GoogleCodeExporter]

I have a feeling of deja vu , no ?

Original comment by HuguesLe...@gmail.com on 13 Jul 2013 at 10:02

[GoogleCodeExporter]

OK ! Can you copy anything in Oblivion using r1369 ? I seem to have an 
assertion during the "new file" creation !

Original comment by HuguesLe...@gmail.com on 13 Jul 2013 at 11:02

[GoogleCodeExporter]

So ok, I have an assertion on creating a new file (SizeAvailable < SizeNeeded) 
, and another assertion on copying MGEF.

Original comment by HuguesLe...@gmail.com on 13 Jul 2013 at 11:09

[GoogleCodeExporter]

I can copy any other record type except MGEF just fine. Perhaps you are using 
some other experimental version? :)

Original comment by zila...@gmail.com on 13 Jul 2013 at 11:17

[GoogleCodeExporter]

MGEF asserts because it expects the flags SortKey to be 32 bytes long, where it 
was an empty string. I have to "swap" a GetSize with a GetDefaultSize 
"somewhere"

Original comment by HuguesLe...@gmail.com on 13 Jul 2013 at 11:26

[GoogleCodeExporter]

Good point! I opened the Sharlikran version last night and did not check!

Original comment by HuguesLe...@gmail.com on 13 Jul 2013 at 12:12

[GoogleCodeExporter]

I knew that! Deja vu :)

Original comment by zila...@gmail.com on 13 Jul 2013 at 12:12

[GoogleCodeExporter]

"Solved" the MGEF first Assertion by adding the RequiresKey property to 
IwbIntegerFormaterDef, sets to true for flags.
Now I assert on the EDID not being a valid MGEF code. :(

How is it possible that, on entering TwbSubRecord.Create, I have some members 
already filled ? I am refering to cntState which is 
[csInit,csInitOnce,csInitDone] !!! Should't the damm thing be filled with zeros 
?

Original comment by HuguesLe...@gmail.com on 13 Jul 2013 at 3:59

[GoogleCodeExporter]

Yes, apparently something else is going on here not tied to SortKey at all. I 
tried to replace decider with native value

  i := Container.ElementNativeValues['Flags'];
  if i and $00010000 > 0 then
    Result := 1 // Use weapon
  else if i and $00020000 > 0 then
    Result := 2 // Use armor
  else if i and $00040000 > 0 then
    Result := 3 // Use creature
  else if i and $01000000 > 0 then
    Result := 4; // Use actor value

and it still asserts, guess where? Again in TwbSubRecord.Create()

Original comment by zila...@gmail.com on 13 Jul 2013 at 4:31

[GoogleCodeExporter]

MGEF do not like being SetToDefault to an empty string! This does not pass 
validation.

Original comment by HuguesLe...@gmail.com on 13 Jul 2013 at 4:36

[GoogleCodeExporter]

Well, mgefs in Oblivion are referenced not by FormID, but by 4 chars code. 
Still it was not a problem before in previous version. I dunno why 
TwbSubRecord.Create is not zeroed :(

Original comment by zila...@gmail.com on 13 Jul 2013 at 4:41

[GoogleCodeExporter]

Well mine is now :) 
Maybe there is a "miss" in the inheritance chain ? Something not declared as 
override or virtual ?

Original comment by HuguesLe...@gmail.com on 13 Jul 2013 at 4:48

[GoogleCodeExporter]

Maybe just go back to previous snv revisions and find out what caused this? I 
clearly remember MGEF working before.

Original comment by zila...@gmail.com on 13 Jul 2013 at 4:54

[GoogleCodeExporter]

So, I override SetToDefault for MGEF so they expect ' <Warning: Expected 4 
bytes but found 0>' as the default value and the TransformString now transforms 
'' into '' as an edit value without assserting.

For the TwbSubRecord.Create I forcibly exclude all csStates values in a loop.
Even setting cntStates to [] was not working. :)

This way, copying MGEF is working again.

Original comment by HuguesLe...@gmail.com on 13 Jul 2013 at 5:09

[GoogleCodeExporter]

I have a bad feeling that it'll break something else :)
What about IwbIntegerFormaterDef.RequiresKey, redundant now? Why SortKey 
stopped working?

Original comment by zila...@gmail.com on 13 Jul 2013 at 5:15

[GoogleCodeExporter]

So  do I, so I am copying Oblivion.esm into a new plugin to see what else is 
wrong.
Currently, I am finding a lot of brackets in FormID's value, so I am asserting 
"validly" a lot, before finally running out of memory.

The RequiresKey is still valid, it was a valid issue unless we change all 
deciders to check the referenced Element exists and it has a value before 
comparison.

And to think all of that comes from trying to "intelligently" display elements 
without value! That's when it started becoming "touchy".

Original comment by HuguesLe...@gmail.com on 13 Jul 2013 at 5:27

[GoogleCodeExporter]

Ok finishing copying Tamriel now. Every other type of things copied properly 
until then except dialog that's still to do.

Original comment by HuguesLe...@gmail.com on 13 Jul 2013 at 7:33

[GoogleCodeExporter]

oops.

Original comment by HuguesLe...@gmail.com on 13 Jul 2013 at 7:34

• Changed state: Started

[GoogleCodeExporter]

Now dialogs? Damn :(

Original comment by zila...@gmail.com on 13 Jul 2013 at 7:43

[GoogleCodeExporter]

he! It's not done yet, don't be negative :)

Original comment by HuguesLe...@gmail.com on 13 Jul 2013 at 7:54

[GoogleCodeExporter]

Tamriel worldspace is OK ! :)

Original comment by HuguesLe...@gmail.com on 13 Jul 2013 at 7:55

[GoogleCodeExporter]

Dialogs copy OK except I end up with a Out of Memory after a while.
Pretty systematic when copying GREETINGS.
Updating the trunk now as it is at least better than before.

Original comment by HuguesLe...@gmail.com on 13 Jul 2013 at 11:16

[GoogleCodeExporter]

Looks like I also reach 3.7 G of RAM usage and crash with 3.0.30 while copying 
GREETINGS.

Original comment by HuguesLe...@gmail.com on 14 Jul 2013 at 9:59

[GoogleCodeExporter]

Considering 3.0.23 is doing exactly the same, I don't think the Out of Memory 
is related to any recent changes. :)

Original comment by HuguesLe...@gmail.com on 14 Jul 2013 at 11:06

[GoogleCodeExporter]

Tested GREETINGS with 3.0.15, out of memory too. An old bug I guess with 
infinite loop perhaps.
At least we are not guilty :)

Original comment by zila...@gmail.com on 14 Jul 2013 at 11:46

[GoogleCodeExporter]

Maybe because of TwbGroupRecord.Sort(). I disabled it for FO3/FNV/TES5 since it 
was not working sometimes.
It sorts INFO records so they come in order depending on parent INFO via PNAM 
field, maybe Oblivion's Construction Set has an error where it saves them in 
wrong order, I don't know. I've never seen any problems with dialog topics 
myself.
I have a letter from Elminster where he briefly describes how it works if you 
are interested though.

Original comment by zila...@gmail.com on 14 Jul 2013 at 11:54

[GoogleCodeExporter]

Thanks, it can be usefull.

Original comment by HuguesLe...@gmail.com on 14 Jul 2013 at 12:55

[GoogleCodeExporter]

as of r1371

Original comment by HuguesLe...@gmail.com on 3 Jan 2014 at 12:32

• Changed state: Fixed