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

[smunisto]

As far as my limited knowledge goes, FAR cannot adjust itself fully to any and all custom parts. These parts need specific strings in their configs, made by the modder himself, to accomodate for usage of FAR. 90% of the mods out there provide FAR compatibility already.

For example, I was a bit disappointed by Porkjet's refusal to implement FAR compatibility until he completely finishes his Spaceplane+ pack(as this can take from a month to infinity to do), but it is his decision and I respect it. In the meantime I have modified his parts to be "Parts", not "Winglets" and have removed the "winglet lift" from all of his parts.

I was even thinking I should make my own FAR configs, but it would be an impossible task, so I just use them for vertically launched rocket planes for now.

[NathanKell]

It's something the part maker (or anyone) has to do and is pretty simple, you just figure out the chord, area, and taper ratio IIRC.

[goldenpeach]

Is there a way to force a spoiler to go upward or downward when activated? It could help cancelling the pitching effect of the spoiler when they're activated.

Also, how can I make the spoiler to have a maximum angle of 90 degrees?

I see it is the case in the included ships(the airliner) but the only way I've found is to edit the save file(and it didn't worked on every parts).

[DivisionByZero]

Ok... I'm dropping kerbals left and right lately in 0.23.5. Did something between FAR and/or DRE change with 0.23.5? It seems a lot harder than just a few weeks ago with 0.23? It's possible just something about the ships I'm landing is the difference. Could it just be that?

[wasmic]

Alright, Ferram... remember that bug earlier with the AIES engine, where a single broken config made it not simulate drag on the rest of the vessel? It's scary how many mods have that bug with FAR. I'm currently betatesting the Aerojet Kerbodyne mod. A single part in that mod has a broken config, meaning that an entire rocket will start following stock drag rules. Another example is SDHI, where the docking port has something broken, which results in everything placed above the docking port not actually being simulated. Is this bug going to be fixed, so that even if FAR can't simulate for a single part, it will still simulate for the parts further down the craft tree?

[ferram4]

@DivisionByZero: FAR's drag properties got changed a little bit for 0.13, but that should be causing ships to burn up more. If that's not your issue, you're just flying differently.

@wasmic: The only parts that should be causing the issue should be parts with ModuleJettisons in the config that don't have fairings of any sort to jettison. There's not much I can do to get things to work after it throws an exception, that simply halts execution and there's not much I can do besides going an adding my own exception handling system to deal with this. Ultimately, I'm not too concerned, since this is a problem that should be solved on the part modder's side in that they should clean the junk out their configs, since unnecessary PartModules will slow things down a bit.

All of that said, all the tests I've done indicate that the upcoming version of FAR won't have that issue. Until then, remove the ModuleJettisons from the config file if the part doesn't have a fairing; it shouldn't be there anyway.

[DivisionByZero]

@ferram: Yeah, I'm having some over-heating issues which result in burn-up of the chutes. Is it also the case that different L/D ratios are going to have a larger effect now? I had some orbiters with science modules below them and these were coming to a stop more easily than a capsule+heat shield alone. It seemed like a disproportionate effect, but maybe my intuition is just plain wrong and sending the capsule alone in is just a lot harder than I am expecting. I was feeling like a n00b though with all these brave Kerbals dying on re-entry when earlier flights with what I'm thinking is a slight difference in L/D were coming in without a problem.

[ferram4]

You want to check the ballistic coefficient, which is a measure of how strong drag is relative to mass; lower means it will decelerate better. Anything above ~1000 kg/m^3 for BC is probably not going to come down properly, or will at least risk it heavily if it can't spend lots of time bleeding off speed high up.

You might just be too aggressive with the pods.

[Moon Goddess]

You know, I LOVE the idea of FAR, I so so want to use it, but I can't get anything more than the absolute simplest thing into orbit when I'm using FAR. I know I'm not a good pilot but wow.

[CoolBeer]

You know, I LOVE the idea of FAR, I so so want to use it, but I can't get anything more than the absolute simplest thing into orbit when I'm using FAR. I know I'm not a good pilot but wow.

You need to do the gravity turn in a totally different way(not that the "10km straight up, yank it to 45 degrees" is anything you can call a gravity turn), I usually start to pitch over when I'm going between 50 and 100m/s, I try to make it so I'm around 45 degrees pitched over at 10km and fully pitched over when I hit 45km apoapsis(which is around when I hit 30km altitude usually).

I also find it helps a lot with fins on the first stage and RCS thrusters on the last stage(I run my rockets without reaction wheels as I find them silly, but those can help as well).

-

Kolbjorn

[Amaroq]

@ferram: Yeah, I'm having some over-heating issues which result in burn-up of the chutes. Is it also the case that different L/D ratios are going to have a larger effect now? I had some orbiters with science modules below them and these were coming to a stop more easily than a capsule+heat shield alone. It seemed like a disproportionate effect, but maybe my intuition is just plain wrong and sending the capsule alone in is just a lot harder than I am expecting. I was feeling like a n00b though with all these brave Kerbals dying on re-entry when earlier flights with what I'm thinking is a slight difference in L/D were coming in without a problem.

Yeah, the plain old Mk1 w/integrated heatshield survives re-entry, but attached radial RealChutes burn up when they didn't previously. Not that that's "good" or "bad", but I was having the same "feeling like a n00b" feeling!

[ayana]

You know, I LOVE the idea of FAR, I so so want to use it, but I can't get anything more than the absolute simplest thing into orbit when I'm using FAR. I know I'm not a good pilot but wow.

The art of the constant gravity turn is just that, an art. But the advice getting posted here is good. Just use a rocket without any exposed flat surfaces for learning how to do it.

[phoenix_ca]

The art of the constant gravity turn is just that, an art. But the advice getting posted here is good. Just use a rocket without any exposed flat surfaces for learning how to do it.

Well, that or you can fiddle with TWR on the lower stages so it's a bit below 2, slap MechJeb on it, and then set an ascent profile starting the turn at 5Km (or even less) and then muck with it from there until the profile only has a very shallow turn in atmo, finishing the rest in space. Takes some finagling but I've had good results. Even just forgetting the autopilot and instead using the navball guidance is a boon, especially for newbies. I sure as hell got the hang of FAR a lot quicker being able to use it.

[flywlyx]

Hi, if there is anyway I could affect the center of lift? It always moves along x axis...

[Drew Kerman]

Yeah, the plain old Mk1 w/integrated heatshield survives re-entry, but attached radial RealChutes burn up when they didn't previously. Not that that's "good" or "bad", but I was having the same "feeling like a n00b" feeling!

If you weren't experiencing issues before then this may not help, but I was having trouble with RealChute radials burning up from the get-go and Starwaster came up with this fix for me, which I put into an MM script. Makes the RC radial heat up similar to other parts on the Mk1 capsule

@PART[RC_radial]
{
  MODULE
  {
    name = ModuleAeroReentry
    adjustCollider = -0.025
  }
}

[ferram4]

@Moon Goddess: Lower TWR. Smoother, earlier-starting gravity turn. Fairings. Tall rocket, not asparagus pancake. Fins. Pictures of problem vehicles are helpful here.

@flywylx: Well, that depends on what you're trying to do and what FAR modules you're trying to use for it, and what you're calling the "x-axis," since that could point in any direction. I need a more detailed explanation of what you want to do first.

[flywlyx]

@Moon Goddess: Lower TWR. Smoother, earlier-starting gravity turn. Fairings. Tall rocket, not asparagus pancake. Fins. Pictures of problem vehicles are helpful here.

@flywylx: Well, that depends on what you're trying to do and what FAR modules you're trying to use for it, and what you're calling the "x-axis," since that could point in any direction. I need a more detailed explanation of what you want to do first.

Thank you for your reply.

I am planing to achieve a part that could act as a wing, but the COL should in the middle. X-axis is the x-axis of the part.transform, once b_2 is positive value, COL appears at the left side.

[ferram4]

Well, that's because of the way that normal wing parts are set up. The only way for you to achieve what you want to do is to offset the part origin so that it is b_2 * 0.5 to the right of the center, and then shift the CoM of the part back to compensate. However, this won't work for stock winglet parts.

FAR currently doesn't currently support what you're trying to do, and likely will not ever do so because of the problems involved in trying to model multiple wings using the proeprties of one wing; you would be better served by splitting your wing design into multiple parts to achieve the goal.

[flywlyx]

Well, that's because of the way that normal wing parts are set up. The only way for you to achieve what you want to do is to offset the part origin so that it is b_2 * 0.5 to the right of the center, and then shift the CoM of the part back to compensate. However, this won't work for stock winglet parts.

FAR currently doesn't currently support what you're trying to do, and likely will not ever do so because of the problems involved in trying to model multiple wings using the proeprties of one wing; you would be better served by splitting your wing design into multiple parts to achieve the goal.

Understand, thank you for your help~

[ferram4]

Alright people, version 0.13.1 is out, fixing the EAS-Mach-Navball issue, the improper engine fairing issue, and marking a change in FAR's license, which is now GPL v3. Its source is also on Github now, so all glory to the octocat!

[NathanKell]

Hurrah! Thanks as always!

[Dirt_Merchant]

Weeeeee!!! Stoked!!!

[White Owl]

I loves me some EAS indication.

[AndreyATGB]

This sounds pretty stupid but even after reading on Wikipedia about EAS and what it's used for, I still don't understand why you guys wanted it so bad. How does it help during reentry or just in general compared to the traditional "surface" indicator?

[White Owl]

At higher altitudes the air is thinner, and the aerodynamic forces acting on the wings are weaker than the same airspeed at low altitude. Fly high enough, and surface speed doesn't tell you how much lift you can expect; no telling how close you are to stalling. In general, if my plane handles well at 100 m/s sea level, then it'll also handle well at 100 m/s EAS up at higher altitudes. (Big caveat that mach effects will make things different.)

As for usefulness in reentry, neither surface speed nor mach number tell me if my plane will have enough pitch authority and overall lift to climb up out of the too-hot air while I slow down. EAS does tell me this, as long as I already know at what airspeed my plane can maintain a given altitude.

Another practical use would be landing in some high mountains. Attempt the landing using the surface speed that worked at KSC at sea level, and there's a chance of the stall catching you by surprise. But if you know the EAS stall speed, it's always valid.