While testing some very old FAR craft I found some wings seemed almost permanently stalled. Adding some extra information to the right click menu, it seems that often there was asymmetric shielding, and that AoAmax for the stalling wing pieces could range from anything between ±40000 as a lower bound.

To verify this wasn't something weird lurking in the old craft files I based two new test craft of off the old "FAR Hypersonic Demon".

FARtest12.craft (no shielded wings, needs infinite fuel enabled)
FARtest13.craft (shielded wings)

Also, I found that actions such as deploying and retracting landing gear somehow affect the shielding of a wing piece completely separate from it.

I'd guess the odd stalling behaviour is related to the wing interaction code, as I couldn't see anything in there that differentiates between part of an actual wing, or a wing piece used as a structural piece.

Reproduction steps:

1. (Optionally) add some extra info to the right click GUI (see Gist)
2. Go to the SPH
3. Load the FARtest13 craft
4. Launch
5. Gain some speed
6. Observe that some wing pieces are almost permanently stalled / other weirdness

https://gist.github.com/mjn33/43d9f7bf048be8746533 (also contains a few experiments relating to shielding)
screenshot0.png
screenshot1.png
screenshot2.png
Player.log (don't think there's anything useful in there)

Please add support for raising / lowering Adjustable Landing Gear (https://kerbalstuff.com/mod/321/Adjustable%20Landing%20Gear) via the `Toggle Gear' button in SHP/VAB GUI.

Linux 64,
Starting from a clean installation from steam
Module manager installed,
FAR installed in full

Only logfile I could find on the linux 64 version, point me in the right direction if i'm wrong!
http://paste.ubuntu.com/8890770/

Replication; Select craft from hangar and launch OR select runway and launch prebuilt ship

Kind Regards

EDIT: Just realised it wasn't a true clean installation due to navhud being installed, redownloading now
EDIT 2: Unfortunately still there :(

additional log

http://paste.ubuntu.com/8891307/

I hit an interesting issue today where KSP hiccuped every second (pausing for a small but perceptible interval), and the debug log contained:

"Updating vessel voxel for VesselName"

every second.

A bit of experimentation showed this wasn't happening straight out of the VAB, but I could induce it on the vessels I was testing by deploying a deployable solar panel of the restowable type. To be clear, the lag and log spam continued even once the panel had completed its movement, even if the panel was then restowed.

I'll gladly provide any more information you need; but I don't know what that would be.

When deploying four communications satellites according to the standard procedure I got "Cannot deploy while stowed" when trying to activate anything on the satellites after the fairing has been deployed. It would make sense if they were actually still in the fairing, but they're completely free. They're strutted to the inside of the fairing, so I don't believe they've being knocked around in there.

Sometimes an odd antenna here or a solar panel there or miraculously the engine of the first sat will activate. It's inconsistent, but mostly failing over five launches.

Uninstalling FAR allowed me to deploy the satellites using the same craft on the first try.

It struck me, as part of the discussion on another issue, that constantly animated modules like rotating habitat sections will cause constant vessel voxelisation. Would it not be possible to suppress this in vacuum altogether?

While developing an air-breathing engine I ran into a problem with FAR:
The engine is surface-attached by a pylon and has no stack nodes. Its local axes are oriented as follows:

But being attached in default orientation to a plane in SPH it gets the maximum drag coefficient (as indicated by CdCurve in drag model debug printout). And rotating it so that its Z axis is collinear with the surface velocity gives the smallest Cd:
Drag in the default orientation
Drag with Z axis collinear with the surface velocity

I tested the issue with several other surface-attached parts with the same result.

Hello,

I recently ran into a problem using DCA on a rocket that had both control surfaces (for launch) and reaction wheels (for upper ascent). Once I started going supersonic, DCA nerfed my control inputs in proportion to the dynamic pressure -- except it reduced both the rocket fins (good) and the reaction wheels (bad). I ended up losing control of the rocket because I no longer had the control authority in the upper atmosphere to both correct my flight path and avoid straying too far from prograde.

IMO, a better strategy would be to compute the fraction of the unmodified torque that comes from control surfaces (if you need an algorithm reference, MechJeb already does similar calculations), then reduce the control input by the currently used penalty times that fraction. This should ensure that the corrected control authority is equivalent to only reducing the effect of control surfaces, and not of atmosphere-independent sources of torque.

All control surfaces become completely non-functional upon installation

First of all: Great work on the Euler update/remake of FAR ferram4!

Now to my suggestion:
Control surfaces which are set to follow AoA are fluttering erratically when the craft is not moving. This is not really a problem, but looks really bad.

An easy fix would propably be to disable AoA control under a speed of a few (like 1-5) m/s.

More of a visual enhancement than a bug, but hey, it's something which bothered me a bit.

Calling CalculateVesselAeroForces from the FARAPI appears to result in aerodynamic failures and exploding parts when trying to predict forces for a parked test vessel.

I was trying to predict forces for use in another mod, and found fins getting ripped off stationary vessels on the pad when requesting forces given a large velocity vector.

Don't rule out user error, but I do have a theory from tracing the code:

CalculateVesselAeroForces
-> Instance.InstanceCalcVesselAeroForces
-> SimulateAeroProperties
-> PrecomputeCenterOfLift
-> CalculateForces
-> DoCalculateForces (several overloaded calls)

This statement checks for aerodynamic failure - getting called on the simulation:

if (Math.Abs(Vector3d.Dot(scaledForce, forward)) > YmaxForce * failureForceScaling || Vector3d.Exclude(forward, scaledForce).magnitude > XZmaxForce * failureForceScaling)

If you enter a very-out-of-range altitude (e.g. 15000km) into the SPH stability analysis window, on hitting Calculate the FAR window goes blank and completely wedges itself. This is relatively easy to do by accident when you're used to the earlier version which wanted altitudes in metres, not km.

Exiting/reloading the SPH fixes it (until you do it again..)

Log says this:

[LOG 11:18:37.247] Mass: 18574.39061068
^MS: 90.60585
^MMAC: 2.41785793368632
[LOG 11:18:37.252] Cl needed: 0.230949963874938, AoA: 3.23974609375, Cl: 0.230949963874938, Cd: 0.0657364503604507
[LOG 11:18:50.995] SCREENSHOT!!
[LOG 11:18:50.995] SCREENSHOT!!
[LOG 11:18:52.581] Mass: 18574.39061068
^MS: 90.60585
^MMAC: 2.41785793368632
[LOG 11:18:52.582] Cl needed: Infinity, AoA: 0, Cl: Infinity, Cd: 0.339969381285907
[EXC 11:18:52.585] ArithmeticException: NAN
        System.Math.Sign (Double value)
        ferram4.FAREditorGUI.StabilityLabel (System.String text1, Double val, System.String text2, System.String tooltip, Int32 width, Int32 sign)
        ferram4.FAREditorGUI.StabilityDerivativeGUI (Boolean tmp)
        ferram4.FAREditorGUI.ActualGUI (Int32 windowID)
        UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID)
        UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style)
[EXC 11:18:52.613] ArithmeticException: NAN
        System.Math.Sign (Double value)
        ferram4.FAREditorGUI.StabilityLabel (System.String text1, Double val, System.String text2, System.String tooltip, Int32 width, Int32 sign)
        ferram4.FAREditorGUI.StabilityDerivativeGUI (Boolean tmp)
        ferram4.FAREditorGUI.ActualGUI (Int32 windowID)
        UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID)
        UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style)
[EXC 11:18:52.616] ArgumentException: Getting control 0's position in a group with only 0 controls when doing Repaint
Aborting
        UnityEngine.GUILayoutGroup.GetNext ()
        UnityEngine.GUILayoutUtility.BeginLayoutGroup (UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options, System.Type LayoutType)
        UnityEngine.GUILayout.BeginHorizontal (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options)
        UnityEngine.GUILayout.BeginHorizontal (UnityEngine.GUILayoutOption[] options)
        ferram4.FAREditorGUI.StabilityDerivativeGUI (Boolean tmp)
        ferram4.FAREditorGUI.ActualGUI (Int32 windowID)
        UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID)
        UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style)
[EXC 11:18:52.645] ArithmeticException: NAN
        System.Math.Sign (Double value)
        ferram4.FAREditorGUI.StabilityLabel (System.String text1, Double val, System.String text2, System.String tooltip, Int32 width, Int32 sign)
        ferram4.FAREditorGUI.StabilityDerivativeGUI (Boolean tmp)
        ferram4.FAREditorGUI.ActualGUI (Int32 windowID)
        UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID)
        UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style)
[EXC 11:18:52.647] ArgumentException: Getting control 0's position in a group with only 0 controls when doing Repaint
Aborting
        UnityEngine.GUILayoutGroup.GetNext ()
        UnityEngine.GUILayoutUtility.BeginLayoutGroup (UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options, System.Type LayoutType)
        UnityEngine.GUILayout.BeginHorizontal (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options)
        UnityEngine.GUILayout.BeginHorizontal (UnityEngine.GUILayoutOption[] options)
        ferram4.FAREditorGUI.StabilityDerivativeGUI (Boolean tmp)
        ferram4.FAREditorGUI.ActualGUI (Int32 windowID)
        UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID)
        UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style)
[.. etc etc ..]

Before:

After hitting Calculate:

Mod list:

✓ AdvancedFlyByWire-Linux 1.4
✓ DeadlyReentry v6.4.0
✓ FerramAerospaceResearch v0.14.5
✓ KerbalEngineerRedux 1.0.13.1
✓ ModuleManager 2.5.4
✓ PreciseNode 1.1.2
✓ ProceduralFairings v3.11
✓ StageRecovery 1.5.2.1_2
✓ Toolbar 1.7.7

Plane is entirely stock parts - I can provide the craft file if you need it but it doesn't seem too dependent on the exact craft.

FAR floods the log with updating messages in the VAB when I put a part in.
Testen on vanilla KSP 1.0.2 32 bit and FAR v0.15.1

Just a reminder to add the functionality to increase flap deflection above the neutral state. If possible, maybe change the units for deflection to degrees, just for added clarity when constructing / operating aircraft.

I have seen similar issues reported before on this platform.
When I go to launch a space ship, it instantly launches out into space, ripping it apart. To me it simply seems like the command pod is being teleported out of the solar system, but inspecting the logs I see otherwise.

I have tried not running it through steam and using the 64-bit versions (With and without launcher).

I have use both the latest official release and the git master.

FAR was the only installed mod, (aswell as the mod manager dll)

I am running manjaro linux 64 bit (Basically Arch linux).

I made a dual body aircraft for which the flight data gui shows a negative cl.
https://www.dropbox.com/s/iu4jloqi8b6aowz/dualbodybug.jpg?dl=0
https://www.dropbox.com/s/g519pevg3z50c54/Dual%20Body%20Glider.craft?dl=0
Accordingly, the shown L/D ratio is -1.42.

Judging by the glide path, i estimate that the plane actually has a L/D above 10.

If I set up a control surface as a spoiler with a negative deflection (e.g. I've put it under the wing to match a spoiler above the wing), then it appears to deflect correctly in the SPH when I do stability analysis, but it does not deflect at all when activated on the runway.

I've checked the action groups, and tried removing/readding them, and they all seem OK.
Changing the deflection to a positive deflection also works (in the sense that the spoiler moves when activated - it moves the wrong way, obviously!)

This worked OK in 0.14.4.

Craft file (should be stock parts only): https://www.dropbox.com/s/001riev9sdvtdz3/turbojets.craft?dl=1
The problem spoilers are the ones under the wings.
Spoilers are bound to the RCS action group as well as brakes.

Mod list:

✓ AdvancedFlyByWire-Linux 1.4
✓ DeadlyReentry v6.4.0
✓ FerramAerospaceResearch v0.14.5
✓ KerbalEngineerRedux 1.0.13.1
✓ ModuleManager 2.5.4
✓ PreciseNode 1.1.2
✓ ProceduralFairings v3.11
✓ StageRecovery 1.5.2.1_2
✓ Toolbar 1.7.7

Using the DLL found in the current repository from 9 days ago, when I pick up a control surface to attach it to my plane, I get the following in my error log:

NullReferenceException: Object reference not set to an instance of an object
at ferram4.FARControllableSurface.OnStart (StartState state) [0x00000] in :0
at Part.ModulesOnStart () [0x00000] in :0
at Part+��.MoveNext () [0x00000] in :0

To reproduce this, I click on SPH, choose the Probodobodyne OKTO2 probe core, then switch to the aerodynamics tab and click on the advanced canard. I do not have to place the part onto the craft, simply pressing the button in the part list is sufficient.

Things get worse if I choose a pWing control surface (using pWings 0.8.1):

NullReferenceException: Object reference not set to an instance of an object
at ferram4.FARControllableSurface.OnStart (StartState state) [0x00000] in :0
at WingManipulator.CalculateAerodynamicValues () [0x00000] in :0
at WingManipulator.OnStart (StartState state) [0x00000] in :0
at Part.ModulesOnStart () [0x00000] in :0
at Part+��.MoveNext () [0x00000] in :0

When I attempt to attach the pWing control surface, it doesn't "stick", and when I throw it away I get these errors scrolling on forever:

NullReferenceException
at (wrapper managed-to-native) UnityEngine.Component:InternalGetTransform ()
at UnityEngine.Component.get_transform () [0x00000] in :0
at ferram4.FARWingAerodynamicModel.WingExposureFunction () [0x00000] in :0
at ferram4.FARWingAerodynamicModel.RunExposure () [0x00000] in :0
at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
at ferram4.FARPartModule.ForceOnVesselPartsChange () [0x00000] in :0
at ferram4.FARGlobalControlEditorObject.LateUpdate () [0x00000] in :0

NullReferenceException
at (wrapper managed-to-native) UnityEngine.Component:GetComponent (System.Type)
at UnityEngine.Component.GetComponent[FARWingAerodynamicModel] () [0x00000] in :0
at ferram4.FAREditorGUI.Update () [0x00000] in :0
at ferram4.FAREditorGUI.OnGUI () [0x00000] in :0
at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
at RenderingManager.OnGUI () [0x00000] in :0

at which point the name field at the top of the interface disappears and clicking no longer works, necessitating an alt+F4 exit.

A full log is available at http://silenttosaturn.com/kspsave/farbug2.txt

I apologize if this is actually a bug in something else such as pWings and it just happens to become visible through log messages relating to FAR. As always, thanks for a great mod and your incredible patience when it comes to dealing with end users who don't always understand what's going on.

hi,

I don't know if this is of any help but I got a bunch of NullReferenceException's like so:

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: 4294967295)

what I did: crashlanded a plane and eva'd to take surface sample

Operating System: Fedora 21 (Linux) x86-64

Using FAR from the master branch, commit 065777e
Mods installed:

• ModularFlightIntegrator v1.0.0
• ModuleManager v2.6.3

Reproduction steps:

1. (Optionally) Disable aerodynamic failures
2. Go to the SPH and load the craft file at https://dl.dropboxusercontent.com/u/15422248/farbug3/Aeroscoop%20mk2.craft
3. Perform an AoA sweep on the craft, note the unusually high values for Cd, Cl, etc.
4. Launch vessel

Expected result:
The craft experiences a high but reasonable amount of lift / drag.

Actual result:
If aerodynamic failures are enabled, many parts will explode shortly after the
craft is loaded. Without aerodynamic failures, the craft visibly "twitches" and
enabling "Display Aero Forces In Flight" shows these phantom forces. From my
testing, the first version this is reproducible is at commit
fc4afd9.

Contents of Player.log here: https://dl.dropboxusercontent.com/u/15422248/farbug3/Player.log
Video displaying the issue here: https://dl.dropboxusercontent.com/u/15422248/farbug3/cut2.mp4

No? Comon!

As noted on the forums, as of v0.15.2 "Ferri" drag can still end up being 0 on valid vessels in odd circumstances. Logs so far have no indication of anything being wrong, nor has anyone been able to provide reproduction steps beyond "I launched a few rockets and it broke." Also, most of the installs this occurs on seem to have a large modlist, so mod interactions can't be ruled out. Finally, I've never been able to hit it myself, so I can't test this alone, unfortunately.

Indications are this is not related to #74, as that required a game restart to fix, while this only requires a scene reload. Further, none of the results seem to indicate a race / deadlock in the voxelization code, which would result in log spam (from the main thread repeatedly trying to queue a voxelization). There is no info on whether another vessel update (from decoupling or deploying gear or anything) fixes the issue.

This implies that there are three main possibilities for the error occurring:

1. The part mesh geometry is not transformed into the proper basis for voxelization. This would lead to the voxel being empty, and then everything breaking. The error would then be somewhere in GeometryPartModule or MeshData.
2. The cross-section data from the voxel is broken somehow. This would lead to the aero properties and section smoothing functions trying to work on something invalid. In that case, the bug would be in either VehicleVoxel.CrossSectionData() or in VehicleAerodynamics.GaussianSmoothCrossSections().
3. The aerodynamic property determination is broken somehow. Not sure how this would happen on its own, but if that's the case, then it would be in VehicleAerodynamics.CalculateVesselAeroProperties().

So, with that in mind, here's what needs to be done:

• Get a reliable test case and strict reproduction steps.
• Verify whether this bug is FAR alone or requires mod interactions.
• If it requires mod interactions, the mods involved.
• Narrow down the cause to any of the above. Suggestions for how to do that are welcome.
• Test solution to ensure that more bugs didn't slip in as a result.

Any help would be greatly appreciated, I'm somewhat at a loss here.

In every version of FAR after 14.7, there seems to be a @thumbs folder inside the Ships folder. It seems to be unintentional, but I'd like confirmation on that. (Got a report about this from someone in the CKAN forum thread).

Thanks

So you lost my pull request (#8) somewhere along the way ... I'd really love at least the FSairBrake stuff in for when B9 R5 is released.

Also, if FAR can properly account for the drag of extended/retracted FSwheel landing gear, this might be worth it too:

@PART[*]:HAS[@MODULE[FSwheel]]:FOR[FerramAerospaceResearch]
{
    @maximum_drag = 0
    @MODULE[FSwheel]
    {
        @deployedDrag =0 
    }
}

Or, if FAR cant understand the right drag there automagically, *= 0.2 like for FSairBrake.

The next version of RSS will contain pressure and temperature curves that approximate the International Standard Atmosphere. As the temperature at sea level of the ISA is 15 °C, the density is 1.2250 kg / m³, so the inverse density is 0.81632 m³ / kg rather than 0.8319 m³ / kg.
This affects the Frac SL Density display (tests by NathanKell yielded 1.008 at 65 m AMSL) and the EAS display.
invKerbinSLDensity should be initialised in a way that is consisted with the result of FARAeroUtil.GetCurrentDensity, possibly as

invKerbinSLDensity = FARAeroUtil.GetCurrentDensity(FlightGlobals.Bodies[1], 0);

Not really a bug, just a small annoyance

• Start craft in SPH
• Open FAR info window
• exit SPH
• open VAB
• FAR window is open with no apparent way of closing.

Obviously I can drop a pod & close the window, but it does take up a fair bit of screen estate.

I am very happy that you're using github and I wish all KSP adon devs were doing so, but it looks like there is a trend to publish all the binaries on curse. I must admit, this makes it really easy to stay up-to-date with all preferred mods because they allow "favourite" adons to be marked and downloaded in bulk (very useful when a new version of kerbal is released!)

FAR creates more and more buttons every time I go to the space center view, as the title says. This doesn't happen with any other mod (KIDS works fine, for example).

I'm using FAR 0.14.5 on Ubuntu 14.10 (64 bit KSP). Sorry if this is a known bug in either KSP or FAR, I didn't find anything about this.

I just tried this with a fresh install of 0.25:

A probe core + RT DP10 reflectron + some high powered engine. Accelerate under full power. Without Ferram, the reflectron survives mach 5 without problems. With Ferram, the reflectron breaks within seconds, usually around 130 m/s.

For comparison here is the craft file that I used. I did not use any other mods except for Remote Tech and Ferram. Versions were:
Remote Tech 1.5.1
Ferram 0.14.3.2
KSP 0.25-0 32bit Windows

Fresh install, fresh save and so on. Not sure what is causing this, but it is also happening inside fairings (in a different installation, I noticed the problem with inline fairings first). Would be nice to have a fix as these are my two favorite mods and I'd like to use them together.

In my FusTek Station Parts add-on, I have two parts with significantly high-poly meshes for EVA handgrips:

• Karmony Payload Bay Module
• Karmony Payload Bay Module Adapter

I've noticed recently that these parts cause KSP to momentarily freeze when manipulated in the VAB/SPH editor scenes. I narrowed the incompatibility down to FAR through a process of elimination.

I suspect that this lag due to these parts have the keywords "Payload" in them, leading FAR to attempt to treat them as aerodynamic payload shrouds (when in fact they aren't).

I tried using a ModuleManager patch (and deleting the Custom FAR Classification CFGs) to reclassify them as Cargo Bays, but the freezing while manipulated in editor persists.

As such, I was wondering if there was a way to write a ModuleManager patch to tell FAR exclude parts with certain names from being treated as PayloadFairing/CargoBay {}.

http://imgur.com/fJNDCbr

If I remove the Big-S "fin" it is working as expected again.

FAR floods the log with updating messages in the VAB when I put a part in.
Testen on vanilla KSP 1.0.2 32 bit and FAR v0.15.1

Log: https://www.dropbox.com/s/ou8kks1jp9vtdz4/output_log.zip?dl=0

Sorry, accidentally hit close on the other one.

Echoes from IRC: LiftSlope is just a division and a square root, it's not worth making that into a spline.
While previous tests by ferram4 seemed to suggest that the use of splines was significant for functions such as PrandtlMeyerMach, the most time-consuming bit in there is a couple of arctangents. The x86 instruction set has FPATAN, which is about as slow as a trig function (~100 cycles), so that could still be fast enough not to warrant loading a spline from memory.

It appears Unity's Mathf should be disposed of if performance is an issue. I would further suggest that all intermediate calculations be done in double: since this will be run using x86 rather than x86-64 all floating-point operations will go to the x87 instruction set, so using float requires constantly casting back and forth between double and float.

In any case, some profiling is in order.
If splines are indeed needed, they should not be uniformly sampled (and if we can use only static splines it's easier to optimise the error in Mathematica than to try to do so at runtime).

Operating System: Fedora 21 (Linux) x86-64

Using FAR from the voxelAeroPort branch, commit b9e604f.
Using a fresh install with no other mods.

Reproduction steps:

1. Go to the SPH
2. Load "FAR Colibri" from FAR v0.14.7
3. Launch & takeoff (I only used the rear engine)
4. Toggle landing gear

Expected result:
The landing gear retract and the aircraft flies normally.

Actual result:
The Cl value in the FAR Flight Data GUI will drop to a large negative value and the plane nosedives, it tends to sort itself out given time (although not always). This also happens if I open and close the cargo bay doors, and on the odd occasion causes rapid unplanned disassembly.

screenshot0.png (shortly after takeoff)
screenshot1.png (retracting landing gear causing nosedive)
screenshot3.png (recovered from nose dive)
screenshot4.png (happens again when deploying)
screenshot10.png (doomed)

Contents of Player.log here: https://dl.dropboxusercontent.com/u/15422248/Player.log

I'm not sure if this is a problem with FAR not updating the shielded status or DRE not doing something when parts burn up. I've already posted this issue for DRE, but I just realized it might be FAR. If it's not feel free to just close the issue.

What happens is when parts are in a cargo bay or Procedural Fairing and the bay or fairing burns up during reentry, the parts never get unshielded. I can reliably make everything else burn up our break off, then the shielded parts are immune to heat and have no drag. I've managed to have parts get a stable Kerbin orbit at 6000 meters because of the lack of drag.

When a new ship is loaded on the launchpad, when the physics starts the ship explodes. Interestingly even the launch clamps will teleport away from their positions on the launchpad. This happens with only Ferram Aerospace installed, without other modifications.

Having seen another issue with this mod fixed by running KSP directly rather than through steam, I tried invoking the executable directly and the issue went away.

... for obvious reasons.
The same holds for Assembly-CSharp-firstpass.dll and possibly UnityEngine.dll; add those to the .gitignore and remove them.

maintaining AOA in space is somewhat funny.

Looks like i put it in the wrong place. In the if (ToolbarManager.ToolbarAvailable) branch. Not good. Putting it right at the end seems to work.

private void DebugAndDataTab(GUIStyle thisStyle)
{
....
if (ToolbarManager.ToolbarAvailable)
{
...
}
FARActionGroupConfiguration.DrawGUI();
}

If a mod enabled and disables a model's renderer for effect purposes, such as Roverdude's warp drives and the drives warp bubble, the model is always included as part of the mesh geometry. This then screws up the resulting aero for what one would assume would be an aerodynamic rocket.
Here are a few images showing what I mean
Cross Section with bubble guide

Voxel Debug with bubble guide

Cross Section without bubble guide

Voxel Debug without bubble guide

Operating System: Fedora 21 (Linux) x86-64

Using FAR from the voxelAeroPort branch, commit d4e5d88.
Mods installed:

• ModularFlightIntegrator v1.0.0

Reproduction steps:

1. Go to the SPH
2. Load "FAR Firehound" from FAR v0.14.7 (it's got struts)
3. Launch & takeoff
4. Take to high speed and cause aerodynamic failure
5. Try and find one of the strut fragments

Expected result:
The strut fragment is slowing down due to drag.

Actual result:
The strut fragment appears to have no aerodynamic properties, opening up the FAR FlightData GUI shows NaN for Cl, Cd and Cy values. This issue isn't that serious, it is a bit odd though.

screenshot1.png (shortly after takeoff)
screenshot5.png (going fast)
screenshot6.png (aerodynamic failure)
screenshot7.png (found a strut fragment)
screenshot10.png (strut fragment still moving fast)
screenshot12.png (still moving fast)

Contents of Player.log here: https://dl.dropboxusercontent.com/u/15422248/farbug2/Player.log

When you like keep testing planes. After a while its behaviour totally changes from flying to exploding 😟. When I was looking what was wrong with my plane using the simulator. This error occured: http://hastebin.com/usorodeciq.avrasm

KSP info: Kerbal Space Program - 1.0.2.0 (LinuxPlayer) Steam
OS: Linux 3.19 Ubuntu 15.04 64bit
CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (8)
RAM: 23878
GPU: GeForce GTX 770/PCIe/SSE2 (2048MB)
SM: 30 (OpenGL 4.5 [4.5.0 NVIDIA 346.59])
RT Formats: ARGB32, Depth, ARGBHalf, RGB565, ARGB4444, ARGB1555, Default, DefaultHDR, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8

nuFAR's voxel debug shows struts that have been disconnected (due to removal or movement of the part they were connected to) as if they were still extended.

As you can see, the bottom right has a strut that is not connected. It used to be connected to the satalite that was above the command pod. Disconnecting the strut resolved this issue.

I was using stock struts and this issue is reproducible.

Using FAR downloaded under an hour ago (11 PM PST) from VoxelAreoPort

A bug was corrected in RealChute where the parachutes were being deployed too early - for example at 0.5kPa (26,500m) instead of .5atm (500kPa - 3,500m). It's still present in the version on Kerbal Stuff, but I don't know if it's been fixed on master - I'm going to have a look now, and see if I can create a pull request.

See RealChute commit ChrisViral/RealChute@a8b0653

During particularly long vessel loads, LateUpdate starts running before all of the parts and things are properly started. When this happens, FAR throws a NullReferenceException like this one:

NullReferenceException: Object reference not set to an instance of an object
  at SpriteText.UpdateMesh () [0x00000] in <filename unknown>:0 
  at SpriteText.set_Text (System.String value) [0x00000] in <filename unknown>:0 
  at ferram4.FARControlSys.ChangeSurfVelocity (SurfaceVelMode velMode) [0x00000] in <filename unknown>:0 
  at ferram4.FARControlSys.LateUpdate () [0x00000] in <filename unknown>:0 

This must be the speedometer assignment at line 1286 in FARControlSys.

The Exception spam prevents LateUpdate from properly concluding, which may have further ramifications for other code.

Unfortunately I cannot reproduce it at will. It happens every few hours of gameplay on average, almost always after undocking. While adjusting the camera angle with right-click-drag, all gui elements do not show up (looks like I had pressed F2 when I start the drag, and pressed it again when I stop dragging).

Output log available at http://silenttosaturn.com/kspsave/farbug.txt

Relevant excerpt:

ArgumentException: Value does not fall within the expected range.
at ferram4.FARControlSys.OnDestroy () [0x00000] in :0
at ferram4.FARControlSys.OnGUI () [0x00000] in :0
at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
at RenderingManager.OnGUI () [0x00000] in :0

I love this mod so much!

I would like to be able to chart out the terminal velocities for a spacecraft on various planets, at various heights. I assume that, in FAR, this depends on the rocket (unlike stock, which looks like it is a simple lookup table).

Is there any possibility of you providing a calculator to do this, or (possibly more fun!) a science experiment to measure it.

I'm working on a fix.

In Stock KSP, wings and control surfaces have additional info showing Lift rating. That info allows players to rate the effectiveness of the part, and therefore to choose what to use.
It could be debated how "Lift Rating" could resemble anything in reality; certainly FAR has a better approach with the surfaces actual characteristics.

Since a number of FAR versions (this issue is present at least since 0.14.1.1), installing FAR deletes the additional info.
It is evident that the additional info is associated to the stock module "ModuleControlSurface"; also, is noticed that with the "FerramAerospaceResearch.cfg" file (lines 758-761 in v. 0.14.3) that stock module is deleted, and proper data for each part is associated to modules "FARControllableSurface" or "FARWingAerodynamicModel".
However, even if FAR data is associated to a part, nothing is made visible to the player, who therefore loses the ability to rationally choose parts. Moreover, none of the stock KSP data with a part description is of help.

Even if it requires some more effort, it would be proper to allow some significant info to be visible to players from those FAR modules, and not only from the FAR analysis tool (that, for as helpful as it is, provides nothing about single parts).

I think FAR should install a flag. The image in the thread might make a good one :)