Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Values in the stability derivatives panel can change wildly when a craft is reloaded in the editor #177

Open
kbios opened this issue Mar 27, 2017 · 9 comments

Comments

@kbios
Copy link

kbios commented Mar 27, 2017

Hello, the following is with ksp 1.2.2 and the latest dev version of FAR, under linux 64 bit.
I noticed that the values displayed in the stability derivatives panel can change wildly when reloading a craft in the editor, without making any changes to it:
screenshot5
screenshot6
These are the two "configurations" of the values that can happen with this craft (attached
SSTO3.craft.txt).
The only thing I did between these screenshots was to reload the craft a few times in the editor (the issue seems to happen randomly). Here is the full log: the relevant section is towards the end, as I did a bit of playing at the beginning.
KSP.log.txt

@kbios kbios changed the title Values in the stability derivatives panel change wildly when a craft is reload in the editor Values in the stability derivatives panel can change wildly when a craft is reloaded in the editor Mar 27, 2017
@ferram4
Copy link
Owner

ferram4 commented Apr 5, 2017

I cannot reproduce this issue. Without fail, the outcome is always the 2nd screenshot. Is the 1st screenshot only the result of building the craft from scratch, or does that also appear when loading the craft in the editor? If it is the latter, then there are reproduction steps missing to cause that outcome.

@Virindi-AC
Copy link
Contributor

Virindi-AC commented Apr 6, 2017

I have also noticed fluctuations while building a craft. For instance, placing a new part then hitting undo will not always return values to what they were before the part was added. (Note that the fact that undo will improperly revert tweaked values such as procedural wing sizes can obfuscate this, but this is not the cause.) I tend to see this in the wave drag area, because I am watching that all the time, but it may be the same thing happening here.

The variations I have seen tend to be small though and have little effect on craft performance.

@kbios
Copy link
Author

kbios commented Apr 6, 2017

So I did a few more tries and I managed to reproduce the issue on a clean install with only FAR installed: you can see my reproduction steps in the attached video. I noticed that it tends to happen more if I just started up KSP (could be a coincidence though). A few times I reached an "area of stability" where the values remained unchanged after many reloads of the craft, at the same values you get (24 AoA).
repro.zip

@ferram4
Copy link
Owner

ferram4 commented Apr 7, 2017

I have followed your steps exactly and I cannot reproduce the issue. No matter what I try, I always get the second 24 AoA result.

I'll leave this up with a note that it needs more specific repro steps, but until I can get that, I can't make any progress on this.

@Virindi-AC
Copy link
Contributor

Virindi-AC commented Apr 19, 2017

Here is a video showing SLIGHTLY different values calculated for an identical craft, with the only difference being adding and deleting a part:

https://youtu.be/jbu7L9ba6n0

This may or may not be the same problem, as it involves building a craft manually. But it happens very consistently when doing the same build.

@Rodhern
Copy link

Rodhern commented Jun 23, 2017

I think I have noticed this when I first start the game (the KSP_x64.exe). After a while in the editor with craft reload it settles. I am not on a clean FAR install, but are there any particular values that it would make sense for me to debug/log, that may help figure out what the pattern is?

@ferram4
Copy link
Owner

ferram4 commented Jun 23, 2017

Absolutely anything that produces reliable, reproducible results, with as few mod parts as possible (ideally, none).

@Rodhern
Copy link

Rodhern commented Jun 23, 2017

In order to calculate the Cl output we call 'GetClCdCmSteady'. I have broken the values in my modded version down into a virutal stack trace:

  • In 'GetClCdCmSteady' we use a vector 'force'.
  • Vector 'force' depends on 'vel'.
  • Vector 'vel' depends on 'relPos'.
  • Vector 'relPos' depends on 'AerodynamicCenter'.
  • 'AerodynamicCenter' is adjusted by 'ACShiftVec'.
  • The main ingredient in 'ACShiftVec' is 'ACshift'.
  • 'ACshift' is affected by 'effectiveUpstreamMAC'.
  • 'effectiveUpstreamMAC' is updated in 'UpdateUpstreamValuesFromWingModules' depending on 'associatedInfluences'.

It seems to me that somehow 'effectiveUpstreamMAC' has not reached its ultimate value, and every load indirectly feeds results to the next set of calculations. I hope this observation can help you get reproduction steps.

Edit:
I cannot upload craft file or images right now. I put a debug message in the 'UpdateThisWingInteractions' method. I created a craft of a girder segment and four basic fins. When the craft is first loaded (load 1) I don't get the final results. When the craft is reloaded (load 2) I get a few influence numbers, but I do not yet get the final results. When I reload once more (load 3) I seem to have no influence numbers (according to the 'UpdateThisWingInteractions' debug messages) but I get the final results. Loading again doesn't seem to change anything; I still get the final results.

@Rodhern
Copy link

Rodhern commented Jul 19, 2017

I have come up with a trick/fix to help find the bug. When a vessel is (re)loaded in the editor, and possibly when parts are added and removed [edit: maybe in ResetEditorEvent?], we should call FARAeroUtil.ResetEditorParts(); Otherwise the editor all parts cache may survive with old copies of parts. The 'influence collisions' are detected but the hit parts can't be found in the cache.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants