Inaccuracies and inconsistencies in version 1.3.0

[FastAndFishious]

It seems that version 1.3.0 does not calculate drag and lift correctly, and sometimes completely ignores the root part.

With only the root, everything appears to be normal, the drag matches the in-game value.

Adding a part at the front, the drag shoot way up, when it should barely increase.

Adding a part at the back has the opposite effect; it's as if the 100's front face was fully shielded, but the drag from the 200 was ignored.

Changing the root part seams to inverse the situation: the back of the 200 is shielded, and the 100's drag is ignored.

Here is another strange result: by attaching the 100 on the reaction wheel, then making it the root (it is order dependent), it gets totally ignored, even its mass; the pitching torque is practically zero, and it's unaffected by the fuel in the 100.

I also did some tests with fairings and cargo bays, and with long stacks of fuel tanks, which proved to be even stranger. In contrast, version 1.2.4 passed all of my tests flawlessly.

[DBooots]

This appears to be linked to https://github.com/DBooots/KerbalWindTunnel/issues/12 .

Troubleshooting is in progress to figure out what's going on. If this isn't stock behaviour based on attachment nodes occluding weirdly, I'm guessing it has something to do with https://github.com/DBooots/KerbalWindTunnel/commit/f6abbe57c5493039a760eeb2375aec45255c1fdf .

[DBooots]

Annotating for my own reference: tests pass 1.2.5.-1. There's only four commits between those versions. 5c511fa2f1d3fa00c91c68358942cb1b71ae9b49 checked out correctly. Can probably blame https://github.com/DBooots/KerbalWindTunnel/commit/0b4e6a392424ccc7742618220710e8213f6d4f5d - Confirmed.

[DBooots]

There's still an edge case where re-rooting, removing, and then replacing a part causes it to cycle between 1 or 2 erroneous results and the correct result. This appears to be caused by the order in which parts are cached and their relative placement in the ShipConstruct.parts list. Under the new method, parts are cached in parent-child order instead of the parts list order. I corrected most of the issues by then sorting the cached list by the original indices. There's still something not quite right... but I'm out of debugging time for the weekend.

[DBooots]

Edge cases appear to be resolved, actually. @FastAndFishious I'm going to close this issue with the release of 1.3.1. Please let me know if anything still seems off.

[FastAndFishious]

Are you sure you correctly released version 1.3.1? Because it's stupidly broken. The drag calculation is basically:

1. Calculate the drag of the last part of the first branch in the tree, ignoring if it’s shielded by a fairing or a cargo bay.
2. Apply this drag to every unshielded part.
3. There is no 3, we are done. This is different from version 1.3.0, but obviously still very wrong. On the flipside, the root part issues seam to be fixed, so that’s nice.

[DBooots]

Can you show an example? 1.3.1 passed my standard test craft and I've tried to reproduce the behavior you describe, but simple craft seem to have the drag representative of the correct parts regardless of order.

[FastAndFishious]

Upon closer inspection, it’s actually the drag cube that is pasted to other parts, not the drag.

First, I’ve simplified my Physics.cfg to facilitate the testing (line 140):

DRAG_TIP
{
    key = 0 1 0 0
}
DRAG_SURFACE
{
    key = 0 0 0 0
}
DRAG_TAIL
{
    key = 0 0 0 0
}

Basically, only front drag. Next, we start with a 100. So good so far, 235 kN.

After attaching a 200 on the front, the drag exactly doubles to 470 kN, when it should stay the same, because only front drag is applied.

Attaching a small nose cone at the back, the drag stays the same.

However, turn it 180 and now it’s tripled to 706 kN. This makes sense; the 200’s back face is fully covered, so a back facing part adds no drag.

Now, lets consider the nose cone alone. About 1/3 kN for the front face alone.

If we go back to our previous setup, but add the cone BEFORE the 200, it becomes the last part of the first branch, so it’s drag cube applies to everyone. And because its back face is covered, it adds no drag, but the two fuel tanks are forwards, so we have 2/3 kN.

And when the three parts face forward, we get 1 kN! Science!

Results are basically the same with an unmodified Physics.cfg, just more muddied.

[DBooots]

Thanks for researching this bug. I've tracked down the root cause now, and I would never have found it without your feedback. Your screenshots and steps to reproduce are stellar and are a model to all bug reports.