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

[Streetwind]

Okay, from what I've seen from searching this thread, FAR replaces the stock parachutes with a RealChute lite implementation. So far, so good.

Now, I just returned from a test flight (testing reenty heating with modified heat config values), and on the capsule, I had both a mk16 main chute and a pair of mk12-R drogues. And what I noticed on descent is that apparently the drogue chutes produce exactly as much drag as the main chute does (that is, a single drogue chute fully equaled the mk16). Checking the info panel, that sort of makes sense in the way that both of these have the same deployed area, which I presume is the main figure that's taken into account.

But doesn't that kind of invalidate having a difference between drogues and main chutes at all? Also, if the drogues are as good as main chutes, but deploy safely at higher speeds, that makes them just massively better all around. Stock KSP has a drag multiplier that is set higher on the main chute than on the drogue, but it seems to have gotten lost in the transition to RealChute lite.

I also noticed that the mk16 main chute actually isn't able to slow a single starter pod down below 7 m/s before touching down. In stock, it would be able to do so, even with one or two extra parts attached. That's important for career mode, where this is the only parachute you have available at the start, yet pretty much all the parts you have (other than the pod and the modular girders) don't survive touchdowns over 6 m/s.

I now have a whole bunch of questions:

- If I wanted to edit the various parachutes' ability to generate drag in order to differentiate drogues from main chutes in my save, how would I go about doing so with FAR installed?

- Are safe parachute deployment speeds a thing with FAR like they are with stock? If so, what are those safe speed limits for main chutes and drogues? Can I view or change them in configs somewhere? The stock chute safety indicator that was added in 1.0.3 didn't survive the transition to RealChute lite either.

(Running the latest version of FAR, manually downloaded and installed today on a fresh 1.0.4 instance. Other mods are present, but none that add or change parachutes... I think.)

Edited July 4, 2015 by Streetwind

[bartekkru99]

Got a question, how many Gs (sustained) a fighter needs to give off at about 200m/s to be considered maneuverable for you? How high do you rise your bar?

[bartekkru99]

Cuz my new PAK-FA replica is able to make 6-7G vertical loop and 10-9G when doing a horizontal one, all at 200m/s

[ferram4]

@smunisto: Like I said, the values after you change a part are fine, it's the ones when you enter the scene that are off. You shouldn't have any problem designing and optimizing in the editor, you don't need to leave the scene and come back to get the right numbers.

@Streetwind: Ask stupid_chris, he's the one that coded that. But, yes, if the deployed areas are the same, the drag should be the same; anything else would be unrealistic given that the shapes are the same. I don't know about what you can get away with deploying, but I know that the reason that I waited until stupid_chris's RealChuteLite implementation was solely to get around the stupidity of 1.0 not having parachutes fail under stress.

[Streetwind]

Alright, thanks. I'll go poke the penguin then

[Insanitic]

I've developed the heating issue as well, but in my case (aside from some flashing temperature values and semi illogical heating during reentry) it's manifested only when staging and very specifically staging. Firing any kind of decoupler or even heating the previous stage to death results in instant runaway overheating of the payload. This will occur regardless of the reentry heat slider. In line with previous reports however it will happen anywhere so long as staging takes place, and the runaway centers on parts placed inside a cargo bay (in this case a probe core or an array of batteries are what fails. Other contents inside are fine). Disabling overheats via alt-f12 will result in the entire vehicle being conducted to max in a few seconds and will sometimes kraken the kerbol system to death Danny2462 style. Will post logs if that particular condition is anything new or helpful.

I experience this EXACTLY, to the TEE. When not staging, or just after liftoff, everything is perfectly fine, no overheating, nothing, both in atmosphere and in space. But as soon as I decouple my core stage, my payload after around 30 seconds real time, start having temperature gauges pop up everywhere, in all the parts, even after I extended 4 medium radiators and turned off my engines. I disabled max temp but the parts still stay heated for no apparent reason.

I deleted FAR and ModularFlightIntegrator just to see what happens and all heating problems were gone. Radiators were doing their job and the temperatures after burning the engines, were going down.

[kcs123]

One more info that could be related with bug smunisto discovered.

I was noticing even in few erlier FAR versions that when you return to SPH/VAB from other scene that AoA sweep graph ans stability analysis are not the same as before.

I didn't raise too much dust about it, I just run AoA sweep 2-3 times until I get same graph shape and same "green" numbers I was having before.

Point is, that bug could be due to stock SPH code and FAR might not be able to correct it.

But there could be hacky way to overcome this. Forcing same calculation as attaching/moving parts one or more times after craft is loaded again in SPH, after scene change. Not exactly proper solution, but could solve that problem.

[bartekkru99]

Hello, I've got a problem, my plane starts to roll and yaw on itself when doing a loop on a horizontal plane and doing barrel rolls.

[kcs123]

Hello, I've got a problem, my plane starts to roll and yaw on itself when doing a loop on a horizontal plane and doing barrel rolls.

Provide some more info about your craft in Official FAR craft repository thread. Screenshots of your plane in SPH with FAR graphs can be of great help to figure out flaws of your design. That thread is created to help with designes and show off of sucessfull crafts. That way in this thread is more easy to track down possible bugs/solutions.

[bartekkru99]

Provide some more info about your craft in Official FAR craft repository thread. Screenshots of your plane in SPH with FAR graphs can be of great help to figure out flaws of your design. That thread is created to help with designes and show off of sucessfull crafts. That way in this thread is more easy to track down possible bugs/solutions.

I have uploaded some pictures from SPH on the repository.

[Temeter]

Hello, I've got a problem, my plane starts to roll and yaw on itself when doing a loop on a horizontal plane and doing barrel rolls.

Maybe the CoL moves in front of the CoM at high inclinations? Check it in the hangar by tilting the craft and watch how the markers are shifting. Or try moving the wings back further, solved the issue when i encoutered it.

Edited July 6, 2015 by Temeter

[gilflo]

Hello guys

I was on holidays and left KSP 1.0.2.

Coming back I loaded 1.0.4 updated FAR and a lot of mods , then I loaded my last SSTO flying perfectly on 1.0.2.

As soon as it appears on runway, the temperature gauges begins to grow up to the red sector, then I got an explosion....

The craft seems ok, but in fact once in flight I can't handle it. It crashes and the first line of report is that my docking clamp o tron exploded at time 00:00 (on the runway)

So what is this heating bug?

If I remove FAR and Modular flight integrator, I don't get this bug.

[ferram4]

This heating bug is obviously an interaction between the changes that were made to the stock heating system between 1.0.2 and 1.0.3. There's a fix in the dev build, but a release is waiting on some other serious issues to be fixed; the heating issue is limited to only certain vehicles for now.

[gilflo]

Thank's for the reply

Any idea which vehicle are concerned?

You mean a release from stock or from FAR?

[Cairol]

I have a similar problem. In 1.0.4 some structural parts spontaneously explode "due to overheating" while I'm still on the launch pad.

Other parts do this too.

[Temeter]

This heating bug is obviously an interaction between the changes that were made to the stock heating system between 1.0.2 and 1.0.3. There's a fix in the dev build, but a release is waiting on some other serious issues to be fixed; the heating issue is limited to only certain vehicles for now.

Thanks, good to know its in the works!

Sounds like there might be general issues with the game itself, tho, even people not using FAR have reported issues.

I have a similar problem. In 1.0.4 some structural parts spontaneously explode "due to overheating" while I'm still on the launch pad.

Other parts do this too.

Check Ferrams Post!

[Crzyrndm]

Bug Report

Using FAR 15.3.1 (manual install) and KSP 1.0.4

While flying along at constant speed and altitude I noted a regular disturbance in the flight path. Upon closer inspection, when this disturbance occurs the control surfaces on the port wing would flick upwards for a single frame with no corresponding action from the starboard wing. The interval and sound distortion indicate this is happening when the floating origin shift occurs (every 6km). This was noted on the stock Aeris 3A with no modifications

Output log

Video (occurs twice: 11-12s and 41-42s)

Edited July 6, 2015 by Crzyrndm

[TheOrqwithVagrant]

This heating bug is obviously an interaction between the changes that were made to the stock heating system between 1.0.2 and 1.0.3. There's a fix in the dev build, but a release is waiting on some other serious issues to be fixed; the heating issue is limited to only certain vehicles for now.

After removing FAR, it _seemed_ to fix the issue - but in fact, it just slows the heating down. With FAR, it happens in seconds, but w/o FAR - it still happens... eventually. So I'm not so sure it's really an 'interaction', but rather that something that FAR does accelerates the overheating bug. In short; the actual BUG is in stock, and FAR just makes it a lot more obvious. A fix in FAR may actually be the wrong thing to do, if it just makes the underlying bug 'fatal' less quickly.

[Hodo]

After removing FAR, it _seemed_ to fix the issue - but in fact, it just slows the heating down. With FAR, it happens in seconds, but w/o FAR - it still happens... eventually. So I'm not so sure it's really an 'interaction', but rather that something that FAR does accelerates the overheating bug. In short; the actual BUG is in stock, and FAR just makes it a lot more obvious. A fix in FAR may actually be the wrong thing to do, if it just makes the underlying bug 'fatal' less quickly.

Are any parts clipped into each other? I have found if I have parts clipped into each other or slightly overlapped it leads to this bug. Not all parts do it but some parts do it, especially if on a wing or other lifting surface.

[AccidentalDisassembly]

Please forgive me if there is just something I'm completely missing, but aircraft with FAR in 1.0.4 just don't seem to do what I would expect. I am guessing it's because I just don't know that much about aircraft, so I'd be curious to learn what's going on here - or maybe whether FAR actually is doing something funky, if in fact it is. The effects I'm noticing are:

1. Flaps seem to produce a really, really large amount of drag when extended past something like 20 degrees (ish), even at low speeds. Also, the drag they produce at those angles jumps very quickly from just a little at ~5 m/s to a WHOLE lot at ~10 m/s. If they're not deflected as much, you can watch the drag vector arrow things slowly grow in proportion with speed, like the lift arrows. Is this how they work in real life? I thought flaps on something like a 747 extend to a pretty steep angle without bringing the plane to a screeching halt. The flaps at around 40-45 degrees are far more effective than airbrakes... This drag is happening at 14.4m/s. I had to go 120m/s to produce equivalent(ish) arrows from a fully-extended airbrake. Fully extending those 3 flaps (on the double-wing version) in flight at ~70 m/s basically made the plane fall out of the sky in a couple of seconds.

2. Wing area seems to correlate to slower takeoff speeds less than I imagined. I've put absolutely massive wings on small planes, reduced wing mass on the slider in the VAB, took out fuel tanks, whatever, but it seems kind of "off" somehow. For instance, I doubled the wing area on the plane in the picture, and it went from maybe 36 m/s takeoff to 33 m/s (doubled version below). The craft with single wings weighs ~9.5t, double 11.5 - middle bits are cargo bays, no fuel in rear, 40 fuel in tank behind cockpit. The wing seems absurdly large to me, like the thing should be able to take off at pretty darn slow speeds. It sits with something like 10-15 degrees of AOA on the runway; its stall speed is the same as takeoff speed, I think, so I don't think it's a question of not being able to nose up enough. I mean, 33 m/s is only 70ish mph, but still... Flaps help, but are my expectations unrealistic given the proportions of the plane?

3. Flaps seem to interact strangely with the rest of the wing. When I extend flaps one notch (max deflects are 30, 37.5, 41 from outside to inside), something like 80% of the lift is lost from all of the wing pieces, and only the flap parts produce much lift. I would have expected that the wing parts right in front of the flaps would "transfer" their lift to the flaps, so to speak, but should the entire wing lose lift uniformly? Pics:

Is my perception here just based on false aerodynamic intuition?

[ferram4]

1. Plain flaps stall at really low angles, and yes, they are that draggy when deployed. Stalling at 45 degrees to the air as you have them shown is expected, especially when the wing forward of it is at ~10-15 degrees. Yes, increasing the velocity by 2x will increase drag by 4x, that's how V^2 variation in aerodynamic forces works.

2. Doubling wing area will reduce the velocity you need to take off by a factor of 1 / sqrt(2), assuming that the aspect ratio stays the same. And assuming that the mass doesn't increase at all and you achieve the same angle of attack and you don't require additional down-load from the horizontal tail to pitch up. If the aspect ratio reduces (as as happened here), it'll be less efficient, it should need a higher angle of attack to achieve the same lift coefficient, and you've got a lot more wing mass to move.

3. Yes, that's what happens when you deploy flaps that are behind the CoM; they reduce the AoA of the plane, and suddenly the forward wing makes less lift. Pitch it back up to the same AoA that it was before and it should have more lift, assuming that the download from the tail doesn't take all of that away.

Honestly, I think most of your problems with the larger wings are that you moved the aerodynamic center of the wing back with it, and suddenly the entire thing is more stable, needs more pitch inputs to control it, and pitches down a lot more under flap deployment. Move it so the wing center is back where it was before you doubled it and it will likely behave a lot better.

[AccidentalDisassembly]

1. Plain flaps stall at really low angles, and yes, they are that draggy when deployed. Stalling at 45 degrees to the air as you have them shown is expected, especially when the wing forward of it is at ~10-15 degrees. Yes, increasing the velocity by 2x will increase drag by 4x, that's how V^2 variation in aerodynamic forces works.

2. Doubling wing area will reduce the velocity you need to take off by a factor of 1 / sqrt(2), assuming that the aspect ratio stays the same. And assuming that the mass doesn't increase at all and you achieve the same angle of attack and you don't require additional down-load from the horizontal tail to pitch up. If the aspect ratio reduces (as as happened here), it'll be less efficient, it should need a higher angle of attack to achieve the same lift coefficient, and you've got a lot more wing mass to move.

3. Yes, that's what happens when you deploy flaps that are behind the CoM; they reduce the AoA of the plane, and suddenly the forward wing makes less lift. Pitch it back up to the same AoA that it was before and it should have more lift, assuming that the download from the tail doesn't take all of that away.

Honestly, I think most of your problems with the larger wings are that you moved the aerodynamic center of the wing back with it, and suddenly the entire thing is more stable, needs more pitch inputs to control it, and pitches down a lot more under flap deployment. Move it so the wing center is back where it was before you doubled it and it will likely behave a lot better.

Thanks, that's very helpful! I still am confused about a couple of points though, especially the drag of the flaps. Here's another picture - I am just guesstimating that the flaps are at roughly 50 degrees to the airflow (41 degrees deflected, something like 5 or 10 degrees of AOA from the way the wheels are). The airbrakes look like they're maybe 50 or 60 degrees to the air too. But the flaps are radically more draggy. Top speed of the aircraft with flaps at 30, 37.5, 41* is ~14 m/s. With all four airbrakes fully deployed but no flaps, it takes off just fine and top speed is something like 70 m/s. Are the airbrakes just that weak in KSP? Is it their placement that makes them so much less draggy than the flaps? The picture is at ~14 m/s.

EDIT: I think I have terminology problems and that that's the source of some of my confusion. I was thinking of angle of attack as something relative to the ground, but it's relative to the air the plane's moving through. Let me try this and see if I've understood: Normal plane moves through air at a steady altitude. Wings are angled to hit the air at a 5* angle (or whatever), making lift in addition to whatever else makes lift on a wing, but the plane overall is perfectly parallel to the ground. Extend the flaps and their downward deflection of air makes the plane climb a little. On the navball, the angle of the plane relative to the ground might be the same, but the flaps' extra lift, which makes the plane move upward on a 5* slope, let's say, makes it so the wings are now effectively moving straight through the air - so much less lift. So that's what I'm seeing here, I think. I was only focusing on the plane's angle to the ground.

Edited July 7, 2015 by AccidentalDisassembly

[monstah]

Hello guys

I was on holidays and left KSP 1.0.2.

Coming back I loaded 1.0.4 updated FAR and a lot of mods , then I loaded my last SSTO flying perfectly on 1.0.2.

As soon as it appears on runway, the temperature gauges begins to grow up to the red sector, then I got an explosion....

The craft seems ok, but in fact once in flight I can't handle it. It crashes and the first line of report is that my docking clamp o tron exploded at time 00:00 (on the runway)

So what is this heating bug?

If I remove FAR and Modular flight integrator, I don't get this bug.

This heating bug is obviously an interaction between the changes that were made to the stock heating system between 1.0.2 and 1.0.3. There's a fix in the dev build, but a release is waiting on some other serious issues to be fixed; the heating issue is limited to only certain vehicles for now.

Ah, at last I find out it's this mod! It was happening with the batteries with me, and a google on 'exploding batteries overheating' or any similar expression will return similar symptoms but for completely unrelated reasons (mostly bad reentry).

Uninstalling FAR did it for me, so I'll wait for a fix.

Also, I happened to quicksave on a fine ship, which would explode instantly on quickload, so I managed to do a few tests with heat damage off: the whole ship would quickly heat to infinity temperature. Meanwhile, the epicenter battery had constant 4.0 internal temperature, a rapidly growing skin temperature, and constant positive skin to interior flux of around 5-6.

I don't know if that positive skin flux means phantom heat being transferred from inside out, while inside was kept cool, or heat going from outside in as the result of high skin temp. I suspect the former, since skin temperature was rising, and the flux was steady. When skin temperature reached Inf., interior temperature went from 4.0 to Inf. immediately.

The rest of the ship behaved as expected, getting heat from the absurdly high battery's skin temperature.

[Temeter]

The aerodynamic indicators are sometimes bugged for radial parts. Rather check the debug menu's aero context info/FARs Drag Highliting.

[ferram4]

Air brakes don't work on the same code; they run on the stock airbrake code. If the effects of that aren't being displayed in the aero indicators, there's nothing I can do to make that better. It is entirely possible that it's just something changed in 1.0.4.

Deploying the flaps will not decrease the lift of the wings if the wing itself is at the same AoA and velocity. This indicates that you weren't at the same AoA, considering the only other things that could have happened were either A) you suddenly lost a lot of velocity, in which case, the lift dropped due to the velocity dropping, or you started immediately climbing due to additional lift.

Shar ethe craft file, because I actually don't believe any of this is possible. Especially not the flaps reducing top speed to 14 m/s, stall just doesn't increase drag that much.