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

[Wanderfound]

@Wanderfound: Yeah, there's no reason FAR should prevent that from loading. I suspect another issue on the user's end.

As for that odd interaction, that makes no sense: if both engines are producing the same amount of thrust in airbreathing mode than they will be applying the same amount of thrust. The only way this could be interacting is if there is some odd stock bug that you've run into. Also, your link is shortened and so it goes nowhere.

Gah, sorry: http://forum.kerbalspaceprogram.com/threads/90747-Kerbodyne-SSTO-Division-Omnibus-Thread?p=1374206&viewfull=1#post1374206

[darcgekco]

So I built this exact 1:1 f-22 with tweakscale and pparts/wings. Flies well, until I try to use the rudder for more than tiny deflections, in which case it rolls over super fast. Also had to clip two copies of the correctly sized tailfins together to get any semblance of roll stability, presumably because the whole fuselage is made out of wings

The other thing is, why are my pitch input derivatives negative? I can make them positive by swapping deflection direction on my elevators, which makes sense, but then I have inverted pitch control.

Any input on what I could do to stop the rolling when yawing issue would be much appreciated.

[NathanKell]

FAR doesn't support making fuselages out of wings. :\

[Kitspace]

Is there any sort of manual or wiki that would explain how the stability and simulation menus work and what their controls do?

[ferram4]

There is a link to the in-dev wiki on GitHub in the OP. There are also help buttons in-game. Most of the stuff can be found out by looking through aerodynamic simulation textbooks.

[Kulebron]

This question might have been made, but I can't google it out.

Is it possible to have FAR installed with atmosphere density closer to stock values, so that you still expend 4400 m/s to get to orbit?

[Rib]

Ah, apologies. I have just come back to playing Kerbal after a very long time and I had to update the game. I should have suspected Kerbal itself instead of Ferram.

[taniwha]

Kulebron: It's not the density, but the gross inaccuracy of the model used by stock drag. You will just have to get used to building smaller ships, or ship that go further.

[madadam]

Hey Ferram,

I downloaded the dev version of the plugin from github because I was having issues which it was supposed to fix (it did), but now the Stability Derivatives no longer work. When I click on the Calculate button it throws an exception:

NullReferenceException: Object reference not set to an instance of an object
  at ferram4.FAREditorGUI.CalculateStabilityDerivs (Double u0, Double q, Double M, Double alpha, Double beta, Double phi) [0x00000] in <filename unknown>:0 
  at ferram4.FAREditorGUI.StabilityDerivativeGUI (Boolean tmp) [0x00000] in <filename unknown>:0 
  at ferram4.FAREditorGUI.ActualGUI (Int32 windowID) [0x00000] in <filename unknown>:0 
  at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 
  at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 

[ferram4]

Well yes, that's why it's the dev version. I alreayd have that one fixed, but I haven't pushed that version yet.

[madadam]

Cool! Thanks.

[steve_v]

Well yes, that's why it's the dev version. I alreayd have that one fixed, but I haven't pushed that version yet.

Excellent! always nice to know I'm not imagining things

[nli2work]

how would I configure a part to have 0 drag in FAR? Custom classification exempt parts with certain part modules; is it possible to exempt parts based on part name or title? I'm asking because I can exempt FlagDecal; but that would exempt all command pods; instead of just the decal part that also has FlagDecal, and should be 0 drag instead of greeble drag type.

[Diazo]

Okay, this is a bug report. (The first post has a comment to "see the guide below to report a bug", but I can't find said guide so here we go.)

Issue: Sometimes after undocking, when holding down a mouse button, such as right-click to pan, the GUI windows in my AGX mod will vanish while said button is held down. Based on my investigation as detailed below, I have narrowed down what I believe is the cause in FAR and have a potential solution for you to look at.

Investigation: While I have not been able to replicate the error myself, the output logs have the following error at the time of the error. Note that I do not see any errors logged by AGX or any other mod at the time.

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 (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 

Output log from JefferyCor I am pulling this error from.

Note the last line where this error is happening on a call from the RenderingManager. I believe that this error is terminating the RenderingManager early this update frame and therefore the GUI windows for my AGX mod never draws and so I have people reporting this issue to me. Both FAR and AGX currently use RenderingManager queue 0. (I am moving AGX to a different rendering queue to hopefully work around this issue, but I don't know the RenderingManager well enough to tell if that will fix this issue.)

Tracking that code down shows that OnDestroy in FARControlSys is currently:

public void OnDestroy()
{
if (activeControlSys == this)
{
vessel.OnFlyByWire -= new FlightInputCallback(StabilityAugmentation);
}
activeControlSys = null;
}

Based on the out of range exception, I suspect it is the line removing the callback throwing the error as I do not believe an IF statement is capable of throwing that error.

As I read this, that means that a non-existent callback was attempted to be removed. I don't actually know the code to check for a callback's existence, but the following try-catch would work and still print the error to the error log, but not stop the RenderingManager update.

public void OnDestroy()
{
if (activeControlSys == this)
{
try
{
vessel.OnFlyByWire -= new FlightInputCallback(StabilityAugmentation);
}
catch(Exception e)
{
print("FARControlSys.OnDestroy Error: " + e);
}
}
activeControlSys = null;
}

I don't know if this is handling this problem correctly, but if the callback is not there to be removed, I don't believe the "error" of not being able to remove a non-existent callback being put behind a try-catch block is a problem.

D.

[ferram4]

@nli2work: There isn't a way to do that, simply because there are not any parts that shouldn't apply drag ever. The best way to get around it is to define your own FARBasicDragModel and set it's S (area) to 0, but make sure to set CdCurve, ClPotentialCurve, ClViscousCurve, and CmCurve to something non-null or else it will be cleared out as a "broken drag model."

@Diazo: I already fixed that issue in the dev build awhile ago.

[Diazo]

@Diazo: I already fixed that issue in the dev build awhile ago.

Alright, thank you for that.

Do you know if changing the RenderingManager queue AGX will work as a fix until the next version of FAR is ready to go? (Unity question, not FAR, but you know more about mod programming then I do.)

D.

[cxg2827]

Would anyone know how I can get Biconic/Triconic bodies to work with FAR/DRE? The issue I'm facing right now is that they tend to flip and go ass-first after it hits thicker atmosphere.

Also, one of the parts shows being Shielded when it shouldn't. Any clue how to fix this? The shells are made out of upper and lower portions

Javascript is disabled. View full album

[ferram4]

@Diazo: I have no idea to be honest.

@cxg2827: Flipping means that they're aerodynamically unstable, which implies that the CoM needs to be put further forward. As to the shielding error, I can look into it, but it's a very funky edge case caused by the fact that the parts aren't put together in symmetry, which makes determining the exact shape for shielding a great deal more difficult. It's really kind of disappointing it needs to be set up that way when the only difference between upper and lower halves is a texture that doesn't do anything.

[Jagzeplin]

no idea which mod causes this but since the after action reports say its due to aerodynamic stress i guess ill start here.... anyway i keep getting my wing control surfaces and ailerons snapping off any time i load a saved game or change focus and come back. its very annoying as it means i have to maintain focus on my spaceplane the whole time im flying it or all the means of steering it will break off

[Wanderfound]

no idea which mod causes this but since the after action reports say its due to aerodynamic stress i guess ill start here.... anyway i keep getting my wing control surfaces and ailerons snapping off any time i load a saved game or change focus and come back. its very annoying as it means i have to maintain focus on my spaceplane the whole time im flying it or all the means of steering it will break off

Might not be the culprit, but I recently had a "control surfaces ripping off in vacuum" issue. Turned out to be caused by an outdated version of the optional Mechjeb FAR plugin.

[Jagzeplin]

ooh i DO have the mechjeb FAR plugin so lemme remove that and see what happens...

[yohuan]

How would i un-nerf the B9 engines ? i had VTOLs that worked in stock but now they can barely get of the ground.

[Wanderfound]

ooh i DO have the mechjeb FAR plugin so lemme remove that and see what happens...

Sarbian has updated the FAR plugin so that it no longer happens, BTW.

[brusura]

On vessel switching, orbiting mun:

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 (wrapper delegate-invoke) Callback:invoke_void__this__ ()

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

here are some files: https://www.dropbox.com/s/m07mopc6hc6scwz/files.zip?dl=0

far v0.14.1.1

Edited September 8, 2014 by brusura

[Wanderfound]

Folks: I don't want to clutter up Ferram's thread by spruiking my designs here. However, I can't think of a more appropriate place to mention this.

For the 100th post on my design thread, I built an atmospheric trainer that was specifically designed to address the problem of people being scared away from FAR on the grounds that it's "too hard". Starting your flying practice with a hypersonic spaceplane makes about as much sense as putting a teenage learner driver in a race-tuned Ferrari.

Hopefully, this plane should provide a more user friendly and less discouraging introduction to realistic aero than the explosively unstable designed-for-soupmosphere things that most people seem to begin with.

See http://forum.kerbalspaceprogram.com/threads/90747-Kerbodyne-SSTO-Division-Omnibus-Thread?p=1401723&viewfull=1#post1401723 if you're interested.

(PS: Ferram, if this irritates you in the slightest, let me know and I'll delete this post)