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

[Grease1991]

I have to say i feel a bit bad for Ferram4, I mean it's like heres an official update to Far for 1.2.2 and bam 1.3 
With that said I hope the fixes are minor on his end and i'll take it when he deems it ready. 

[Morse]

I want to take a dev-build for a spin. Is there some issues I should be aware of? Some particular use-cases where I should look for some weird behavior?

[TheRagingIrishman]

7 hours ago, Morse said:

I want to take a dev-build for a spin. Is there some issues I should be aware of? Some particular use-cases where I should look for some weird behavior?

https://github.com/ferram4/Ferram-Aerospace-Research/issues is generally a good place to look. If you find anything, add it.

[Skystorm]

I have a few questions regarding configuring a wing model to work with FAR.  On the github.com wiki it says:

    "FAR assumes the wing starts at the model origin. Therefore, any parts of the mesh over the y axis should be ignored."

Does it matter precisely where the wing mesh origin is located so long as the wing sits entirely on one side of the global Y axis or do I need to move the mesh origin so that it resides along the wing root in order to work correctly with FAR?

Here is a Blender image of the wing model.  I have overlaid a trapezoidal plane over the wing portion of the mesh in order to show the shape, lengths, and origin.

Although the wiki does not mention it, should I also be removing CoLOffset and CoPOffset properties from the PART itself?

I have noticed that some part configurations, particularly for FARControllableSurface, have transformName and/or rootMidChordOffsetFromOrig properties but their usage is not mentioned in the wiki.  When and how should these be used?  I'm guessing that transformName is just the same as the one from ModuleControlSurface.

What is the purpose of including the following line in a module manager configuration?  This line does not appear to do anything useful since for a @PART[] the module property is always "Part".

    @module = Part

Also, the two images on the wiki page in the Overview of Derivation section (at the top) appear to be broken links.

I appreciate any assistance that you may be able to provide.

[Gordon Dry]

Using the unofficial 1.3 build.

Does this exception mean there is an incompatibility with Trajectories and/or Deadly Reentry?

NullReferenceException: Object reference not set to an instance of an object
  at FerramAerospaceResearch.FARAeroComponents.FARVesselAero.SimulateAeroProperties (UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, Vector3 velocityWorldVector, Double altitude) [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARAPI.InstanceCalcVesselAeroForces (.Vessel vessel, UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, Vector3 velocityWorldVector, Double altitude) [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARAPI.CalculateVesselAeroForces (.Vessel vessel, UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, Vector3 velocityWorldVector, Double altitude) [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0 
  at Trajectories.FARModel.ComputeForces_Model (Vector3d airVelocity, Double altitude) [0x00000] in <filename unknown>:0 
  at Trajectories.VesselAerodynamicModel.ComputeForces (Double altitude, Vector3d airVelocity, Vector3d vup, Double angleOfAttack) [0x00000] in <filename unknown>:0 
  at Trajectories.VesselAerodynamicModel.ComputeReferenceDrag () [0x00000] in <filename unknown>:0 
  at Trajectories.VesselAerodynamicModel.isValidFor (.Vessel vessel, .CelestialBody body) [0x00000] in <filename unknown>:0 
  at Trajectories.Trajectory+<computeTrajectoryIncrement>d__47.MoveNext () [0x00000] in <filename unknown>:0 
  at Trajectories.Trajectory.ComputeTrajectory (.Vessel vessel, Trajectories.DescentProfile profile, Boolean incremental) [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

Spoiler

 

The game crashed by any unknown reason after I switched to each single Kerbal after landing on Earth, going on EVA, back to Tracking Station, recovering the Kerbal, back to lander, next Kerbal.
Each did collect samples, one planted a flag.

The last Kerbal was a tourist, couldn't go on EVA, so I went back to Tracking Station and - crash.
There is even not a trace of the crash in the output_log.txt and no crash dump in the KSP folder, but I found one in c:\Users\USERNAME\AppData\Local\CrashDumps\ ...

 

https://www.dropbox.com/s/paohf0bsr7xr397/2017-06-17-1 KSP.log.zip?dl=1

[TheRagingIrishman]

26 minutes ago, Gordon Dry said:

Using the unofficial 1.3 build.

If you are using the test build, all problems need to be reported as issues on Github (per @ferram4's wishes)

[undercoveryankee]

21 hours ago, Skystorm said:

What is the purpose of including the following line in a module manager configuration?  This line does not appear to do anything useful since for a @PART[] the module property is always "Part".

    @module = Part

In the really old days, before we had multiple PartModules and MODULE nodes, there were other modules that the "module" property could be set to. Most of these were migrated to be PartModules, but wings and control surfaces didn't get converted until the aerodynamics overhaul in 1.0. In the pre-1.0 world, setting "@module = Part" in the MM patch for FAR was how you disabled those parts of the stock aero system. Now you mostly see it because it's not hurting anything and it's not worth the time to clean up.

[dlrk]

On 6/17/2017 at 2:48 PM, TheRagingIrishman said:

If you are using the test build, all problems need to be reported as issues on Github (per @ferram4's wishes)

I replicated that issue and put it on Github. It doesn't seem to be causing any problems in KSP and TJ is still accurate

[the_machemer]

Sorry for the noob question, but how does one go about adding FAR's control surface/flap tweakables to other mod parts?

[Gordon Dry]

Just 45 minutes. Fresh! Testing on new session in a few minutes.

[RazorFang95]

On 6/9/2017 at 1:26 PM, capi3101 said:

That's comparable to my home box; no worries.

Did occur to me that I tested in the 64-bit version of KSP this morning. Will look into the combination of 32-bit KSP and Lewis to see if that makes a difference or not.

Any headway on my problem? Maybe I installed it wrong? 

[GrubbyZebra]

Had an issue this morning where I had a sock chute mounted to the top of my stack and it prevented the stack from launching (part was reduced in size with tweakscale). Not sure 100% it's a FAR issue, but googling to fix it seemed to indicate it was an old issue with tweakscale and FAR, replaced part with a stock mk16 and rocket flew not problem.

[damerell]

13 hours ago, fwdixon said:

Had an issue this morning where I had a sock chute mounted to the top of my stack and it prevented the stack from launching (part was reduced in size with tweakscale). Not sure 100% it's a FAR issue,

Besides the usual questions, which I daresay someone else will ask, this is easy to check. Remove FAR, does it still happen?

[GrubbyZebra]

3 hours ago, damerell said:

Besides the usual questions, which I daresay someone else will ask, this is easy to check. Remove FAR, does it still happen?

yes, downgrading FAR did not help, removing FAR did, not using a tweakscale chute at the top of the stack also fixed it. Something about tweakscale-FAR-real Chutes together was what was causing it, remove any one and the problem was fixed.....

[blowfish]

@fwdixon What do you mean "prevented the stack from launching" ?  Could you describe what you saw exactly?  Logs would be helpful as always of course.

[Guest]

52 minutes ago, blowfish said:

@fwdixon What do you mean "prevented the stack from launching" ?  Could you describe what you saw exactly?  Logs would be helpful as always of course.

I know this error. The tweakscaled part acts like it it is attached to a launch clamp. It will not move.

[raxo2222]

3 minutes ago, dundun92 said:

I know this error. The tweakscaled part acts like it it is attached to a launch clamp. It will not move.

It sounds like mass scaling issue between any 2 mods, that try to change mass of said part.

Sadly there is no fix for it, unless Squad does something about modifying mass by mods.

Edited June 25, 2017 by raxo2222

[bckspstuff]

Love the mod! Soooo much fun!

I had a few questions about how to add FAR support to custom parts.

1) Lifting Bodies

What is the correct way to configure parts that are intended to be used as lifting bodies?

I see that for the mk2 pods, you removed ModuleLiftingSurface and set minimum_drag, maximum_drag, and angularDrag all to zero but did not add FARWingAerodynamicModel. However, the mk1pod, Mark1-2Pod and all sizes of heatshield still have ModuleLiftingSurface and their original drag settings. Is this intentional? I was under the (perhaps mistaken) impression that ModuleLiftingSurface needed to be removed in all cases. Obviously the capsules fly just fine, I simply want to understand the best way to implement configs for making other capsules support FAR.

2) Gimbal increase (stockEngineGimbalIncrease.cfg)

What is the purpose of the patch that increases the gimbal range and sets the gimbalResponseSpeed?

My gut instinct is to nerf the change and/or remove it. Some of the parts I'm using already have higher gimbal ranges/speed. I wasn't sure if there was a reason FAR needed gimbals to have these settings that wasn't immediately obvious. I'm aware that SAS could use a better controller, but is there any other reason?

3) Propellers and FARPartModuleException

It's my understanding by looking at the configs that propeller and rotor blades should not be voxelized.

In a few cases, I noticed the blades were not voxelized, but the blade grips and rotor nut were. Is this ok? Should I add exceptions to make sure the other moving components of the rotor are also removed from voxelization?

[capi3101]

On 6/23/2017 at 9:15 PM, RazorFang95 said:

Any headway on my problem? Maybe I installed it wrong? 

My apologies; been busy. Unfortunately I've made no headway - home box CPU temp got up over 70C just idling the other day and I haven't had time to figure out why. Hoping it just needs a good dusting.

Wrong installation is a possibility, I suppose. Can you give me the full directory structure you've got leading up to the FerramAerospaceResearch directory? And forgive me - I've slept a bit since you first posted - but as I recall you were doing a vanilla install with FAR as the only mod, is that correct?

[RazorFang95]

2 minutes ago, capi3101 said:

My apologies; been busy. Unfortunately I've made no headway - home box CPU temp got up over 70C just idling the other day and I haven't had time to figure out why. Hoping it just needs a good dusting.

Wrong installation is a possibility, I suppose. Can you give me the full directory structure you've got leading up to the FerramAerospaceResearch directory? And forgive me - I've slept a bit since you first posted - but as I recall you were doing a vanilla install with FAR as the only mod, is that correct?

Correct. 

Computer > Local Disk (C:) > Kerbal Space Program > GameData > FerramAerospaceResearch.

The Total contents of my GameData folder is as follows 

FerramAerospaceResearch 

ModularFlightIntegrator

Squad 

ModuleManager.2.7.6

[capi3101]

1 hour ago, RazorFang95 said:

Correct. 

Computer > Local Disk (C:) > Kerbal Space Program > GameData > FerramAerospaceResearch.

The Total contents of my GameData folder is as follows 

FerramAerospaceResearch 

ModularFlightIntegrator

Squad 

ModuleManager.2.7.6

Looks like a correct install so far...

Contents of the FerramAersopaceResearch sub-directory?

[RazorFang95]

1 minute ago, capi3101 said:

Looks like a correct install so far...

Contents of the FerramAersopaceResearch sub-directory?

FerramAerospaceResearch >   

FARPartModule.cfg.                          CustomFARAeroData.cfg.               CustomFARAeroStress.cfg.             CustomFARGUIColors.cfg.               FARAeroData.cfg.                              FARAeroStress.cfg.                          FARAnimOverrides.cfg.                   FARGUIColors.cfg.                             FARPartModuleTransformExceptions.cfg.                                                  FARPM.cfg.                                        FARVoxelGeometryOverrides.cfg.  FerramAerospaceResearch.cfg.    speedometerReplacement.cfg.      stockEngineGimbalIncrease.cfg

          Plugins > PluginData > FerramAerospaceResearch > config.XML.

FerramAerospaceResearch.dll ferramGraph.dll       Scale_Redist.dll

          RealChuteLite > Sounds > sound_parachute_cut.wav                sound_parachute_repack.wav.

RealChuteLite.cfg

         Shaders > farshaders.ksp

          Textures > icon_button_blizzy.png.                      icon_button_stock.png.                    sprite_debug_voxel.png

 

I hope this is understandable. 

[SilverWolf]

Edit.

Edited June 26, 2017 by Verran
Error in method.

[Vladokapuh]

16 minutes ago, Verran said:

...

In all this time passed i however found out that doing opposite of what Ferram suggested works.
Aka, literally slam the plane hard into the ground at 150-200m/s, the harder you slam it, the more likely you are to succesfully land, dont ask me why, this USUALLY makes it work. This is a KSP issue, but i found that FAR somehow extrapolates it alot.

Edited June 26, 2017 by Vladokapuh

[Gordon Dry]

Hmm... scratches head...