TES4Edit hangs when focusing a record

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Load attached plugin into TES4Edit
2. There is a cell with 4 references
3. Select 01012A21

What is the expected output?
Anything: record, error message, exception.

What do you see instead?
TES4Edit hangs

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

Please provide any additional information below.
This bug first appeared in TES4LODGen 2-3 years ago, it was hanging when 
generating LOD from a combination of popular worldspace mods. I always thought 
this is because of out of memory so didn't bother much.
However a recent thread 
http://forums.bethsoft.com/topic/1499541-issues-with-tes4lodgen/ pinpointed to 
a particular mod, so I tried to pursue it and was able to isolate a problematic 
record out of 3 huge mods with 2m+ records.
The problem goes back to 3.0.15, however there are reports of version 2.2.0 
working, so some old legacy bug. I suppose that binary data is wrong in this 
plugin, because such huge landspace mods are impossible to create without 3rd 
party tools, and xEdit isn't suppose to support them. However I'd rather see an 
error message or at least an exception instead of hanging.
p.s. I manually removed master files so binary record indexes in esp are off, 
ignore it.

Original issue reported on code.google.com by zila...@gmail.com on 25 Apr 2014 at 12:46

Attachments:

• TWMP_Valenwood_Elsweyr.esp

[GoogleCodeExporter]

I'll let it run, but it seem to hang xDump as well. :) If confirmed that should 
make it easier to track.

Original comment by HuguesLe...@gmail.com on 25 Apr 2014 at 1:15

[GoogleCodeExporter]

It was not so easy :(

Original comment by HuguesLe...@gmail.com on 25 Apr 2014 at 1:17

[GoogleCodeExporter]

The error log from version 2.2.0 posted somewhere was about converting null
variants if it helps.

2014-04-25 17:17 GMT+04:00 <skyrim-plugin-decoding-project@googlecode.com>:

Original comment by zila...@gmail.com on 25 Apr 2014 at 2:04

[GoogleCodeExporter]

xDump did not complain but I found it very slow. I don't know where I could 
start tracing the execution :(

Could you try script deleting the faulty records ? Maybe you'll be lucky and 
have an exception :)

Original comment by HuguesLe...@gmail.com on 26 Apr 2014 at 2:27

[GoogleCodeExporter]

Deleted without any problem :(
http://pastebin.com/vVZ5wJU0

Original comment by zila...@gmail.com on 26 Apr 2014 at 3:54

[GoogleCodeExporter]

Narrowed it down to getting a value of Z rotation, though I can get IwbElement 
itself without any problems. Some FP error or what...
http://pastebin.com/LKJntxEQ

Original comment by zila...@gmail.com on 26 Apr 2014 at 4:09

[GoogleCodeExporter]

Hexediting the Z value to 0 does what ?

Original comment by HuguesLe...@gmail.com on 26 Apr 2014 at 4:16

[GoogleCodeExporter]

It works after zeroing.

Original comment by zila...@gmail.com on 26 Apr 2014 at 4:28

[GoogleCodeExporter]

So its the value, I'll debug the ToString for floats.

Original comment by HuguesLe...@gmail.com on 26 Apr 2014 at 4:38

[GoogleCodeExporter]

It hangs on getting a native value too, so not ToString.

Original comment by zila...@gmail.com on 26 Apr 2014 at 4:46

[GoogleCodeExporter]

Looks like the problem is normalising the value 232281915392 in 2PI increment.
It is going to take 37 millions loops twice to display the value assuming that 
no interruption will require redrawing the cell before the end of the loop!

I think we need to assume the maximum value a radiant angle can "normally" have 
and raise an exception if bigger.

Original comment by HuguesLe...@gmail.com on 26 Apr 2014 at 10:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

changing RadiantNormalizer to this:

function RadiansNormalize(const aElement: IwbElement; aFloat: Extended): 
Extended;
begin
//  Result := RoundToEx(aFloat, -6);
  Result := aFloat;

  Assert(Abs(Result)<1000*TwoPi);

  while Result < 0.0 do
    Result := Result + TwoPi;
  while Result > TwoPi do
    Result := Result - TwoPi;
  if SingleSameValue(Result, 0.0) or (Result < 0.0) then
    Result := 0.0;
  if SingleSameValue(Result, TwoPi) or (Result > TwoPi) then
    Result := 0.0;

//  Result := RoundToEx(Result, -6);
end;

Hides the issue and display the value as Default.

The question becomes "why the 2 RounToHex were commented ?" :)

Original comment by HuguesLe...@gmail.com on 26 Apr 2014 at 10:46

[GoogleCodeExporter]

Why it just can't brign it down to -2PI..2PI range by subtraction Result - 
2PI*Trunc(Result/2PI)? I'm not on a good terms with FP arithmetics, but assume 
that it is because of extra errors that come from multiplication and division.
And probably also this
http://stackoverflow.com/questions/6699066/in-which-order-should-floats-be-added
-to-get-the-most-precise-result

But in this case we can first just bring it down into a more acceptable range, 
lets say -100*2PI..100*2PI and then run the loop for a more precise 
approximarion:

function RadiansNormalize(const aElement: IwbElement; aFloat: Extended): 
Extended;
begin
  Result := aFloat;

  if Abs(Result/TwoPi) > 100.0 then
    Result := Result - Sign(Result)*TwoPi*Trunc(Abs(Result/TwoPi) - 100.0);

  while Result < 0.0 do
    Result := Result + TwoPi;
  while Result > TwoPi do
    Result := Result - TwoPi;
  if SingleSameValue(Result, 0.0) or (Result < 0.0) then
    Result := 0.0;
  if SingleSameValue(Result, TwoPi) or (Result > TwoPi) then
    Result := 0.0;
end;

As for commented RoundEx, maybe to reduce the chance of false positive ITMs due 
to rounding? No clue.
I don't think we should raise errors here and even mention anything in message 
log, it is not a structural error in plugin and the game reads it just fine. 
This is only a problem of how xEdit handles normalization that must be fixed.

Original comment by zila...@gmail.com on 27 Apr 2014 at 6:53

[GoogleCodeExporter]

Done in r1572

Original comment by HuguesLe...@gmail.com on 27 Apr 2014 at 8:15

• Changed state: Fixed