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

[BombastixderTeutone]

Hello everyone.

Is the displayed Mach Number in the FAR window the Number for Kerbin sealevel Athmosphere, or does it calculate the number with the athmosphere density your vessel is surrounded with?

[ferram4]

@NathanKell: Still haven't been able to see the behavior you're experiencing.

Let me see if I understand this correctly:

You set a full control input on some axis and hold that input.

The control surface deflects to that input.

It then snaps back to 0 deflection, contrary to control inputs.

In addition, no other control systems are interfering (no SAS or MJ), the focus has not been moved to a plugin window, away from flight controls and control input thingy in the bottom left corner displays a full control input. Further, thrust vectoring on engines still follows that control input.

All of this while you have stayed on the active ship, inside the atmosphere.

@BombastixderTeutone: It's Mach number at the altitude that you're currently at. FYI, the speed of sound doesn't depend on density, it depends primarily on temperature and gas constants / properties.

[KerbMav]

For FAR to not calculate drag for parts inside fairings (from ProcFairings in this case) does FAR only check for the procedurally created fairing part?

So, could I create an interstage fairing, put it aside, remove the lower fairing base, reattach the fairing and be happy?

Does a large nose cone shield parts below it (like a heat shield would in DRE) while steering inside the prograde marker?

[ferram4]

FAR only checks within the fairing shape for parts, so the fairing base isn't necessary if you can attach without it.

And nose cones don't do shielding like that at all. They simply act as standard parts, like anything else. If they did anything like that your rocket would become horribly unstable since the only drag applied would be that of the nose cone, well ahead of the CoM.

[9911MU51C]

Just letting you know this mod is not compatible with the ANVIL CORE mod fairings, and the engines tend to make rockets a bit screwy also (http://kerbalspaceprogram.com/anvil-rockets/)

[BudgetHedgehog]

Just letting you know this mod is not compatible with the ANVIL CORE mod fairings, and the engines tend to make rockets a bit screwy also (http://kerbalspaceprogram.com/anvil-rockets/)

Or rather, Anvil Rockets is incompatible with FAR. Seeing as FAR automatically checks part names for words like 'fairing', 'bay', that kind of thing, if the part name doesn't have it, FAR won't treat it as such and parts inside the fairings will not be shielded. I don't know what the setup for the actual fairings themselves is, I think they need to have a FARDragModelDefault module or something applied to them. Ferram can be more precise.

[NathanKell]

9911MU51C: I think you will find (1) that if a modder titles their fairing parts "fairing" or "shroud," FAR will detect them automatically, and that (2) that's probably because the modder didn't assign proper-size attach nodes (and .23.5 means that everyone has to do that now). It ain't FAR.

[taniwha]

This is a short video I recorded demonstrating FAR's lifting body support... and its consequences (this is one reason I consider using stock aerodynamics to be cheating).

[phoenix_ca]

You can't cheat in a single player game. That comment is equivalent to a reversal of the holier-than-thou MJ comments. People using stock aerodynamics aren't hurting you or anyone else through dishonest action. Why would you then say they are cheating you? Because that's what cheating is. It's something done in relation to others.

[taniwha]

phoenix_ca: actually you very much can cheat in a single player game: you cheat yourself. But how big of a deal this is very much depends on many things. I'm actually not particularly concerned about how others play, but for me it is a matter of personal integrity to play with as accurate physics as possible.

As for MJ, since you bring it up, I don't consider it to be cheating. At most, it's a different play style (mission control vs piloting). Heck, I love using MJ's docking AP to allow multiple tugs to operate at once (particularly nice when the frame-rate is around 2fps).

[phoenix_ca]

No. Your implied meaning of the word "cheat" is wrong. For this I refer to the only prescriptive English dictionary: http://www.oxforddictionaries.com/definition/english/cheat?q=cheat

Note that all examples refer to cases of one person cheating to gain unfair advantage over another. That is the very definition of what it is to cheat. It's to do something dishonest to gain advantage over someone else.

So, in the case of your post, simply not using FAR's aerodynamic model and instead using that of the stock game is not cheating. Maybe, at most, you could suggest that such a person is depriving themselves of a "full" experience, whatever you might consider that to be, but that is highly, highly, subjective. The notion of cheating is not subjective, because it is used in context of an unfair advantage being gained through dishonest/deceitful means over another person, where a fair playing field, as it were, was expected. By saying that someone simply not using FAR is therefore cheating is wildly inaccurate. Hell, you could say the very reverse, that using FAR is actually "cheating" because it significantly reduces delta-v necessary to reach orbit, and be just as wrong. For someone to cheat, there had to be established rules that that person is breaking in order to gain unfair advantage over other persons. An analogy: An athlete who arranges that their weights be replaces with look-alike versions that are lighter in a weightlifting competition, such that their recorded lift was in reality less than the weight recorded, is cheating. A person who does the very same at home outside that context, is not cheating. Maybe they're being a little silly yes, by patting themselves on the back for lifting fake weights, but they are not cheating. Depriving themselves of more meaningful exercise or a particular accomplishment through honest means, but not cheating.

The notion of cheating in KSP should only be brought-up in relation to challenges or competitions where two (or more) persons directly compete against each other. Then it may be accurate to assert that one person using FAR, or not, is cheating, especially if the rules of such a competition or challenge explicitly prohibit, or require, the use of FAR, respectively. Outside of that context, anyone claiming that anything is "cheating" doesn't know the meaning of the word, and/or is not articulating their meaning adequately.

Edited April 23, 2014 by phoenix_ca

[Read have Read]

The Long Telus Mobility bay ladder is generating 90kN of drag at mach 1.5, while the much larger surface mount ladder above it only generates 20kN of drag. In my opinion the ladder stowed away in the body of the air craft shouldn't generate drag at all, while the surface mounted ladder could generate some.

the surface ladder as much drag as the leading edge flaps, or canards, or nose, and I can live with that if that is expected behaviour, but the undeployed ladder is generating as much drag as the main wings.....

Edited April 24, 2014 by Read have Read

[ferram4]

@Read have read: Unintended behavior, caused by FAR having to apply drag to parts that previously hadn't had drag as a result of how many parts got physics turned off in the 0.23.5 update. The current dev build on GitHub does have a fix though.

[Malcolm182]

@NavyFish: More gets saved in the craft file than really should. So the MM file updated the properties of all the parts that will be added in the future, but not any of the ones added in the past. Any crafts where you've had this problem, swap the engines out and it'll go away since you'll clear all the problem data out of the craft files.

@Malcolm182: So you make a full deflection, you hold the deflection (and the control indicator in the bottom left corner of the screen continues to show a full deflection), but without messing with anything else on the screen (no other windows, mods or anything else that would prevent inputs from going to flight control), the control surface deflection zeroes out? I've attempted to reproduce this, but have done so unsuccessfully; all of my tests had full deflection maintained for as long as I chose, until I did something that caused focus to shift from flight controls and into another window.

whaaw: Because gravity tends to pull things towards the ground, so if the rocket ends up offset a little bit on the pad, it will fall over.

Of course, that's not the question you're asking, is it? You're asking, "why does my rocket lose control and flip around in the middle of flight?" or more simply, "why is my rocket aerodynamically unstable?" The answers, in no particular order, are:

1. You're overspeeding and aerodynamic forces are overpowering thrust vectoring control. Reduce TWR to ~1.2 - 1.6 compensate.\
   
2. You're sending the rocket sideways at a very high AoA. This will make the rocket unstable; gentle gravity turn, keep the rocket pointed prograde, starting shortly after getting off the launch pad, not go up 10km and yank sideways.
   
3. You've attached something really draggy to the top of the rocket and have a relatively streamlined rear end of the rocket. Shift more mass towards the top of the rocket and more drag / lift towards the back.
   
4. You're staging in the lower atmosphere, and while your rocket's configuration with the first stage was stable, without the first stage it is unstable.
   
5. You have a really, really tall first stage (relative to the rest of the rocket) that causes the CoM to shift backwards after the first bit of fuel is burned, making the rocket less stable.
   

Well sorta. i was wrong b4 physically the control surfaces stay deflected its only visual. but yeah thats what happens. (i have MJ but as u can see its not even installed on the craft, and i also have not turned off the roll on the surfaces)

http://postimg.org/image/vt2oynst1/

Edited April 24, 2014 by Malcolm182

[KerbMav]

While I am at work and unable to upload my craft file (gladly the stockiest design I made), do any Airbenders have some input to my aircraft with a hypersonic washing mache drive?

After going >~300m/s at ~10km it starts to get unstable and finally tumbles on every axis.

Fun Fact: With a less rigid/bendy tail construction it almost managed to reach orbit - but this was with active torque in every pod.

Using: FAR, KIDS, DRE, HotRockets

[whaaw]

@NavyFish: More gets saved in the craft file than really should. So the MM file updated the properties of all the parts that will be added in the future, but not any of the ones added in the past. Any crafts where you've had this problem, swap the engines out and it'll go away since you'll clear all the problem data out of the craft files.

@Malcolm182: So you make a full deflection, you hold the deflection (and the control indicator in the bottom left corner of the screen continues to show a full deflection), but without messing with anything else on the screen (no other windows, mods or anything else that would prevent inputs from going to flight control), the control surface deflection zeroes out? I've attempted to reproduce this, but have done so unsuccessfully; all of my tests had full deflection maintained for as long as I chose, until I did something that caused focus to shift from flight controls and into another window.

whaaw: Because gravity tends to pull things towards the ground, so if the rocket ends up offset a little bit on the pad, it will fall over.

Of course, that's not the question you're asking, is it? You're asking, "why does my rocket lose control and flip around in the middle of flight?" or more simply, "why is my rocket aerodynamically unstable?" The answers, in no particular order, are:

1. You're overspeeding and aerodynamic forces are overpowering thrust vectoring control. Reduce TWR to ~1.2 - 1.6 compensate.\
   
2. You're sending the rocket sideways at a very high AoA. This will make the rocket unstable; gentle gravity turn, keep the rocket pointed prograde, starting shortly after getting off the launch pad, not go up 10km and yank sideways.
   
3. You've attached something really draggy to the top of the rocket and have a relatively streamlined rear end of the rocket. Shift more mass towards the top of the rocket and more drag / lift towards the back.
   
4. You're staging in the lower atmosphere, and while your rocket's configuration with the first stage was stable, without the first stage it is unstable.
   
5. You have a really, really tall first stage (relative to the rest of the rocket) that causes the CoM to shift backwards after the first bit of fuel is burned, making the rocket less stable.
   

thanks for your answer i managed to get into orbit now:-)

but i have another bug found on my rockets. Sometimes my winglets do strange behavior on vessel load. i put 4 winglets with symetry mode on the bottom of my rocket. sometimes two of them go full left after vessel loading. when i lunch the rocket it goes wild no chance to controll it.

then i restart ksp same rocket same save no problem, everything is running. then do another restart an i got the strange behavior again. after 10 ksp restarts i can say its completly rondom failure that happens to me. somtimes i can restart 5 times and everything is good, somtimes i restart ksp and i get everytime this fail. dont see anything in the logs.

i only use the clouds mod and interstellar. my rocket contains no mod parts at this moment.

Edited April 24, 2014 by whaaw

[phoenix_ca]

Try using Kerbal Joint Reinfircement. This could be strangeness caused by physics loading. KJR ramps physics forces on load so it's less drastic and less prone to explodifying things.

[ferram4]

@Malcolm182: I actually just fixed that bug last night in my dev build. So what's happening is that the part's you're looking at still use the old Part type ControlSurface for non-FAR aerodynamics; FAR zeroes out the lift and drag parameters to be sure, but the Part type is unchanged. The ControlSurface code ends up setting the control surface's orientation every frame; FAR only sets it if it changes and then leaves it untouched. So what happens is that you'll see the control surface deflect so long as it's moving, and then when it stops it will snap back to 0, thanks to the ControlSurface code. Fortunately, it was easy to set up a ModuleManager line to fix that:

@PART
[*]:HAS[#module[ControlSurface],@MODULE[FARControllableSurface]]:FOR[FerramAerospaceResearch]
{
    @module = Part
    @maximum_drag = 0
    @minimum_drag = 0
    @angularDrag = 0
    @dragCoeff = 0
    @deflectionLiftCoeff = 0
}

You can drop that into your config and it should work. If you're not using ModuleManager 2.0.3, get rid of the :FOR[FerramAerospaceResearch] part. Issue will be removed.

@whaaw: Are you leaving any of the FAR control systems on? Keep trying to reproduce the issue, and document everything about what you're doing, like whether you go straight to the Launchpad or head through the VAB, whether it happen after you revert to launch, if you use a mod to skip the Space Center entirely. A seemingly random bug usually means that there's a variable you're not controlling for.

Make sure to post a copy of the output_log.txt from KSP_Data when that happens, so if there's anything really breaking in the code it can be traced back to the source.

[Malcolm182]

@Malcolm182: I actually just fixed that bug last night in my dev build. So what's happening is that the part's you're looking at still use the old Part type ControlSurface for non-FAR aerodynamics; FAR zeroes out the lift and drag parameters to be sure, but the Part type is unchanged. The ControlSurface code ends up setting the control surface's orientation every frame; FAR only sets it if it changes and then leaves it untouched. So what happens is that you'll see the control surface deflect so long as it's moving, and then when it stops it will snap back to 0, thanks to the ControlSurface code. Fortunately, it was easy to set up a ModuleManager line to fix that:

@PART
[*]:HAS[#module[ControlSurface],@MODULE[FARControllableSurface]]:FOR[FerramAerospaceResearch]
{
    @module = Part
    @maximum_drag = 0
    @minimum_drag = 0
    @angularDrag = 0
    @dragCoeff = 0
    @deflectionLiftCoeff = 0
}

You can drop that into your config and it should work. If you're not using ModuleManager 2.0.3, get rid of the :FOR[FerramAerospaceResearch] part. Issue will be removed.

@whaaw: Are you leaving any of the FAR control systems on? Keep trying to reproduce the issue, and document everything about what you're doing, like whether you go straight to the Launchpad or head through the VAB, whether it happen after you revert to launch, if you use a mod to skip the Space Center entirely. A seemingly random bug usually means that there's a variable you're not controlling for.

Make sure to post a copy of the output_log.txt from KSP_Data when that happens, so if there's anything really breaking in the code it can be traced back to the source.

thx its working

[crimsonknight3]

Hey guys a quick question, I am using FAR and Deadly re-entry, fun stuff I know but I am all of a sudden having quite an issue landing even the simplest craft on kerbin. First I used my usual descent path, can't tell you to be exact but it is usually quite steep... The heat shield seems to generate almost NO drag, and it takes A LONG time for the drag to build up so that by the time the drag builds to around 15kn the craft has already crashed into the ground, So I tried a very gentle descent to build up as much drag as possible, started from 150km and set periapsis to 30km, that time the shielding couldn't take the heat and blew up then the rest blew up from heat, third time I tried again from 150km and set periapsis to 15km, this time it did slow down but was still going at around 1600m/s when entering the lower atmosphere, the heat shielding blew up THEN i noticed whats been happening! The heat shield generates almost no drag, and the 2 mystery goo containers apparently generate 20kn each.

The reason my whole craft is exploding and I can't seem to land the ship is

A. The shielding isn't generating enough drag

and B. When the shielding explodes, the shock from going from almost no drag, to the drag of the mk1 causes the G forces to explode everything...

So is this an issue I need to get fixed on FAR's end or on DE's end?

Thanks a bunch

[ferram4]

Let me guess, something like this? You shouldn't have a heat shield attached to the Mk1 pod, it already has a built-in one.

[crimsonknight3]

Let me guess, something like this? You shouldn't have a heat shield attached to the Mk1 pod, it already has a built-in one.

Yeah that probably is the issue, I have it attached too flush (Just checked).

Also, for "Shouldn't have a heat shield attached", IF I DIDN'T attach a heat shield, my Mystery goo pods always explode, so even though the pod itself is fine, my science would be gone and I don't know how to get around it other than by attaching a second shield.

Thanks for the quick reply

[ferram4]

You've got a Kerbal on board, yes? Get out of the capsule, get next to the goo, right-click, take data. Return to capsule, take data in there. Return capsule without goo. Profit.

[crimsonknight3]

You've got a Kerbal on board, yes? Get out of the capsule, get next to the goo, right-click, take data. Return to capsule, take data in there. Return capsule without goo. Profit.

Can you store more than one goo experiment on board? I knew you could store more than one eva report, and surface sample but only one crew report.... That is a good idea though, but saying that, I have just designed an extra final stage. Final 3 stages = de-orbit fuel and engine, then a "science capsule" which has its own shield and has all the science equipment attached, then just the pod. Use a mod that allows for timed action group triggers and use real parachute mod so when I eject the engines then the "science capsule" the parachutes arm themselves, then trigger at the correct altitude (use lazor purely to prevent the science capsule from unloading so the chutes still release

[ferram4]

You can store multiple types of each experiment, so long as they are from different situations. You can't store two instances of Goo Low Kerbin Orbit, but you can store Goo Low Kerbin Orbit and Goo High Kerbin Orbit.