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

[Mode1Bravo]

Just a stupid question: Where am I supposed to put the 'source' folder when installing this plugin? (The readme doesn't give any installation instructions, which is weird...)

unzipping (using winrar) everything to the root folder doesn't work on my computer (The mod just ends up in the KSP-win folder instead of the gamedata folder) .

[Nobody_1707]

You could throw the source folder away if you wanted to. It's just the source code for the plugin, in case you wanted to change some things and recompile the DLL.

Also, try using 7-Zip. It's free and it works better.

[foamyesque]

Could I get some tips on aerobraking on other planets with this mod. What would be good heights that would slow the aircraft down without disintegrating it. I'm aiming for an aerocapture.

If a specific scenario is needed: Here is the one I'm currently facing, an SSTO is docked to a Space Stationy Interplanetary Booster Fuel Ring Thingy, basically an aerodynamic brick assembled in orbit, not meant for atmo. This vessel has way too much delta v for a Laythe Landing, and I'm looking for a way to aerocapture the entire station without wasting its precious fuel.

With FAR, it isn't just height that matters; your wing's AoA is hugely important. If you put your wings in a stall situation you can, in fact, decelerate the whole way through the atmosphere and be done an aerocapture at very high altitudes even from an interplanetary trajectory. Specifics are a lot harder to judge; I'd quicksave and try different periapsises and AoAs.

[ferram4]

Gauss H2K: First, make sure that you figure out what is a stable orientation for aerocapture; if your vehicle is aerodynamically unstable during that maneuver you really won't be able to predict what will happen. Once you figure that out you'll have an idea of whether you can have a very high drag configuration high in the atmosphere or whether you'll have to go with a lower drag configuration and dive deeper for your capture.

Unfortunately, you'll have to take a trail-and-error approach to this. Consider each attempt that fails a "simulation" and then just quickload to try again.

@Firov: I'm aware of the incompatibilities. The shielding-even-when-open problem looks like it is caused by B9 is using the animation modules used by the Firespitter pack, which I haven't coded it to work with. The parts-being-shielded-when-they-shouldn't problem is probably the result of FAR thinking the cargo bay is larger than it is because FAR is trying to find the extremities of the cargo bay expecting that the doors are closed; when they're open it thinks the bay is much larger than it actually is.

@Model1Bravo: Basically the source folder contains all of the C# code that gets compiled into the FAR dlls. Don't worry about it, you don't need it to use FAR, but I have to make the source code available to post the mod here, so I figured that distributing it in the .zip made the most sense.

Why don't you try opening the zip file and just copying the necessary files out rather than dumping them to the KSP directory and hoping that it works out?

[Firov]

@Firov: I'm aware of the incompatibilities. The shielding-even-when-open problem looks like it is caused by B9 is using the animation modules used by the Firespitter pack, which I haven't coded it to work with. The parts-being-shielded-when-they-shouldn't problem is probably the result of FAR thinking the cargo bay is larger than it is because FAR is trying to find the extremities of the cargo bay expecting that the doors are closed; when they're open it thinks the bay is much larger than it actually is.

Hmm. Seems like a reasonable explanation. If they're using a different animation model then I can see how that would break your ability to detect their status.

The odd thing about the outside object shielding is that it's seemingly random. It doesn't just happen when the cargo bay is open. I can be in the middle of my ascent with the cargo bay door closed and suddenly it will shield equipment attached to the outside of the cargo bay. Additionally, opening the cargo bay (assuming you start with it closed) doesn't seem to be a catalyst for this. Very unusual. It's as if FAR is constantly recalculating the size of the cargo bay and inaccuracies creep in to the calculation at higher speeds.

Anyway, since they're using the firespitter animation, is there any chance of a compatibility patch? It would be a shame if there wasn't since B9 is so popular, and otherwise goes so well with FAR.

[Mode1Bravo]

You could throw the source folder away if you wanted to. It's just the source code for the plugin, in case you wanted to change some things and recompile the DLL.

Also, try using 7-Zip. It's free and it works better.

Thanks, my good sir!

Gauss H2K: First, make sure that you figure out what is a stable orientation for aerocapture; if your vehicle is aerodynamically unstable during that maneuver you really won't be able to predict what will happen. Once you figure that out you'll have an idea of whether you can have a very high drag configuration high in the atmosphere or whether you'll have to go with a lower drag configuration and dive deeper for your capture.

Unfortunately, you'll have to take a trail-and-error approach to this. Consider each attempt that fails a "simulation" and then just quickload to try again.

@Firov: I'm aware of the incompatibilities. The shielding-even-when-open problem looks like it is caused by B9 is using the animation modules used by the Firespitter pack, which I haven't coded it to work with. The parts-being-shielded-when-they-shouldn't problem is probably the result of FAR thinking the cargo bay is larger than it is because FAR is trying to find the extremities of the cargo bay expecting that the doors are closed; when they're open it thinks the bay is much larger than it actually is.

@Model1Bravo: Basically the source folder contains all of the C# code that gets compiled into the FAR dlls. Don't worry about it, you don't need it to use FAR, but I have to make the source code available to post the mod here, so I figured that distributing it in the .zip made the most sense.

Why don't you try opening the zip file and just copying the necessary files out rather than dumping them to the KSP directory and hoping that it works out?

Thanks for the explanation! I did it the manual way and it works just fine!

It actually made the game a lot more challenging (rockets too), so that's nice!

[Tripod27]

every time I start the game with the FAR parts loaded my FPS goes down to about one frame ever 3 seconds

using the standard parts everything is fine

also it didn't do this until a day after I downloaded the patch. since then I downloaded remotetech but even without remotetech parts on my ship, the game still lags like crazy with the FAR parts loaded

Edit: oddly enough, doing the scott manley test shows that the mod does still work, even without those parts, so I have no idea what's going on besides me not being able to change stuff in the hangar like the AoA and if I want it to be an airbrake or something

although without the parts my planes go into random flat spins far less often than they did for the day or two when I did have those parts loaded and in general stall far less

Edited June 5, 2013 by Tripod27

[Huelander]

Ferram there is some new engines and intakes with the lastest B9 pack that creates a few drag problems, Taverius kindly explained the probable cause in this post. I will try to explain the best way my poor English allows me to.

By my understanding, those engines and intakes uses another method for intake area so they can weight more than the 0.01 of the stock intakes and have the same amount of air going through them. Because of that, the data on the right click UI on them are wrong, as in 10x what a similar sized intake does, the "air req met" in the FAR UI is 10x+ more than normal the same way. All engines on the pack that came with a intake (CF34, TFE731) and a few intakes (RBM Variable Geometry Intake, RNM Variable Geometry Intake) have this problem.

To illustrate this, I am using your stock plane FAR Fireball.

The drag at this example static analysis without any extra parts looks like this:

Now, with two extra Ram Air Intakes, not that much extra drag:

With two CF34 mounted, it won't ever get off the runway:D:

Two TFE731:

Two RBM Variable Geometry Intake:

And for some reason the "EM engine mount" of the pack does the same, with or without any intake/parts connected to it.

Using two TFE731 (weight 0.49) engines increases the drag almost the same ammount as using one CF34 (0.81), the drag increase seems to be weight related.

Looking for a possible solution in the readme, there is a "FARBasicDragModel" that I've tried using it messing with the values for area and drag for those parts and nothing happens, I am doing something wrong? Or in those cases it won't matter?

The parts-being-shielded-when-they-shouldn't problem is probably the result of FAR thinking the cargo bay is larger than it is

Using a simple structural panel between the wings and the side of those cargo bay solved the problem here, or fuel tanks and then attach the wings to them. Seems that the guess that far does are just a bit over the real size of the cargo bay, at least the "says that the part is shielded, but really isn't" bug that happened with the last B9 version is fixed. Edited June 6, 2013 by Huelander

[grom]

How do you determine terminal velocity when using this mod?

[ferram4]

@Tripod27: If you're not getting anything in the VAB or SPH, that means that FAR isn't being loaded at all; alternatively, it means that you're using the stock "aerodynamics" on the wings but FAR aerodynamics on everything else.

Could you go and reinstall all of FAR, run the game and then post a copy of your output log? Without that I can't find the problem you're having, since I don't have that on my end and there are no other reports like that.

@Huelander: The problem is due to the orientation of the part; FAR is working on the assumption that they're oriented across the airflow in a higher-drag configuration than they should be. I think I've fixed that problem on my end, so the next FAR release should fix it. FAR's air intake values are correct though; it keeps track of the actual resources added rather than just what the GUI value says.

@grom: You take your object up high and drop it.

Joking aside, trying to figure out terminal velocity is incredibly difficult due to the fact that it varies with geometry, orientation to the airflow, the mass of the vehicle. That said, unless your TWR is greater than 3 and you're going to go vertical for a minute you don't need to even worry about it. If you're going fast enough that terminal velocity matters you're going to be worrying more about controlling your rocket than flying it.

Long story short: it doesn't matter; it's about ~400 m/s for a full rocket at sea level. It drops off from there fast.

[Tw1]

Hey, I have a suggestion. The limited Aerodynamics model is also a problem for boats. Could you include the structural panels as a part that gets changed with your mod?

Perhaps someone could show me how to modify them myself?

[Tripod27]

@Tripod27: If you're not getting anything in the VAB or SPH, that means that FAR isn't being loaded at all; alternatively, it means that you're using the stock "aerodynamics" on the wings but FAR aerodynamics on everything else.

Could you go and reinstall all of FAR, run the game and then post a copy of your output log? Without that I can't find the problem you're having, since I don't have that on my end and there are no other reports like that.

What do you mean by "not getting anything"? I have the FAR CAS menu, and I can run all the tests and all that, but I can't modify the control surface AoA and function (because they don't show on the list) unless I use your parts folder, which then causes my game to run at under 1 FPS. I already reinstalled to see if it was a bad unzip, and had the same issue. I did look through the .log after rerunning with the parts put back in the gamedata folder. I was getting something called "FieldAccessException: Cannot set a constant field" about every third of a second along with "NullReferenceException: Object reference not set to an instance of an object" but that happened without the parts loaded (although not as much) and probably isn't the issue

[ferram4]

@Tw1: The structural panel aerodynamics are already modified. I'm not going to try to mess with the water dynamics though, so boats will have the same problems they've always had.

@Tripod27: Okay, then it's the second thing I mentioned: you're only running FAR aerodynamics on non-wing parts. And all of those NullReferenceExceptions? The debug log getting spammed with that is probably causing the slowdown. I need a copy of the output_log uploaded so I can dig through all of those exceptions (and the finer details you don't see printed in-game) and find the source of the error. Without that I can't do anything about your problem because I don't know what the root cause is.

[Tripod27]

where would I find the output log?

EDIT: nevermind, here we go

NullReferenceException: Object reference not set to an instance of an object

at ferram4.FARControllableSurface.CalculateSurfaceFunctions () [0x00000] in <filename unknown>:0

at ferram4.FARControllableSurface.LateUpdate () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

NullReferenceException: Object reference not set to an instance of an object

at ferram4.FARControllableSurface.CalculateSurfaceFunctions () [0x00000] in <filename unknown>:0

at ferram4.FARControllableSurface.LateUpdate () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

NullReferenceException: Object reference not set to an instance of an object

at ferram4.FARControllableSurface.CalculateSurfaceFunctions () [0x00000] in <filename unknown>:0

at ferram4.FARControllableSurface.LateUpdate () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

NullReferenceException: Object reference not set to an instance of an object

at ferram4.FARWingAerodynamicModel.FixedUpdate () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

NullReferenceException: Object reference not set to an instance of an object

at ferram4.FARWingAerodynamicModel.FixedUpdate () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

NullReferenceException: Object reference not set to an instance of an object

at ferram4.FARWingAerodynamicModel.FixedUpdate () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

NullReferenceException: Object reference not set to an instance of an object

at Part.ModulesOnStart () [0x00000] in <filename unknown>:0

at Part+.MoveNext () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

NullReferenceException: Object reference not set to an instance of an object

at Part.ModulesOnStart () [0x00000] in <filename unknown>:0

at Part+.MoveNext () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

FieldAccessException: Cannot set a constant field

at System.Reflection.MonoField.SetValue (System.Object obj, System.Object val, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0

at System.Reflection.FieldInfo.SetValue (System.Object obj, System.Object value) [0x00000] in <filename unknown>:0

at ProtoPartSnapshot.Load (.Vessel vesselRef, Boolean loadAsRootPart) [0x00000] in <filename unknown>:0

at ProtoVessel.LoadObjects () [0x00000] in <filename unknown>:0

at Vessel.Load () [0x00000] in <filename unknown>:0

at Vessel.Update () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

it's basically just an infinite spamming of those errors

I just tried the B9 aerospace pack, and their parts work fine and let you change the flaps and everything, so the rest of the mod works fine as far as I can tell

Edited June 6, 2013 by Tripod27

[Spanier]

Can this mod detect structural panels, that shield off other parts from direct airflow? So this design would be aerodynamically beneficial?

[a.g.]

FAR's air intake values are correct though; it keeps track of the actual resources added rather than just what the GUI value says.

Um, actually unless you changed things since the release, it is using intake.airFlow, which is exactly the air flow value displayed in the menu. Thus, either the value is wrong in both cases, or it is actually right; the only way to resolve this definitely is by doing a flame-out test in the game.

Now, Taverius says that unitScalar and area have been multiplied/divided by the same value, so the result should be right. However, if this code from MechJeb is to be believed to be a faithful representation of the current intake code, the actual formula for the intake air produced is:

mass = atmDensity * aoa * ((vesselSpeed + intakeSpeed) * unitScalar + intakeSpeed) * area * unitScalar

Which represents a quadratic dependency on the value of unitScalar, but only linear on area.

[localSol]

Ferram, I remember reading a long time ago in the FAR patch notes - how it changed biplanes to be less effective / fix them etc. I built a ring wing / annular wing in FAR with PWings today and noticed it seemed to have much more lift than I expected. It seemed unusual that it could also take off at about 40 m/s weighing 5.76 tons, go up to mach 3.6, and do 15+ G maneuvers but stay relatively stable. Very twitchy though I reduced control surface travel to around half of default. You'll need to add landing gear if you (or anyone) want(s) to try it and use my craft file, I merged stock gear with TV's and it wouldn't be compatible. I used TV's lightest smallest gear of weight 0.05. I didn't change anything balance wise. All regular FAR , TV and PWings parts.

Stats : http://www./view/6pe89uyzc8boqhn/ringwing_stats.jpg

Takeoff1: http://www./view/drz6x2mub89udjv/ringwing_slow_takeoff.jpg

Takeoff2: http://www./view/pz6a4fcpk0xsm52/ringwing_slow_takeoff2.jpg

Craft File: http://www./view/cghhh4cdd4e1rq9/RingWing_pwing_highlift_nogear.craft

Thanks!

Edited June 6, 2013 by localSol

[ferram4]

@Tripod27: That sounds like something isn't starting up properly; what is the very first FAR-based NullReference to appear? That should help narrow down the problem.

I'd say that this is probably a result of either an improper install or some type of interference with another mod. What mods are you using?

@Spanier: FAR can't detect the proper result of the payload being shielded by your makeshift fairing; if it attempted to do so your computer would lag to a halt and would probably prevent parts from being affected by aerodynamics when they should have been.

The problem comes down to the fact that while you and I can see that all of those structural panels should behave like a payload fairing in this particular instance trying to create an algorithm for the computer to run to determine this (that doesn't cause performance to drop terribly) is difficult, if not impossible to do.

@a.g.: I think I am using the wrong numbers... I'll look into fixing that for the next version.

@localSol: While it does suffer a decrease in lift due to it being a biplane it benefits greatly due to the effect of closing the planform; essentially it has better lift and drag performance than an equivalent open wing design. You're also using quite a lot of lifting surfaces for a very light design, so taking off at that speed makes quite a bit of sense.

The only reason it actually makes it to Mach 3.6 is because the wings don't fly apart in the transonic regime (like they probably should) and that you're powering it with an engine that is as strong as rockets. Considering the strength of KSP jet engines and the amazing failure strengths of parts, none of this is really all that wrong.

[a.g.]

@a.g.: I think I am using the wrong numbers... I'll look into fixing that for the next version.

Don't jump to conclusions too soon

I actually did a flame-out test with the biggest intake, and the engines flamed out at 100% on the dot, so the numbers perfectly correctly reflect the actual air produced: http://imgur.com/a/dAL2W

[Taverius]

Don't jump to conclusions too soon

I actually did a flame-out test with the biggest intake, and the engines flamed out at 100% on the dot, so the numbers perfectly correctly reflect the actual air produced: http://imgur.com/a/dAL2W

So, I'm a little confused, is unitScalar in a linear relationship like I've been using it, or is it quadratic? If its the latter, I have a lot of intakes to fix

[a.g.]

Well, if you take that formula above:

amount = atmDensity * aoa * ((vesselSpeed + intakeSpeed) * unitScalar + intakeSpeed) * area * unitScalar / resourceDensity

and substitute numbers from this screenshot, you get:

1.223 * 0.105 * 1 * ((295.86 + 100) * 50 + 100) * 50 * 0.000224 / 0.005 = 5722.2

Which is very close to the displayed 5744.44. Now, if you remove the 250x adjustment, the result would be:

1.223 * 0.105 * 1 * ((295.86 + 100) * 0.2 + 100) * 0.2 * 0.056 / 0.005 = 51.5

To achieve the same result with smaller area you need to use unitScalar2 = unitScalar*sqrt(coeff), and, if I did the math right, maxIntakeSpeed2 = maxIntakeSpeed*(unitScalar2+sqrt(coeff))/(unitScalar2+1):

1.223 * 0.105 * 1 * ((295.86 + 100*4.558) * 3.16 + 100*4.558) * 3.16 * 0.000224 / 0.005 = 51.5

Note by the way that there doesn't seem to be an 'intakeSpeed' field in the intake module, but there is a maxIntakeSpeed. Unless it is doing something tricky with it, that intakeSpeed property in the config might not be having any effect.

Edited June 7, 2013 by a.g.

[Tripod27]

@Tripod27: That sounds like something isn't starting up properly; what is the very first FAR-based NullReference to appear? That should help narrow down the problem.

I'd say that this is probably a result of either an improper install or some type of interference with another mod. What mods are you using?

After I deleted some air probe parts from remotetech (I never used them and they looked a bit badly made anyway) the parts started working again.

Since they stopped working after I installed remotetech, I guess that air probe was causing the issue?

[Taverius]

To achieve the same result with smaller area you need to use unitScalar2 = unitScalar*sqrt(coeff), and, if I did the math right, maxIntakeSpeed2 = maxIntakeSpeed*(unitScalar2+sqrt(coeff))/(unitScalar2+1):

Note by the way that there doesn't seem to be an 'intakeSpeed' field in the intake module, but there is a maxIntakeSpeed. Unless it is doing something tricky with it, that intakeSpeed property in the config might not be having any effect.

Thanks! I'll fix the B9 intakes and Pizza Pack intakes ASAP.

About intakeSpeed, it is indeed doing absolutely nothing. However, were you to fix the syntax of the stock intakes you would find yourself most likely flaming out on the runway. The fact that all the intakes have a base speed of 100m/s instead of 10m/s has so far masked a bug with intakes when speed is close to 0 which can cause the IntakeAir value to fluctuate wildly. So keep using the default of 100.

Well, now the intake speeds are pretty meaningless, but oh well.

Edited June 7, 2013 by Taverius

[rhoark]

I'm having issues with the B9/Firespitter airbrake.

First off, it's having an effect even while on top of the wing while flying belly prograde. I'm not sure whether responsibility for shielding it should go with the airbrake part cfg, Ferram, or the pWing the airbrake is sitting on top of.

Secondly, Firespitter models the airbrake basically as a brick of variable size, rather than an angled surface. That's obviously not in Ferram's purview, but I figure people looking at this thread would know how to get started modeling the airbrake more properly as a toggled control surface.

[a.g.]

The fact that all the intakes have a base speed of 100m/s instead of 10m/s has so far masked a bug with intakes when speed is close to 0 which can cause the IntakeAir value to fluctuate wildly.

The quadratic unitScalar is labeled as an intake bug in that MechJeb code too, and it does look like a bug - probably something like a "speed = (speed + intakeSpeed) *unitScalar" line repeated twice or similar.

Re intakeSpeed, fortunately the required change if you only want to reduce area while keeping the final value the same is actually increasing it from 100: in the above case, to as much as 455.8.