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

[BFGfreak]

FAR hates my rockets. Any rocket i build that is perfectly aerodynamic just likes to flip whenever i go to do my gravity turn at the start. It starts cartwheeling in mid air and it's really frustrating cause the rocket design seems fine. http://imgur.com/2wsKwVv

Just by looking at it, it looks like you might have a thrust to weight issue. When you launch it, does it look like a lumbering behemoth struggling to get airborne or does it go zipadeedoodah and it's off? The former is good, the latter isn't since you're most likely exceeding the maximum dynamic pressure your rocket can handle.

[BudgetHedgehog]

FAR hates my rockets. Any rocket i build that is perfectly aerodynamic just likes to flip whenever i go to do my gravity turn at the start. It starts cartwheeling in mid air and it's really frustrating cause the rocket design seems fine. http://imgur.com/2wsKwVv

Your design isn't fine. The payload looks way to light to justify such a big rocket under it. Wat's your TWR at launch? I've never had a need for those big SRBs, not even with the heaviest 3m payload. If you're too over powered, no wonder its flipping, despite it being aerodynamic.

Edit: ninja'd... Either way, your TWR should never really exceed 2.5 in atmosphere and should be at around 1.3 at launch. Any higher is not needed.

Edited April 13, 2014 by ObsessedWithKSP

[GentlemanJack]

Your design isn't fine. The payload looks way to light to justify such a big rocket under it. Wat's your TWR at launch? I've never had a need for those big SRBs, not even with the heaviest 3m payload. If you're too over powered, no wonder its flipping, despite it being aerodynamic.

Edit: ninja'd... Either way, your TWR should never really exceed 2.5 in atmosphere and should be at around 1.3 at launch. Any higher is not needed.

Took the SRBs off. Still does it. TWR without SRBs is 1.69. I'll try using a single engine instead of the cluster.

Edit: Seems that fixed the issue. Didnt know an overpowered rocket was a thing. Thought the more TWR you have, the better.

Edited April 13, 2014 by GentlemanJack

[ferram4]

@not-a-cylon: The best option would be define custom drag models for them using the documentation in the readme. I'll look into adding something to make it easier to deal with.

@a.g.: Primarily because the new size-3 decoupler counts as "physics insignificant" and I suspect that's on purpose, and that more and more parts will be declared physics insignificant to reduce the physics overhead. With that in mind, FAR has to start applying drag to physics-less parts (or more properly, to their parents), which means that there will be some hiccups as everything is suddenly accounted for.

@Motokid600: I haven't looked at it yet. If the parts are set up in any way similar to the way that Frizzank's are (in particular, the way the S-IVB is set up), there won't be much I can do, since that part will create a huge amount of drag if I don't define a nice special drag model specifically for that. The problem with part mods like that is that the way the parts are set up has too much of an effect on the drag properties, and modellers never make them like the stock parts are, they always combine things that should be separate together or separate things that should be together, making applying drag properties far more difficult.

I suspect I'm going to find a lot wrong with it, and besides, it won't be aerodynamically stable without the 1st stage. The configuration without the first stage was never intended to fly inside an atmosphere, so there's really no way to make it stable for Kerbin flight. For RSS, sure, but it's always going to be wrong for Kerbin.

@jrandom: The non-wing parts you have to change from "winglet" to "Part" so that FAR actually applies drag properties to them. The wing parts need to have modules defined like for the stock wings, which can be found in the ferramaerospaceresearch.cfg; since most of the parts seem to be the same shape you should be able to copy the modules over.

[localSol]

those are b9 puffers, or basically rcs that uses air instead of hypergolics or monoprops, lets you have attitude control on vtols [...] See: http://en.wikipedia.org/wiki/Hawker_Siddeley_Harrier#Controls_and_handling for more info on [...] these bleed air puffers IRL.

Regarding flight dynamics, the canards helped with mach tuck at supersonic speeds, but at subsonic speeds one solution was as good as another really.

Good to know! This article is about turbofan nozzles I think , I thought i had heard of compressed air systems too at one time, I wonder if a plane could compress air as it flew efficiently enough to refill air tanks for that purpose. Canards helping mach tuck? I will try this today too with a sort of wild x/cross wing type craft. B9's super tall landing gear are convenient. Spaceplane Plus parts look high quality, I would love an inline mk2 cockpit too, I don't know of any other available.

[thorfinn]

Primarily because the new size-3 decoupler counts as "physics insignificant"

What?

That looks to me one of the very last things that should be declared physicsless... (how does it even handle the joints to the stack then?)

[jrandom]

@jrandom: The non-wing parts you have to change from "winglet" to "Part" so that FAR actually applies drag properties to them. The wing parts need to have modules defined like for the stock wings, which can be found in the ferramaerospaceresearch.cfg; since most of the parts seem to be the same shape you should be able to copy the modules over.

Good, that means I'm on the right track. Thanks!

[a.g.]

@a.g.: Primarily because the new size-3 decoupler counts as "physics insignificant" and I suspect that's on purpose, and that more and more parts will be declared physics insignificant to reduce the physics overhead. With that in mind, FAR has to start applying drag to physics-less parts (or more properly, to their parents), which means that there will be some hiccups as everything is suddenly accounted for.

With more physicless parts they should finally fix mass accounting so they aren't effectively free for dV calculations. I've been thinking if it's possible to do externally, but it probably requires some really hacky things like a hidden 'child mass' resource added to the parent parts to do reliably. That is, you can change just the mass field of the parent, but some parts like probably procedural stuff, and KAS containers, already mess with it, and don't expect anything else to do it too.

[Motokid600]

Thanks for that breakdown Ferram. Brings alot to light for me. But holy crap that's ashame.

[ferram4]

@thorfinn: It works by having the physics-less part define one of the other parts as the body that handles the physics for it, and then any joints / forces that would be applied to the physics-less part goes to the other part instead. So when you connect two things using a cubic octagonal, the joints don't attach to that part, they simply use the cubic to determine which parts to actually attach to. It works surprisingly well.

@a.g.: I think we're going to discover that however this stuff works out, lots of mods are going to break in the process.

@Motokid600: I just did a flight-test of the Saturn V with FAR 0.13.1, and it flew just fine. The LEM fairing didn't do anything to protect the LEM, but it was still perfectly stable on the way up. There's nothing I can do about the S-IC's fins though, since they're built-in to the stage, so FAR can handle drag properties for those.

[a.g.]

@a.g.: I think we're going to discover that however this stuff works out, lots of mods are going to break in the process.

Squad can just add up the mass of non-physical children where they compute the total mass, which shouldn't break anything. What I'm thinking about is a mod that makes the mass of non-physical parts count by adding it to the parent in some way.

[DivisionByZero]

Ah-Ha! I figured out why I've felt n00bified of late: there's a "feature" with the Mk-1 pod and the 1.25m heat shield.

The heat-shield likes to attach almost flush with the capsule. Like in this image:

However, as you can see, the drag coeff. is WAY low.

If, however, you attach in an unaesthetic fashion like in this image:

it calculates a much more reasonable drag coefficient.

So, it turns out I was entering the atmosphere and heating up just fine. However, without a commensurate drag force, I'd just keep going way too fast and hold the heat for a really long time. Re-entry was pretty much impossible. I saved my ship already in flight by realizing I could probably use the built-in heat shield so I re-jiggered my staging and detached the extra heat-shield before re-entry on the last attempt. Sure enough, I was getting about 5g accel and decent drag coefficients. I noticed this by looking carefully at the FAR data during re-entry and seeing a really low Cd.

So, I don't know how intended this feature is or what the problem is with attaching the heat-shield, but I thought I'd let you and others know of this issue.

Is this a FAR issue or DRE? I'll cross-post on DRE if this belongs over there...

Peace.

Edited April 14, 2014 by DivisionByZero
is this FAR or DRE issue?

[NathanKell]

The problem with attaching the heatshield to the Mk1 pod is "you shouldn't." Because it already has a built-in heatshield.

[CoolBeer]

The problem with attaching the heatshield to the Mk1 pod is "you shouldn't." Because it already has a built-in heatshield.

Sure, but then the pod heats up and the chutes I tend to use(the radial ones) burn up, attaching an extra heatshield fixes that issue.

(This is not an issue from LKO, it did happen to Jeb coming in from the Mun, may he rest in peace).

-

Kolbjorn

[Aedile]

Sure, but then the pod heats up and the chutes I tend to use(the radial ones) burn up, attaching an extra heatshield fixes that issue.

(This is not an issue from LKO, it did happen to Jeb coming in from the Mun, may he rest in peace).

-

Kolbjorn

Add something under the chutes to take the brunt of the heat.

The second case is more of a FAR abuse, the same way the problem with adapters was.

Periapsis at 33km works nicely, the only issue is G when you need to deploy your chutes, so you need a drogue.

You can orient your pod in such a way, that you get a bit lift, and spend a bit longer between 45 and 31 km. Also make sure only one of your chutes is exposed, and rotate to change them.

Anyway, it is somewhat more difficult to aerobrake with a pod.

[DivisionByZero]

The problem with attaching the heatshield to the Mk1 pod is "you shouldn't." Because it already has a built-in heatshield.

Haha. Ok. That's a fair answer. It´s still unexpected behavior. At least, I didn't expect it.

[Starstrider42]

So, I don't know how intended this feature is or what the problem is with attaching the heat-shield, but I thought I'd let you and others know of this issue.

Is this a FAR issue or DRE? I'll cross-post on DRE if this belongs over there...

The problem with attaching the heatshield to the Mk1 pod is "you shouldn't." Because it already has a built-in heatshield.

"You shouldn't" is a bit harsh. Having a double heat shield is how I practiced getting survivable re-entries; it would have taken me a lot longer if I couldn't see how much extra ablative I used on a given trajectory.

However, there *is* an issue with all the heat shields in that, because they're so thin, it's easy to accidentally attach them via the bottom node instead of the top one. This happens with the 1-2 pod as well. But that's something best discussed in the proper thread...

[NathanKell]

Apologies, that was meant in a tongue-in-cheek manner rather than harshing, but it didn't quite come through. And as Starstrider42 says there *are* occasions when it makes sense.

[spookydonut]

How do I remove the info FAR adds to part menus? I can't use some functions because there's so many FAR lines!

[TheWampa]

How do I remove the info FAR adds to part menus? I can't use some functions because there's so many FAR lines!

You might want to upgrade to v0.13.1. Ferram accidentally left them enabled in v0.13.

[DivisionByZero]

lol. I didn't think it was harsh at all.

[sidfu]

i havea question FAR x13 and 13 didnt save anything to persistence file did they? cause game i started after .23.5 even after using the 13.1 had same problems with far acting up and or failing. but went and started a new game and error stoped.

before someone says its mod incoompatibliy i went thru and sptent 6 hours moving mods to a new install with far and worked fine its only when i load a save from a previous version of far this happens. if u want the saves tell me and ill rar them up for u to see if anything is happening

[ferram4]

Well, what do you mean by "FAR acting up and failing?" Does that mean that FAR didn't apply its aerodynamic model to all parts? Does it mean that it did apply aerodynamic properties to each part, but you think that they're wrong? More info would be much appreciated.

It's possible that something got saved improperly for a given ship, but I doubt that, since FAR does its best to not save anything to the current game state. Whatever the case, I'll need a copy of the output_log.txt in order to diagnose the issue.

[Starwaster]

lol. I didn't think it was harsh at all.

I call it tough love.

We love you guys and sometimes we gotta get mean to demonstrate our affection.

[sidfu]

this is the error i get over and over spammed

(Filename:  Line: -1)

NullReferenceException: Object reference not set to an instance of an object
  at FlightIntegrator.FixedUpdate () [0x00000] in <filename unknown>:0 

(Filename:  Line: -1)

NullReferenceException: Object reference not set to an instance of an object
  at Vessel.recurseCoMs (.Part part) [0x00000] in <filename unknown>:0 

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

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

and here is link to the uploaded output log. new saves are fine its any old save that used the .13 expermental and the .13 version

http://rg.to/file/da006ce9ef24fff7fd0ed7f91ddbcccf/output_log.txt.html