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

[Flayer]

I am trying this mod, but it appears I am now incapable of boosting a rocket into orbit ( I think I am just really bad at it lol )

[ferram4]

@AndreyATGB: They should be shielded. They always have been before. That's quite odd, I'll have to look into it.

@Flayer: Lower TWR. Start gravity turn early. Stay pointed prograde. Don't put really light fluffy payloads on top of big heavy rockets. Fairings. Fins if you need them. Pictures help with diagnosis.

[Tiron]

Is there a FARWingAerodynamicModel PartModule attached to it currently? If not, and you're using FAR, FAR is going to add a FARBasicDragModel PartModule to it, since there's no exemption for FSliftsurface in the FAR configs. And FARBasicDragModel can really screw up on parts like that

I added an exemption for FSliftSurface as I mentioned previously, and it didn't particularly change anything so far as I can tell. I'm pretty sure the lift surface *itself* is the source of the drag, because when I say 'enormous' I mean it. I'm not talking 'FAR wing panel turned perpendicular to the airflow' or 'giant cylinder', I'm talking stock-level drag. As in 'similar to the OP B9 Airbrakes I use'. One time I started a shallow descent from about 25km at about mach 4.5, engines off, and was down to about 300 m/s by 14km. *Without* using the brakes like I normally do.

(FYI: if there's a way to port those brakes over to FAR I'd love to hear it, because I mostly use them for the for the look. I'm guessing the answer is 'no' or you would've done it in the default .cfgs. I will admit I kinda like using them to pull out of a spin, though. ;P )

It's perfectly possible for you to attach a FARWingAerodynamicModel to it, but you're going to have to hack it as an unswept wing and add "nonSideAttach = 1" to the MODULE node to get it to center the CoL. If you said you wanted an inaccurate hack to begin with, you should have just asked for it.

I didn't really, but given that you made it quite clear an accurate one wasn't possible, and I discovered it wasn't behaving accurately to begin with, I'm willing to settle. It just got frustrating that every time I asked something, your explanation seemed to suggest some way it *could* work, if less accurately. Sorry if I got a bit snippy.

Sometimes, one just has to suck up the limitations and deal with it. There's a reason 'workaround' is a word. I'd prefer not to, but some semblance of accuracy is better than none at all.

Trying to figure out how to do a high Mach STOL is giving me headaches. The coaxial-contrarotating twin rotor (think 'KA-50') that the same pack comes with works fine. The amount of drag is insignificant and it's even slightly more powerful than the wing-rotor. But carting a rotor along (especially a twin-rotor) at Mach 5 is just too absurd for me to accept. Every time I look at it, my brain goes '*snerk* yeah, right.'

FAR does reference the models, but it doesn't go into the complicated mess of "how much is this part inside this other part" unless it's looking at cargo bays and payload fairings. The "stuff in front lowers drag of stuff behind" is related to parts attached in a stack, which makes figuring out how the drag of one thing affects another thing easier.

That actually makes a lot of sense, from a computing standpoint. It's just not obvious, or more importantly, intuitive. There's no real way to tell what the shortcuts and limitations are, though once mentioned it's fairly obvious they have to be there (non-idealized drag equations are just INSANE.)

Edited May 8, 2014 by Tiron

[federally]

Ferram does FAR take into account a wings thickness in any way?

I'm wondering if changing the thickness of my Procedural Wings will make any difference in lift and drag

[ferram4]

(FYI: if there's a way to port those brakes over to FAR I'd love to hear it, because I mostly use them for the for the look. I'm guessing the answer is 'no' or you would've done it in the default .cfgs. I will admit I kinda like using them to pull out of a spin, though. ;P )

Ummm... it would require a bit of math and assumptions, and I haven't done it because I generally thing running around trying to fix other mods is something that will be irritating and take up too much of my time. The way you'd want to do it is to find the area of the brake surface, and then pick a drag coefficient for it (I'd say ~0.7, 0.8 for their size and angle). Then you need to convert that to maximum_Drag for KSP's stock system to function with. So the equation you'll have to solve is:

drag_coeff * area = mass * 0.008 * maximum_Drag

Then set the drag value for the part equal to the number that comes out of that equation. Standard maximum_Drag should be set to 0.

I didn't really, but given that you made it quite clear an accurate one wasn't possible, and I discovered it wasn't behaving accurately to begin with, I'm willing to settle. It just got frustrating that every time I asked something, your explanation seemed to suggest some way it *could* work, if less accurately. Sorry if I got a bit snippy.

Sometimes, one just has to suck up the limitations and deal with it. There's a reason 'workaround' is a word. I'd prefer not to, but some semblance of accuracy is better than none at all.

Trying to figure out how to do a high Mach STOL is giving me headaches. The coaxial-contrarotating twin rotor (think 'KA-50') that the same pack comes with works fine. The amount of drag is insignificant and it's even slightly more powerful than the wing-rotor. But carting a rotor along (especially a twin-rotor) at Mach 5 is just too absurd for me to accept. Every time I look at it, my brain goes '*snerk* yeah, right.'

If the wing was somehow an oblique wing (so a straight wing at an angle) you'd be able to get most of the benefits of sweep with the accurate modeling (except in rotor mode, but whatever). Unfortunately, FAR works on the assumption that wings can be set up as a single trapezoidal lifting section with the origin at the wing root. Except for where it can make an exemption for the control surface only parts (which is less accurate, but functions , and that's what you'll be hooking into).

That actually makes a lot of sense, from a computing standpoint. It's just not obvious, or more importantly, intuitive. There's no real way to tell what the shortcuts and limitations are, though once mentioned it's fairly obvious they have to be there (non-idealized drag equations are just INSANE.)

Nonlinear PDEs are a pain, aren't they?

Ferram does FAR take into account a wings thickness in any way?

I'm wondering if changing the thickness of my Procedural Wings will make any difference in lift and drag

No, that is only a visual effect. Otherwise, lots of stock and mod parts would perform very badly because they have improper cross-sections for wings.

[federally]

That's sad

[Tiron]

If the wing was somehow an oblique wing (so a straight wing at an angle) you'd be able to get most of the benefits of sweep with the accurate modeling (except in rotor mode, but whatever). Unfortunately, FAR works on the assumption that wings can be set up as a single trapezoidal lifting section with the origin at the wing root. Except for where it can make an exemption for the control surface only parts (which is less accurate, but functions , and that's what you'll be hooking into).

The actual shape of the blades is a pair of isosceles trapezoids that share the larger of the parallel sides. It starts with a narrow part that attaches to the hub, expands outward for a short distance, and then tapers very slightly down to the blunt blade tip. The taper is fairly slight from the wide point out to the tip (less so from the wide point to the hub, the hub connection looks like it's about the same size as the tip but the wide-to-hub section is MUCH shorter.)

When it folds up, all it does is flatten their pitch(0 collective, basically,) flip them back into a 'V' shape, and collapse the hub. (There's some complications involving what happens if it's spinning already when you want to fold it, but that's a bit out-of-scope at the moment.)

So if my understanding of what you said is correct, it's pretty darn close to *being* a pair of oblique wings in wing mode. Of course, I also got the impression that it doesn't really matter, as it sounds from what you said like the nonsideattach bit simplifies things in a way that would prevent it from modeling that anyway.

So here's a question: if the wing module can handle oblique wings, would it be possible to 'fake' movable wing support by attaching the FAR wing module to just the wing part of the model? I realize it can't do this now, and you'd probably have to (somehow) be able to set a fake!origin for the wing module to work right (no idea how you'd do that, that sounds like it could be somewhat difficult to find the right co-ords).

I really don't know what I'm talking about, I'll freely admit, but that occurred to me just now based on your explanation...

Edited May 8, 2014 by Tiron

[Dirt_Merchant]

Flutter would be a very welcome addition.

Your butthurt aside.

The only reason I cared to share my points is that your plugin is the sole reason I still play the game after 2000 hours.

This is the most backhanded compliment/statement I've ever agreed with;)

@ferram4: Thanks for being awesome. Thanks for being patient. Thanks for giving us the ability to tweak all things in-game. Thanks for considering adding flutter;) Also, very excited to hear more about the FAR replacement, I have heard tell of some of the specifics, but might I trouble you for a couple details regarding new features, aero-modeling techniques, or anything you care to comment on? If you'd rather keep it quiet, I understand. Also, as a complete aside... Any news on those "dumb" control surfaces? No worries if you don't wanna mess with them at this point, was just curious;)

[Keldor]

How about adding some randomization to the aerodynamic failure point? In real life, the exact point at which something breaks is unpredictable and random, so this would make disintegration look more realistic, since instead of both wings falling off at the exact same time, one would fail, the craft would turn sharply as a result, which would force the other to fail. Much more interesting looking. The current failure point could just be treated as a lower bound where things might break.

[phoenix_ca]

How about adding some randomization to the aerodynamic failure point? In real life, the exact point at which something breaks is unpredictable and random, so this would make disintegration look more realistic, since instead of both wings falling off at the exact same time, one would fail, the craft would turn sharply as a result, which would force the other to fail. Much more interesting looking. The current failure point could just be treated as a lower bound where things might break.

While more realistic to add random failures, it is generally a very, very, very bad idea to add any mechanic to a game that solely punishes the player for an RNG outcome over which they have little control. It's very much a rage-quit inducing "feature" that can remove players from your fan base for good.

Think about the problems random failures could create in more mundane situations. What if some player is returning to Kerbin with a design that has withstood many a reentry, at incredibly high speeds, and a randomized failure causes a wing to explode under relatively moderate conditions. Kerbals die, payloads are lost. The solution now in such a case would be to revert; previous to the rewrite of that particular bit of KSP there was no option other than going back to your quicksave and hoping it was in a reasonable place.

Or alternately, random failures causing a rocket that performed very well in past suddenly breaking-up. This stuff happens enough already when dealing with payload changes and good ol' pilot error. Adding more entropy intentionally would just compound the problem, creating a situation where a player doesn't know for certain whether they were hit with just bad luck or bad design. One they can fix, the other they just hit revert and try again. But not knowing, and even suspecting that the deck may be stacked against you, so-to-speak, can be a massive downer for any player.

Plainly, it's just not fun. Random failures sound more interesting than they really are, and in terms of effect, they would be equivalent to out-of-memory errors we already get with 32-bit KSP binaries, and provide just as much depth as those CTDs do.

[Tiron]

[Words]

He's not talking about making the failures themselves happen randomly, just about making *how* they happen more random. So that pulling the same, too-hard maneuver will result in slightly different failure patterns. What causes the failures and when would be consistent and predictable, the exact nature of the failure itself would not. Big difference.

[ferram4]

@Tiron: No, it can't model a pair of oblique wings that way, because if you tried to do that you'd end up with it instead modeling a pair of overlapping wings centered at the same position, and there's no way to attach the FARWingAerodynamicModels to the wing transforms themselves; they're PartModules, they only work with the wing as a whole. What you're asking for can't be done in the current way that FARWingAerodynamicModel is coded.

@Dirt_Merchant: The FAR replacement is basically this:

Take part meshes.

Run through mesh simplification algorithm to create simple model of vehicle.

Solve linear potential flow around the aircraft using a panel method (essentially, covering the surface of the vehicle in a group of known solutions to the linear potential flow equation and then adjusting their strengths to make the vehicle solid wrt the incoming air)

Get pressure across model from panel method solution.

Integrate to get lift and drag forces distributed across vehicle.

Add finagle factors for viscous effects, use some of that to adjust the panel method for additional accuracy.

It's going to be either awesome or laggy. Either way, it's interesting and frustrating at the same time.

Also, no news on dumb control surfaces, but that's because I've been kluging out ^that sort of stuff.

@Keldor: No, that leads to the irritating situation where someone rides just on the other side of the line for a bit, everything is going perfectly and then it spontaneously falls apart. Or alternatively, the vehicle gets through a bunch of really nasty aerodynmaic forces fine, but then falls apart at something much lower. Does not make for good gameplay because it makes the failures less due to the player's choices and more up to the pseudo-RNG.

[phoenix_ca]

He's not talking about making the failures themselves happen randomly, just about making *how* they happen more random. So that pulling the same, too-hard maneuver will result in slightly different failure patterns. What causes the failures and when would be consistent and predictable, the exact nature of the failure itself would not. Big difference.

"adding some randomization to the aerodynamic failure point"

That sounds like the very same thing with the same result as I described.

Maybe you're closer to what they meant, but I stand by my interpretation.

Edit: And ferram seems to have covered the other reasons why even if my interpretation is wrong, it's still a bad idea.

[NJC2]

Something weird is happening with FAR. I haven't flown any aircraft in three or more versions of FAR. Today I decide to build a new aircraft to go collect the last bits of science left on Kerbin. I ran though several designs and no matter how much tweaking I always got the same result when testing the aircraft. When I stall it, it settles flat, slightly rear down and just falls down in this attitude no matter how far forward the CG is of the center of lift. It acts almost as if it's in a vacuum or very thin air. I can get a little roll and yaw out of it, but it pitch control seems almost non existent. I loaded up an earlier aircraft that flew fine the last time I used it. I remember it being very stable, nearly impossible to stall, and if I did stall it, it just pitched back down and recovered on its own. Now it too behaves as above after stalling.

Another odd thing is happening too. If I fly to the upper atmosphere (>18,000m) and then descend back, it seems to act as if it's still flying in the thin upper atmosphere. It's very sensitive and twitchy up there. I take off, fly at 45° nose up until I hit 18k altitude. When I ease the stick forward (I'm using an Xbox 360 controller to fly) to level out, it goes out of control. Every time, with several different designs, it yaws to the right, then rolls over and flies belly first into the direction of flight. After bleeding off speed and descending back to the lower atmosphere it is nearly impossible to recover. A few times I managed to recover control, but it still seems to fly as if it's in the thin upper atmosphere after I descend back to the lower atmosphere.

I did a test by flying to the upper atmosphere in a gentler approach. I flew at 45° until above 10,000m, then at 15° until hitting about 20k. I then cut the throttle and let it pitch down on its own. By the time it had nosed over and descended below 18k it was going over 500m/s, and I was barely able to pull it up to level off. I managed to get it leveled off at about 4000m altitude and it had slowed to 200m/s by then. Pulling full up elevator at this altitude and speed barely did anything. I loaded the same aircraft, took off and flew up to 4000m, then pulled full up elevator at 200m/s and it rips its wings off.

[AndreyATGB]

While your description is pretty detailed, we're still gonna need pictures and seems logs as well since something must be going wrong.

[Azimech]

It's funny to see how a manned re-orbit capable Eve lander is now nearly impossible using the newest FAR and DRE. Maybe a spaceplane with asparagus stages. Maybe. With a ballistic trajectory of a normal craft you either burn through your heat shield, die of g-forces or get torn apart due to the new aerodynamic stresses. Or you simply don't have the delta-v to get back to orbit.

With stock parts it's totally impossible.

I love it.

[phoenix_ca]

Maybe a spaceplane with asparagus stages. Maybe.

I'd love to see that. Seriously. I think it would be quite funny to watch as FAR...does its thing.

[mcviscount]

I am having a problem where installing Ferram breaks other mods like Mk 2 Cockpit Interior, RasterProp and RemoteTech2... I'm only using one MM etc.

Regards.

[AndreyATGB]

It's funny to see how a manned re-orbit capable Eve lander is now nearly impossible using the newest FAR and DRE. Maybe a spaceplane with asparagus stages. Maybe. With a ballistic trajectory of a normal craft you either burn through your heat shield, die of g-forces or get torn apart due to the new aerodynamic stresses. Or you simply don't have the delta-v to get back to orbit.

With stock parts it's totally impossible.

I love it.

I tried to build one but I doubt it's possible with stock parts. You'd have to make it fly both forwards and backwards, which is impossible as far as I've seen. What might be the only way is to make it fall in a box and jettison that, revealing a normal rocket under it, realistically you'd use balloons to get to altitude and go from there though.

[DaMichel]

In this thread full of whine and nagging i think it is time for something nice again :>

May i present to you the Kylon Space Transport. Obviously inspired by the Skylon and again there are many like it but this one is mine. Many Kerbals have sacrificed their lives for this glorious achievement of engineering. Really, because the first iterations were manned ... Now it works pretty well and i like the look of it. It is like a shark in space

It is pretty much perfectly balanced, takeoff and landing is easy with it. Only downsides are lack of pitch stability at high speeds and moreover the small payload area but i'm already thinking about a variant with the large B9 bay

Edited May 9, 2014 by DaMichel

[andqui]

I'm having a problem with using fins for roll control. When I put four fins on the bottom of my rocket, and then apply a roll command (Q or E,) the rocket begins to pitch or yaw as it rolls, as if there were some imbalance. I'm posting this here because this seems the most relevant mod out of all those I have installed- I'm also using RSS/RO.

thanks

[Boamere]

I doubt this will be answered, as it will probably be swept away by the sheer amount of comments but ; I keep getting Nullreference errors, which stop me from exiting/saving/reverting and I have no idea what is causing them, so I have decided to put my output log here (because this thread generally has quite a few people who are good with this kind of thing )

If you can figure out what is causing it, then thanks

http://www./download/44v85is1oc8yxnd/output_log.rar

[Boamere]

I'm having a problem with using fins for roll control. When I put four fins on the bottom of my rocket, and then apply a roll command (Q or E,) the rocket begins to pitch or yaw as it rolls, as if there were some imbalance. I'm posting this here because this seems the most relevant mod out of all those I have installed- I'm also using RSS/RO.

thanks

Do you have any asymmetrical parts on your rocket?

It might be that or it might be the fact that stock SAS isn't that good, and lets you tip

Edit: Your centre of mass could be too high up the rocket?

Edited May 9, 2014 by Boamere

[softweir]

Check that all four fins have the same FAR settings. If you moved them after placing them then the symmetry can be slightly broken, and updating the settings for one won't necessarily carry over to the others.

[ferram4]

@NJC2: I need the output_log.txt to figure out what's going on. Either another mod is interfering with the vehicle, you haven't installed FAR properly (there is only one copy of ModuleManager in GameData and all of its subfolders, correct?), or your tests have variables that are unaccounted for (for example, the pitch-up-at 200 m/s one, both planes were fully fueled when you did this (you used infinite fuel to remove that variable), and no CoM shift occurred at all in flight). Also, altitudes are not helpful, dynamic pressures and Mach numbers are, since those control aerodynamic forces directly.

If there are no mod interactions, then it might just be the changes in the physics between versions; they can change quite a bit as I remove inaccurate modeling and replace it with better models, and that changes the ideal vehicle design. In particular, it's now a lot easier to stall a plane, but it's also much easier to design the plane to not ever get trapped in a stall (by making the forward surfaces stall at a lower AoA).

@mcviscount: I installed all of them and could not reproduce an issue. Make sure that all your mods are up-to-date and that you are using the community hotfix for RemoteTech 2, and then submit a more detailed bug report with an output_log.txt and a description of what "breaks."

@andqui: Make sure that the payload is symmetrical and that there is nothing interfering with the fins. It is always possible that you have some type of inertial coupling going on, in which case, it's part of the physics engine and is realistic.

@Boamere: None of your errors are due to FAR; several are due to RPM related things, but I have no idea what starts them. In addition, you have 3 different versions of the OpenResourceSystem.dll loaded into your game; you may want to clear those out.

Make sure each and every one of your mods is up-to-date and make sure that you install them following the instructions exactly.