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

[Kitspace]

So as I understand from posts a couple of pages ago there will be a separate plugin for the modular wing systems?

[ferram4]

@Hodo: Link still gives 403.

@Kitspace: I'm not sure what you're asking about; I'd suggest that you spend some more time thinking about your questions before asking them as well as doing some more research on your own, since I have noticed a tendency for your questions to include highly inaccurate assumptions that would be corrected with enough research or time spent thinking about it.

[Hodo]

@Hodo: Link still gives 403.

Try this one.

Output

[ferram4]

Known issue, dev build might have fixed it, but I haven't rigorously tested it yet.

[Black-Talon]

@Black-Talon: Load it up in-game without the parachute module on, then dump the drag configs. That's why I added that feature. In any case, why is it being detached from the lower booster anyway?

@ferram:

This sounds perfect, I wasn't aware of the feature. I will figure that out and give it a try.

One concern I have is that I have previously removed the parachute module and loaded it in game to discover that the model is then in the game with the chute partially deployed. Which I think I recall might be exactly why FAR doesn't automatically attempt to model drag of parachute parts... But I'm going to try a few things and see what I can come up with.

"why is [The Nosecone/Probe/Parachute] being detached from the lower booster anyway?" - This is a feature of Sounding Rockets boosters. The purpose of which (I believe) is to make staged sounding rockets at Tier 0 Career availible without providing staging to the other more powerful rocket parts at that stage of the game. An interesting idea imo - not sure it isn't exploitable but no worries on my end.

[xiziz]

I'm quite sure I've found a conflict in having ModuleCommand and ModuleResourceIntake on the same part. The intake module seems to override the command module and prevents the flight GUI from showing.

Discovered this while using vens stock revamp, which adds ModuleResourceIntake to the MK1 Cockpit, which consequently does not want to show the far flight gui.

Adding ModuleCommand to a stock air intake produces the same result

I'm guessing there is something in the gui that makes it appear only when there is a ModuleCommand onboard the craft.

Adding a part with ModuleCommand to the one with ModuleCommand & ModuleResourceIntake makes the gui show again(2 parts on launchpad). So the conflict seems to be when both modules are loaded on the same part.

Sorry if this was already known, was a wee bit many pages to read through to check, but I could not find anything relevant using the search function.

[Black-Talon]

I'm also hitting what I think might be a real issue - I can reproduce it, but I haven't been able to narrow it down to FAR + Stock yet. Sounding Rockets is definitely involved. It is a two part thing:

1) With Sounding Rockets (and specifically the Nosecone I've been messing around with as seen in my previous posts) the FAR Flight GUI will not appear if that Nosecone is equipped - I was going to try to find out if I can get this to happen with other parts as well but so far I haven't succeeded so it may be specific to that Nosecone part for some reason... Any guesses?

2) When I add the FARBasicDragModelmodule to the Nosecone part the drag works as I would hope - BUT as soon as I crash the rocket and revert flight to launch - the log fills with NullRefExceptions. I can launch again but the drag seems messed up. Perhaps related to #1 since I can't get it to happen on a stock part yet.

If anyone wants to reproduce, here is a package containing logs of me reproducing it, the specific part for Sounding Rockets along with it's supporting DLL. My steps to reproduce are as follows:

1. Launch KSP - Dump the ModuleManager logs for reference - Bring up Debug output to watch for NullRefs
   
2. Create new Sandbox game - Go directly to Launch Pad loading Test07b (Stock)
   
3. Note - FAR Flight GUI is unresponsive (does not display)
   
4. Launch rocket - wait for it to crash with no further stages executed - Impact water - Revert to launch
   
5. Note - if FARBasicDragModel has been added to Nosecone, NullRefs now appear in Debug - otherwise no NullRefs
   
6. Note - FAR Flight GUI is unresponsive (does not display)
   
7. Launch rocket - wait for it to crash with no further stages executed
   
8. Note - Debug log is filling with NullRef exceptions
   
9. Note - Right clicking on Nosecone part shows no drag or FAR values are applied (all are zero in flight)
   
10. Impact water - Exit game
    

1st Zip - Logs and all files to reproduce WITHOUT applying FARBasicDragModel - This will reproduce Issue 1 but not Issue 2:

Test SR Nosecone1 - FAR Flight GUI Fail.zip

2nd Zip - Logs and all files to reproduce WITH FARBasicDragModel applied - This will reproduce BOTH Issue 1 and Issue 2:

Test SR Nosecone2 with BasicDragModel Applied.zip

Note first NullReferenceExcpetion is:

NullReferenceException  at (wrapper managed-to-native) UnityEngine.Transform:INTERNAL_CALL_TransformDirection (UnityEngine.Transform,UnityEngine.Vector3&)
  at UnityEngine.Transform.TransformDirection (Vector3 direction) [0x00000] in <filename unknown>:0 
  at ferram4.FARBasicDragModel.RunDragCalculation (Vector3d velocity, Double MachNumber, Double rho) [0x00000] in <filename unknown>:0 
  at ferram4.FARBasicDragModel.FixedUpdate () [0x00000] in <filename unknown>:0

[atomicfury]

Ferram,

I've been helping debug loss of FAR support for the Atmospheric Trajectories mod with 0.14.5.1. I traced part of it to the new skin drag coding. I might have found something but I don't know what your intended behavior of FAR is.

When Trajectories initializes, to initialize FAR it runs a drag calculation with some high values, looking for a number greater than 1 to tell if FAR is working. With the new skin drag code in FAR 0.14.5.1, something was spitting NaN's back. I put some debug statement in FAR and found that in FARBasicDragModel.cs, DragModel was using a zero rho. Trajectories was passing rho=10 to RunDragCalculation, which was using rho=10. I think DragModel is getting a different rho from another scope. Maybe, I'm not terribly familiar with C# so I could be off base here.

A possible fix is to pass rho to DragModel from RunDragCalculation. I put that change into a local version, compiled it, and it appears to work fine. I've put a pull request in if this makes sense.

Thoughts?

Edited December 24, 2014 by atomicfury
Put in note on pull request

[Tonnz]

I'd like to report a bug i had many times, in older versions as well. Always when using RO.

Of course i use the 32bit version of KSP and i do not have any problems at installing mods.

When using Realism Overhaul (Plus all the required mods, most of the recommended mods, and many of the supported mods) FAR just doesn't work. I have the FAR icon in the toolbar, but when clicking it nothing happens, and i am 100% sure that the game uses the stock aerodynamics model. I tried reinstalling FAR, did not help.

I do not use ActiveTextureManagement (instead i set the texture quality to half res), i usually do not encounter memory problems.

I hope there's a way to fix it

(Pure part packs/mods without dlls are not included)

Toolbar

AIES

AJE

CrossFeedEnabler

CustomBiomes

DDSLoader

DeadlyReentry

EngineGroupController

FASA

FAR

RasterPropMonitor

KAS

KerbalJointReinforcement

Infernal Robotics

ModuleRCSFX

Procedural Wings

Procedural Fairings

Procedural Parts

RealChute

RealFuels

RealismOverhaul

RSS

SmokeScreen

StockBugFixModules

Tac Life Support

TextureReplacer

TweakScale

Module Manager

EDIT:

I've set the texture quality to "quarter res" and now it works perfectly. Maybe just a memory issue after all. I should've tried that before posting .

Edited December 24, 2014 by Tonnz

[ferram4]

@xiziz: Known issue, I'll have do deal with that somehow.

@Black-Talon: The NRE is from something in stock KSP. I don't know what causes it, but sometimes the root part transform is borked somehow. It's not something I've been able to fix or even track down, and the best I can do is get around it. I thought I'd fixed this one. I'll see what I can do, but in the mean time, yell at Squad to fix this one, it's not on me.

@atomicfury: Yeah, I see what happened. Okay, next dev build that goes up at some point will have that fixed, and then it will be in the next release.

@Tonnz: FAR's functionality is not dependent on memory usage; if FAR is the tiny straw that finally breaks the camel's back, the game will simply crash.

Your report also has no reproduction steps. I have used FAR in RO with no issue, so without more information, you're on your own.

[bdito]

Can sombody confirm this for me (or set me straight). The Frac SL Density number is the density of the atmosphere right? And since it drops to 0.000 at ~40,000 meters that's for all intents and purposes the top of the atmosphere right? So I should be at a 90 degree angle during the ascent at 40 km?

[kcs123]

Can sombody confirm this for me (or set me straight). The Frac SL Density number is the density of the atmosphere right? And since it drops to 0.000 at ~40,000 meters that's for all intents and purposes the top of the atmosphere right? So I should be at a 90 degree angle during the ascent at 40 km?

Nope. 40 km is still dangerous for 90 degree angle due to high speed, your plane still can easy backflip or something worse. 0.000 value only means that density is rounded to 3 decimal places, some atmosphere density still exists up to 70 km. Still, after 40 km steeper angle is more possible to esceape atmospher more quickly.

[bdito]

Nope. 40 km is still dangerous for 90 degree angle due to high speed, your plane still can easy backflip or something worse. 0.000 value only means that density is rounded to 3 decimal places, some atmosphere density still exists up to 70 km. Still, after 40 km steeper angle is more possible to esceape atmospher more quickly.

Ok. I knew there was still atmosphere up to 70km but I thought it was so minimal that it wouldn't create enough drag to make much of a difference above 40km.

[Black-Talon]

@Black-Talon: The NRE is from something in stock KSP. I don't know what causes it, but sometimes the root part transform is borked somehow. It's not something I've been able to fix or even track down, and the best I can do is get around it. I thought I'd fixed this one. I'll see what I can do, but in the mean time, yell at Squad to fix this one, it's not on me.

Thanks for the info; It's interesting that I haven't seen the NRE issue (not that I've been looking) but it happens every time with those reproduction steps. I do have a suspicion that it could be the parachute + rootpart. Squad parachute models cannot be root parts. If it's KSP causing the root part transform to muck up, does it normally happen all the time? Does Squad already have reproduction steps? I'm always game for reporting issues with the right reproduction steps to the right people but I suppose I don't know what I'm dealing with here.

Any by ideas on issue 1? Where the Flight GUI won't open when using that specific part? Perhaps related to that other known issue where it isn't opening? This silly Nosecone is killing me. :-(

Edited December 25, 2014 by Black-Talon
too sleepy to write without being embarrassed when I read it later

[atomicfury]

@atomicfury: Yeah, I see what happened. Okay, next dev build that goes up at some point will have that fixed, and then it will be in the next release.

Thanks ferram. On a side note, I'm really enjoying the fact you put in a Reynolds number display. The only aero engineering I know comes from KSP and your mod, but I deal with internal flow, so it's near and dear to me.

[blowfish]

Ok. I knew there was still atmosphere up to 70km but I thought it was so minimal that it wouldn't create enough drag to make much of a difference above 40km.

Be careful - drag decreases with altitude but increases with speed, so if you're going very fast at a high altitude you're still going to have appreciable drag. The more useful number to look at is dynamic pressure - best not to try anything too crazy until the dynamic pressure is very low.

[NathanKell]

Not just that: drag decreases linearly with density, but increases quadratically with speed (i.e. the square of velocity).

[bdito]

Be careful - drag decreases with altitude but increases with speed, so if you're going very fast at a high altitude you're still going to have appreciable drag. The more useful number to look at is dynamic pressure - best not to try anything too crazy until the dynamic pressure is very low.

Not just that: drag decreases linearly with density, but increases quadratically with speed (i.e. the square of velocity).

Thanks for the tips. I never thought about that. Makes perfect sense.

[sh5525]

there are some issues about my FAR that I can't understand:confused:

It's about the aerodynamic analysis, and to make sure it's an good example I put a lot of insane control surfaces as spoilers

why the Cd line doesn't change? And the graph is almost as same as last one, because the y-axis has changed too. And when I click the button one more time without any change of spoilers or anything else, the graph changed...

https://t.williamgates.net/image-940B_549BED2A.jpg' alt='image-940B_549BED2A.jpg'>

Why is all of this???

Edited December 25, 2014 by sh5525
former pictures crushed

[Tic-Tac]

It's normal... there's no way you can deorbit less than .25 orbit from where you wan't to go ( actually yes , but lets talk only about common situations ).

It's weird though, it wasn't this hard if i recall correctly, the last time I played, could land a spaceplane with about 0.1 orbit.

Probably my mind getting old.

Thanks for the helpful answers !

[DaMichel]

Hello Ferram4,

here is a little bug report. I have an issue with extreme drag on some random parts of a plane which is about an order of magnitude larger than on all other parts. That is really all i can say. I just build a normal sub-sonic plane and one part gets a really high drag force. Here is an example. 18kN on a Structural Fuselage at mach 0.4 at sea level.

https://www.dropbox.com/s/n5dj2jivalum92v/screenshot16.png

this is the craft file

https://www.dropbox.com/s/oc1yase0peq66zf/FAR%20Odd%20Drag%20Test%20Plane.craft?dl=0

as far as i can tell, FAR is installed correctly, all the modules are loaded and each part shows the drag force and whatnot on RMB. This was tested with the FAR dev version (https://github.com/ferram4/Ferram-Aerospace-Research/commit/845ca57753e3014ec49ea2eff22765ba088d0029).

Cheers, and thanks for your unrelenting work. Merry Christmas, too.

[Behemoth1702]

Hey guys, I am a newbie at this since I've installed FAR just now. I really enjoy the FAR planes, they greatly show off how the improved aerodynamic calculations make the whole aerodynamic aspect way more realistic!

I've read through the wiki on GitHub, but I can not figure out/understand all the different parameters on the control surfaces. I kind of get pitch/roll/yaw, I guess it splits up the input into percentages. The more % you set the more it will deflect. The deflect amount is also clear. But what is %AoA? It seems to do something with angle of attack but I have no idea what it does or how to use it.

Can anyone help? Thank you!

[cantab]

I believe that makes the control surface automatically respond to the angle of attack. So as you pitch up you can have it automatically deflect up or down.

I'm not sure what you'd use it for. Maybe some sort of automatic stabiliser?

[Behemoth1702]

Another thing - I just can not get a plane that has it's yellow stability graph going down when AoA rises. It goes down a bit, then slowly up and stay negative BUT it does not continue to go down, such as with the FAR planes. My CoL is always behind CoM.

Am I that bad of a plane designer? Should I add/remove wings? Weight? Control surfaces? :-/ No idea what causes this.

[Wanderfound]

Another thing - I just can not get a plane that has it's yellow stability graph going down when AoA rises. It goes down a bit, then slowly up and stay negative BUT it does not continue to go down, such as with the FAR planes. My CoL is always behind CoM.

Am I that bad of a plane designer? Should I add/remove wings? Weight? Control surfaces? :-/ No idea what causes this.

Go to the next page, look at the numbers. Hover your mouse over the red ones. That'll bring up a tooltip telling you what's wrong.

If you're having pitch instability problems, you've probably got too much lift at the front of the aircraft or not enough horizontal stabilisers. Let your CoL move backwards; most of the time, it does not need to be as close to CoM as it would be in stock aero.

You'd likely get some use from this tutorial: http://s1378.photobucket.com/user/craigmotbey/Kerbal/Tutorials/Hangar%20to%20Landing/story

Edited December 25, 2014 by Wanderfound