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

[Wanderfound]

@Ferram: ah, thanks a bunch that makes sense. That's a significant change from former versions ! I am open to that new challenge. More fuel transfers while airborne will be needed... Nice that we have that Goodspeed pump mod

For me the jet nerf just makes me take longer to achieve the same results, i understand the need of some for utter realism, but that's feeling artificial to me. It's still a space program for small green men, let's still have some fun, that's my take on it. If i want to play a flight sim there's DCS or X-Plane and Kerbal is nowhere near those (even with your wonderful mod).

Another side effect of the jet nerf is the runway is now a tad too short, and it amplifies the issues with landing gears going sideways because of Unity limitations.

Even with the nerf, you can still easily get both large and small jets up to extreme speeds:

And adding a small amount of rocketry will push those to utterly ridiculous speeds:

[Wanderfound]

Ferram: over on the Vomit Comet challenge, we're getting heavily inconsistent G readouts depending on whether they're measured by F3, navball or seismic/gravioli detectors. Which one is most likely to be giving an accurate measurement of what the airframes are actually taking?

[tetryds]

Ferram: over on the Vomit Comet challenge, we're getting heavily inconsistent G readouts depending on whether they're measured by F3, navball or seismic/gravioli detectors. Which one is most likely to be giving an accurate measurement of what the airframes are actually taking?

I always trusted the navball, but it's too limited.

The F3 reading seems to not update too often, aparently it picks one vaule every x ammount of time and/or averages, which requires consistent turns for good readings, and won't read peaks.

In that case, I think that the F3 readings are better, because even though peaks can destroy your aircraft, being able to hold the pull for longer means your craft is better and that is not just "luck".

And aparently it only saves data until the first time you access it.

Can someone test that and tell if it actually happens? (no time)

Edited September 11, 2014 by tetryds

[Wanderfound]

I always trusted the navball, but it's too limited.

The F3 reading seems to not update too often, aparently it picks one vaule every x ammount of time and/or averages, which requires consistent turns for good readings, and won't read peaks.

In that case, I think that the F3 readings are better, because even though peaks can destroy your aircraft, being able to hold the pull for longer means your craft is better and that is not just "luck".

And aparently it only saves data until the first time you access it.

Can someone test that and tell if it actually happens? (no time)

It doesn't wipe on accessing it, but it does wipe on quickload.

As mentioned in the thread over there, I think the F3 readout wiping after loading is an advantage. It'll stop someone throwing their plane into a suicide dive, screenshotting just before they die, then quickloading before cruising in to land. Something that proves that the plane survived uninterrupted from manoeuvre to landing is a good thing.

[Surefoot]

Even with the nerf, you can still easily get both large and small jets up to extreme speeds

I know, right, as stated it just takes more time. I am already around the 500 hours mark on KSP I get to mach 5.6 with my SR71-like design.

[Kitspace]

Is the transonic center of lift backward movement effect modeled exactly like it should be in real life?

[ferram4]

Exactly? Of course not; that would slow your computer to a crawl, and even then, the best simulations we have can't achieve that.

A decent approximation? Sure.

[madlemur]

Exactly? Of course not; that would slow your computer to a crawl, and even then, the best simulations we have can't achieve that.

A decent approximation? Sure.

Which is exactly how it should be modeled in real life.

[forsaken1111]

Which is exactly how it should be modeled in real life.

And today in the Kerbal News Network, chief sciencers have determined that the universe is indeed a simulation in progress on some unfathomable alien computer. Unfortunately that computer seems to have been constructed with substandard components, resulting in our universe offering inconsistent approximations of physics.

[madlemur]

Heh... I was being pedantic about "exactly" referring to how it should be modeled, not the model itself. As to why it should be modeled as a decent approximation rather than an exact replication, I think ferram explained it pretty well.

And it's still a damned sight better than stock!

[Camacha]

Sometimes only one of my flaps (or other part) will respond, leaving the other stuck in a certain position. The parts are symmetrically placed and both are influenced when editing. Only fiddling a bit with it in the SPH and replacing it seems to fix this. It this something I am doing wrong, a FAR thing or is it KSP?

[tetryds]

Sometimes only one of my flaps (or other part) will respond, leaving the other stuck in a certain position. The parts are symmetrically placed and both are influenced when editing. Only fiddling a bit with it in the SPH and replacing it seems to fix this. It this something I am doing wrong, a FAR thing or is it KSP?

When you set any part to action groups, then move them, the mirrored part won't have the action group, you need to set it again.

That is a VERY annoying stock bug.

[The Space Man]

I'm having a weird problem with the flight systems console, it's disappearing when a craft unloads as i go past the physics load range

I'm using the latest v0.14.1.2 from github!

BD Enemy Gun System Unloaded

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

NullReferenceException: Object reference not set to an instance of an object
  at ferram4.FARControlSys.StabilityAugmentation (.FlightCtrlState state) [0x00000] in <filename unknown>:0 

  at (wrapper delegate-invoke) FlightInputCallback:invoke_void__this___FlightCtrlState (FlightCtrlState)

  at (wrapper delegate-invoke) FlightInputCallback:invoke_void__this___FlightCtrlState (FlightCtrlState)

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

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

(Filename:  Line: -1)

NullReferenceException: Object reference not set to an instance of an object
  at ferram4.FARControlSys.StabilityAugmentation (.FlightCtrlState state) [0x00000] in <filename unknown>:0 

  at (wrapper delegate-invoke) FlightInputCallback:invoke_void__this___FlightCtrlState (FlightCtrlState)

  at (wrapper delegate-invoke) FlightInputCallback:invoke_void__this___FlightCtrlState (FlightCtrlState)

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

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

(Filename:  Line: -1)

NullReferenceException: Object reference not set to an instance of an object
  at ferram4.FARControlSys.StabilityAugmentation (.FlightCtrlState state) [0x00000] in <filename unknown>:0 

  at (wrapper delegate-invoke) FlightInputCallback:invoke_void__this___FlightCtrlState (FlightCtrlState)

  at (wrapper delegate-invoke) FlightInputCallback:invoke_void__this___FlightCtrlState (FlightCtrlState)

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

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

[Camacha]

Did anything change in the maximum stresses before aerodynamic failure between FAR version 0.10 and 0.14? I finally managed to transfer a craft by manually editing the craft file. Where I could push it right to the edge before, I now get a fairly consistent failure when I do that, it always seems to be the same fin and connection. I am convinced I am running the same mods for as far those are relevant, but I am uncertain in what way each changed.

I tried strutting the tail fins together and to each wing, but that seems to do little.

Edit: the whole craft seems to be a bit more twirly in turns, while the thing is pretty much a part for part rebuild. Not sure what is going on here.

When you set any part to action groups, then move them, the mirrored part won't have the action group, you need to set it again.

That is a VERY annoying stock bug.

Ah, I did encounter that somewhere else, I just did not realize it is the same issue. Thanks!

Edited September 12, 2014 by Camacha

[Volt]

I've caught me an NRE. Here's a sample from the log.

 
(Filename:  Line: -1)

NullReferenceException: Object reference not set to an instance of an object
  at ferram4.FARControlSys.StabilityAugmentation (.FlightCtrlState state) [0x00000] in <filename unknown>:0 

  at (wrapper delegate-invoke) FlightInputCallback:invoke_void__this___FlightCtrlState (FlightCtrlState)

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

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

(Filename:  Line: -1)

Look rotation viewing vector is zero

(Filename:  Line: 57)

ArgumentException: Value does not fall within the expected range.
  at ferram4.FARControlSys.OnDestroy () [0x00000] in <filename unknown>:0 

  at ferram4.FARControlSys.OnGUI () [0x00000] in <filename unknown>:0 

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at RenderingManager.OnGUI () [0x00000] in <filename unknown>:0 

(Filename:  Line: -1)

NullReferenceException: Object reference not set to an instance of an object
  at ferram4.FARControlSys.StabilityAugmentation (.FlightCtrlState state) [0x00000] in <filename unknown>:0 

  at (wrapper delegate-invoke) FlightInputCallback:invoke_void__this___FlightCtrlState (FlightCtrlState)

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

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

(Filename:  Line: -1)

Look rotation viewing vector is zero

(Filename:  Line: 57)

ArgumentException: Value does not fall within the expected range.
  at ferram4.FARControlSys.OnDestroy () [0x00000] in <filename unknown>:0 

  at ferram4.FARControlSys.OnGUI () [0x00000] in <filename unknown>:0 

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at RenderingManager.OnGUI () [0x00000] in <filename unknown>:0 

(Filename:  Line: -1)

NullReferenceException: Object reference not set to an instance of an object
  at ferram4.FARControlSys.StabilityAugmentation (.FlightCtrlState state) [0x00000] in <filename unknown>:0 

  at (wrapper delegate-invoke) FlightInputCallback:invoke_void__this___FlightCtrlState (FlightCtrlState)

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

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

(Filename:  Line: -1)

Look rotation viewing vector is zero

(Filename:  Line: 57)

ArgumentException: Value does not fall within the expected range.
  at ferram4.FARControlSys.OnDestroy () [0x00000] in <filename unknown>:0 

  at ferram4.FARControlSys.OnGUI () [0x00000] in <filename unknown>:0 

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at RenderingManager.OnGUI () [0x00000] in <filename unknown>:0 

This began to happen after I switched vessels during a FAR flight in progress. Every time I left- or right-clicked the whole stock UI would flicker. After a couple more vessel switches, the UI disappeared forever, never to return. That was an interesting landing, using mach number and AoA readouts with the NavUtils.

My notable plugins in use at the time were BDArmory (latest), Improved Chase Cam, and NavUtilities.

[Master Tao]

Volt,

The flickering UI bug is fixed in the latest dev build available on GitHub.

[NathanKell]

Yep, the latest dev release fixes a bunch of issues and has been rock solid for me (thanks ferram!)

[Volt]

Whoops! Alright, that's awesome. Does it fix any odd issues with ship stability too? I was dealing with one earlier today which is... difficult... to describe involving >360deg per second rates of roll when sideslipping.

[ferram4]

@Camacha: Well, yes. FAR v0.13 and lower didn't have aerodynamic failures beyond what could be applied to the stock joint system, which has been made too much with the 0.23.5 stock joint changes, and especially with KJR. You can go and disable them in the debug menu in the Space Center scene or change them to something else if you want.

@Volt: Well, it shouldn't change much physically. That sounds a lot like stupidly high dihedral effect with almost no yaw stability; make your vertical tail larger / give it a larger lever arm and reduce your dihedral effect with less-swept wings or some anhedral.

[Surefoot]

I noticed stock parachutes dont appear anymore in VAB or flight staging. Cant trigger them either. Reduced the mods to FAR and MM 2.3.5, 32 bit. Any idea ?

(edit) nvm, reduced it to mm 2.3.5, i'll see with them

Edited September 12, 2014 by Surefoot

[FennexFox]

My craft disintegrated at higher then 25km altitude. It was very fast indeed, but due to high altitude, Q was lower then 10,000 pa. Is it intended, or something like bug?

[tetryds]

My craft disintegrated at higher then 25km altitude. It was very fast indeed, but due to high altitude, Q was lower then 10,000 pa. Is it intended, or something like bug?

High angle of attack.

Nose down a bit more.

[Tygroux]

I'm trying my hand at SSTO spaceplanes and became pretty good at designing and piloting them... Except keeping both hands on the controller at all time at supersonic speeds to micro-correct continuously becomes tedious.

I tried to use Mechjeb to autopilot the long boring part of the flight, but it keeps murdering my planes by going crazy on the controls when I'm supersonic.

How should I go with that? I actually like my behemoths that takes 20 minutes to get into orbit, and another 20 minutes to come down, I just want to not have to babysit them all the time.

[tetryds]

I'm trying my hand at SSTO spaceplanes and became pretty good at designing and piloting them... Except keeping both hands on the controller at all time at supersonic speeds to micro-correct continuously becomes tedious.

I tried to use Mechjeb to autopilot the long boring part of the flight, but it keeps murdering my planes by going crazy on the controls when I'm supersonic.

How should I go with that? I actually like my behemoths that takes 20 minutes to get into orbit, and another 20 minutes to come down, I just want to not have to babysit them all the time.

How far behind is COA in relation to COM at supersonic?

Are you using low wings? and swept? or delta?

Post a pic of your aircraft, please.

It's pretty possible to tweak it so an SAS can take care of it, if even needed.

[Wanderfound]

I'm trying my hand at SSTO spaceplanes and became pretty good at designing and piloting them... Except keeping both hands on the controller at all time at supersonic speeds to micro-correct continuously becomes tedious.

I tried to use Mechjeb to autopilot the long boring part of the flight, but it keeps murdering my planes by going crazy on the controls when I'm supersonic.

How should I go with that? I actually like my behemoths that takes 20 minutes to get into orbit, and another 20 minutes to come down, I just want to not have to babysit them all the time.

A few points:

* Mechjeb is currently useless for spaceplanes because it isn't accounting for gimballing roll. It normally isn't this bad; before they introduced roll gimballing in .24, it was quite easy to fly to orbit by doing nothing by tweaking the pitch settings on Smart A.S.S. Surface mode.

* The Extended Trim mod helps a great deal; it allows you to "set trim to current inputs" with a single action group.

* It will of course depend on your definition of "behemoth", but 20 minutes is very, very slow. Small sporty things can hit orbit in about three minutes; serious cargo planes can do it in five to ten.

* With sufficient aerodynamic polishing, you can create aircraft stable enough to be flown hands-off at hypersonic speed. If you're really good, they can even do it at high levels of time acceleration.

* However, lacking that: vectored thrust covers a multitude of sins. Stick a few Vernors around the nose, a few more around the tail, and keep them toggled off until the plane starts to become squirrely. Flick them on when needed and they will greatly assist in keeping things on track. Also useful for stall/spinout recovery and deliberate aerobatic sillyness.