[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18

[Van Disaster]

On 20/12/2015 at 3:17 PM, ferram4 said:

No, this is not the "first load has everything wrong" bug, that was completely fixed.  All the other data that FAR outputs is consistent between first loads and second loads.  This case is simply something with the Stab Deriv solver being off.  Check the changelogs, I mention bugfixes there, stop saying that bugs that have been fixed haven't.

"Reduction in first-load inconsistency in editor" is all I can find without looking at the commit log ( I wouldn't really know which file to check anyway ). If you say it's completely fixed then I'm happy, thanks and apologies for misinformation distribution. At first in recent reinstall I was getting a lot of issues on first load which were solved with the usual reload dance, but after a while something started cropping up at other times. Given number of installed mods & irregularity of issue, not terribly motivated to debug; if it shows in near stock install sometime then I will expend more effort. I get the occasional error in placement of the CoM ball and I'm pretty damn sure that isn't FAR...

[m4ti140]

A couple of questions from an aerospace student:

1. Are you planning to add simulation of ground effect?

2. Does lift differentiate on the same wing segment if flow velocity changes along it (for example in a rotor blade)?

3. Is C_D corrected for viscous effects?

4. Are edge vortices simulated? Does curling wingtips do anything?

5. Is seperation simulated? Can you lose rudder in a spin?

6. What methods do you use for computation? Is it only an approximation or are you running actual cfd in the background?

Edited December 22, 2015 by m4ti140

[ferram4]

@soulsource: I can confirm it, but I can't think of a mechanism for it within FAR.  I suspect it might be some sort of strange stock behavior exacerbated by FAR, in which case I'll pass it along.

@m4ti140: 

1. When the wing overhaul is done.

2. No, will when the wing overhaul is done.

3. Yes.  Reynolds number, Mach number and Knudsen number effects on viscosity are modeled.

4. By approximation, and curled wingtips will likely help.  Will work much better with the wing overhaul.

5. If you mean the horizontal tail's stall blocking the vertical tail, no.  Likely a later feature of the wing overhaul.

6. A few approximations primarily based on stuff taken from the 1978 USAF Stability and Control DATCOM.  Future plans for the wing overhaul will be a discrete lifting line simulation with the influences adjusted empirically to account for Mach number and possibly stalling effects.  Current delay on that is 1) bugs keep coming up that need to be fixed first and 2) it'll be a lot of code to put together.

[Svm420]

On 11/30/2015 at 0:54 PM, ferram4 said:

That was noted as an issue a few pages back.  It'll be fixed in the next release.  I don't blame you for not reading back though given the state the forums are in though.

 

On 11/23/2015 at 0:58 AM, ferram4 said:

@Psycho_zs: I found something. You should have specified that ultra-high speed spinning was required to cause the issue; turns out it was an edge case with ModuleJettison. Fixed in dev build.

@Shnyrik: Ahk, I see. That's something funky with Procedural Fairings, not Procedural Parts. Did it happen in 0.15.5.2 as well, or just with 0.15.5.3?

@Venerabilius: It's already been fixed in the dev build.

This hasn't been fixed and all mention of it has been ignored the past 2 pages. Is this known @ferram4? Not trying to be a pest just want some acknowledgement that you know it is still an issue. Thanks!

Reproduction steps fresh install of latest dev FAR, latest MFI and MM.

Load any plane or make a new one

place a control surface make it a flap.

Run Aero analysis.

Select a flap setting in aero analysis and rerun.

Note lack of any change in analysis and lack of visible flap deflection.

 

[kcs123]

18 minutes ago, Svm420 said:

 

This hasn't been fixed and all mention of it has been ignored the past 2 pages. Is this known @ferram4? Not trying to be a pest just want some acknowledgement that you know it is still an issue. Thanks!

Reproduction steps fresh install of latest dev FAR, latest MFI and MM.

Load any plane or make a new one

place a control surface make it a flap.

Run Aero analysis.

Select a flap setting in aero analysis and rerun.

Note lack of any change in analysis and lack of visible flap deflection.

 

Tried with developer FAR version on github, it is still issue. Although, spoilers are detected by analysis, but they were deployed flipped - like a flaps should do.
So, if you want to see how flaps would performed, use those as deployed spoilers for analysis purpose. Revert it back to flaps once you have tuned it trough analysis.

Not exactly a solution, but some kind of workaround until proper solution is available.

[ferram4]

@soulsource: I found the exacerbation, but it still seems like there's something left over in stock.  No idea what the source of that is though.

@Svm420: no, that issue has been fixed in the dev build.  There is no further voxelization issues due to ModuleJettison in the dev build; that's what that entire conversation was about...

Anyway, the issue that you're talking about is also now fixed.

[Svm420]

Sorry for the misunderstanding in those posts' subject. Thank you for fixing it!

[123nick]

why is it that, with realchutes (non lite) installed, the MM patch that makes all parachutes not already patched for Realchutes into realchutes, appears to stop working. like, a parachute that would once automatically get patched into being a realchute, when the actuall, full realchute mod installed, wouldnt get patched anymore. any idea why?

[ferram4]

Because when you install RealChute you're replacing FAR's implementation of RealChuteLite.  If FAR attempted to continue with RCL even when RC is installed it would break all parachutes, so it disables itself if RC is installed.  If there's no configs for RC for those chutes, then that needs to be fixed, but not by FAR risking breaking everything else.

[cantab]

Did the wing leveller function change recently(ish) or am I just using it wrong? It now seems very bad at levelling the wings.

Reposting this. To expand, some versions ago (back in 0.90 and old FAR certainly, not sure about 1.0) I could click the roll button in the FAR GUI and it would hold my wings level just fine, on the default settings with no further work needed. Now the roll button seems to have virtually no effect, the plane will bank left or right and no control input is given. So what am I doing wrong?

[ferram4]

What is wrong is likely that you have changed, or something else has changed, the wing leveler gains.  You'll have to change them back to what they were before to function properly.

[cantab]

Thanks. I reinstalled FAR and I've had it working as expected now. Might have been a wrong setting. Might instead have been a controller deadzone issue, I noticed that they were too small just now.

[Autochton]

I just want to say, as an old flight-sim enthusiast, that the FAR wing overhaul sounds like it'll take KSP+FAR into the level of fidelity usually not found in entertainment software of any kind. I can think of two games which have gone this far in simulating aerodynamics of flight. Targetware (now sadly defunct) and X-Plane (which is only so much a game these days). I am thoroughly impressed, and look forward to fooling around with it when it's ready. 

Edited December 23, 2015 by Autochton

[AC656]

Hello so I am having trouble and I suspect it might be FAR. In simple terms the issue is that my ship is not slowing down enough on re-entry and after reaching about 5 km altitude my ship starts accelerating instead of decelerating even though it is already flying at supersonic speeds. Now fluid mechanics/aerodynamics is not something I am well versed in so I might be missing something but as fas as I know this is not how it should happen.

Below is an album showing the problem, it is a sequence of images showing how the velocity does not slow down enough and how it starts accelerating after about 5 km. I apologize for the large amount of images I did not want to leave any information out that might have been pertinent to someone trying to help.

 

I'm pretty sure we can discard the main suspect of too steep of a re-entry since as you can see in the first few images of the album the re-entry orbit is (ap,pe)=  74, 60 km which is not steep as far as I know. Also I don't think a steep entry angle would cause acceleration above supersonic velocities at low altitudes.

 

I do have quite a few mods installed, and even though I am not a modder I can't think of any 2 conflicting to cause this particular problem. I do have the latest version of KSP (1.0.5) and FAR (0.15.5.4) in case anybody is wondering, and I can provide the versions for any/all of the mods installed. The list of mods that I have installed are: 

Adjustable Landing Gear, Asteroid Day, B9 Procedural Wings only, Buffalo, Dangit, DMagic Orbital Science, FAR, Habitat Pack, HullCam, Infernal Robotics, KAS, KAX, Alarm clock, Kerbonov, KIS, kOS, KW Rocketry, LaserDist, MechJeb, MRS, OSE workshop, Planetary Base system, RasterProp, Realchute, Remotetech, ScanSat, TAC LS, Taurus HCV, TweakScale, Universal Storage.

 

I apologize if I am missing something dumb or if this is not the correct protocol of asking for help I do not mean to waste anybody's time. Also I completely understand that people might be busy with holidays stuff so don't worry and take your time. 

Merry Christmas everyone, and thanks in advance.

 

[ferram4]

Try the dev build from the github repo (not the release zip, the repo dll) and see if that fixes it.  If not, you need to provide full reproduction steps that will always cause the issue under all circumstances with only the mods necessary to cause the issue installed.

[g00bd0g]

Doed FAR give us IAS/TAS/EAS? Just curious...

https://en.wikipedia.org/wiki/Airspeed_indicator

https://en.wikipedia.org/wiki/True_airspeed

https://en.wikipedia.org/wiki/Equivalent_airspeed

[Crzyrndm]

FAR toolbar button => Flt Settings => Change "Flt Data" Dropdown to "Air Spd" => Change units and reference to taste

Edited December 24, 2015 by Crzyrndm

[Whovian41110]

The Scot Manley video says that I must overwrite my entire directory; isn't this just a drag and drop folder to GameData?

[ferram4]

Yes, you need to drag and drop into GameData, but if you have an older version of FAR you really should delete any old FAR directories first.

[Whovian41110]

40 minutes ago, ferram4 said:

Yes, you need to drag and drop into GameData, but if you have an older version of FAR you really should delete any old FAR directories first.

Ok.  First time though so its a simple mod to install.  Awesome

[ferram4]

Alright, so I fixed a few issues related to drag near Mach 1 that are now available in the dev build on github.  I'm not releasing yet though because I'm still somewhat concerned (though I have no proof) that there are other issues that still need to be worked out; anyone willing to give the dev build a shot and report back anything weird that they find would be very helpful in getting a new version out sooner rather than later.

Edited December 25, 2015 by ferram4

[kcs123]

Air drag near Mach 1 feels OK, it is possible to slow down to deploy parachutes and probes does not accelerate as shown on previous pictures reported earlier.
However, water drag does not feel right. Don't have some real life data, but it should stop splashed down plane much quicker, at least for game purpose.

If you increase water drag too much, it might be impossible to create seaplanes capable to take off due to too much water drag. But, maybe to increase water drag if speed is below 5 or 10 m/s ?

Someting like: Drag = 1 / craft_speed ² 

With safety check that craft speed is not zero. Something like that is only needed for gamebalance reasons, so you don't need long time, just to be able to recover craft.

 

 

[ferram4]

That code already exists, it simply drops in at a lower speed.  The problem is that if I code the water drag so that that particular plane, with almost all of it out of the water has high drag, then anything with any significant amount of stuff underwater simply won't be able to move.  Even worse, it'll ensure that anything that goes deeper underwater during ditching will submarine and then break up due to the forces.

I don't think there's anything I can really do; this is how things behave under low-speed drag.  I'll break everything if I try to make it stronger.

[d4m1ty]

Ferram, just want to say I love this mod, but I am running into an issue on the Analysis GUI when doing the stability derivatives.  

Not sure if this has been seen before, but flaps will not move to their 0-3 positions when selected and calculated.  Spoilers position themselves just fine, landing gear retract, any AOA% changes do as well, but with flaps activated and an angle set, they don't change so no values change.  In flight the flaps will deflect just fine to their set values, this only occurs in the VAB with the Analysis GUI.  In addition, spoilers will deflect inverse to their value but in flight, will deflect properly.  This is for both stock control surfaces as well as the B9 proc ones.

I don't see any error errors messages when this occurs so I'm not sure what i can give you to help.

 

 

 

 

 

 

[tetryds]

@d4m1ty if you look a few pages back you will notice that the flaps issue has been reported several times, never heard of the spoilers being inverted.

Try out the dev build.