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

[kbios]

7 hours ago, Gordon Fecyk said:

Have you submitted this to ferram4's project page on GitHub as an issue?

I can't reproduce the problem, but it might be you're using a different build than me or you're using a different version of Module Manager or Modular Flight Integrator. I have Module Manager 2.7.5.0, Modular Flight Integrator 1.2.3.0, and finally the FAR DLL version is 0.15.7.2 but this is the one meant for KSP 1.2.2 and the version number doesn't mean much in this case... I forgot when I put it in there but my Created date says 25 JAN 2017.

So, the only difference was that my Modular Flight Integrator was slightly older than yours, but I tried again with the latest version and the issue persists. I've opened an issue here

[Draakon]

23 hours ago, Volatar said:

You really shouldn't be using a hidden dev build of a mod if you are new to the game.

Well, i don't wan't to choice between 1.2.2 mods and good aerodynamics (really, I maybe not good in rocket science but I am marginally better in aerodynamic and when proper designs just didn't work while truly ridiculous ones somehow valid i feel sad).

[Volatar]

8 hours ago, Draakon said:

Well, i don't wan't to choice between 1.2.2 mods and good aerodynamics (really, I maybe not good in rocket science but I am marginally better in aerodynamic and when proper designs just didn't work while truly ridiculous ones somehow valid i feel sad).

Ok yeah, I can definitely understand that. Hope you don't have any issues. Have fun.

[joebopie]

After installing this from the Dev version from Github it seems to have broken B9 procedural wings. one's i previously made show in the editor, but when launched end up the basic rectangle they start as and they seem to have zero aero properties. when i click show wing data, all values are at 0. when i create a new wing no menu comes up if i right click on it. clicking J on a wing does nothing.

I've been looking but I've not seen anybody else mention this.

Edited February 8, 2017 by joebopie

[varsass]

16 hours ago, joebopie said:

After installing this from the Dev version from Github it seems to have broken B9 procedural wings. one's i previously made show in the editor, but when launched end up the basic rectangle they start as and they seem to have zero aero properties. when i click show wing data, all values are at 0. when i create a new wing no menu comes up if i right click on it. clicking J on a wing does nothing.

I've been looking but I've not seen anybody else mention this.

I'm also using using B9 procedural wings and dev version of FAR, and I don't have any problem. Are you sure you got the last version and all dependancies for both mods ?

[Temeter]

Hey, Ferram, I know you're probably super busy updating whenever you're working on FAR, however, a small question... Would you mind, assuming it's viable, adding an optional switch to set the water physics to stock/stock style?

The water physics might be quite realistic for planes, which is good, but they kinda break - or incredibly slow down - the improvised boats and aircraft carriers you can build in KSP. IE, I got a swimming carrier with it's deck sitting on 3 pontoons made out of 3.75m tanks (with cones ofc), and with FAR the water resistance will make it hard ever to reach above 8m/s (applying ~2000kn of thrust), having the whole thing easily fall apart under time warp, or at higher speeds.

Even a real, fast carrier of course will only make 2 times that, but that is not really fun either when it comes to unrealistic boats/carriers. Only way to comfortably use it is w/o FAR, but thas of course makes using planes a lot more boring!

Edited February 9, 2017 by Temeter

[Hesp]

Hi, I've been using the dev version for the last month. Everything worked seamlessly, but yesterday i found a small problem. Not sure if FAR is involved in this, though. Maybe you can help me sort this out. Premise: it's an experimental career game with lots of mods installed.

Got a contract for planting a flag on the Mun. Got there, and during the planting animation the flag was not visible and there was an explosion.

The kerbal was stuck in place. I had to reset the input locks and change scene. When coming back, everything was fine except no flag present, of course.

The contract was marked as completed anyway, so that's just a minor annoyance.

 

I ran through the log and the last thing happening before the explosion is a voxelization operation. I'm not home now, but I can attach the log extract later this evening.

FIrst flag planting of the career, so I couldn't notice this problem before.

Spoiler

[ModularFlightIntegrator] MFI Start
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

[ModularFlightIntegrator] Start. VesselModule on vessel : 
  ModularFlightIntegrator
  FlightGUI
  FARVesselAero
  ModuleLifeSupportSystem
  PDPN_VesselModule
  RPMVesselComputer
  ModuleSwapConverterUpdate
  ModuleStabilization
  CommNetVessel
  BoiloffController
  BetterBurnTimeData

 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

FARVesselAero on flag(Clone)(Clone) reporting startup
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

Handling Stuff for KerbalEVA / Flag
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

Adding vox box to Kerbal / Flag
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

flag(Clone)(Clone) Exploded!! - blast awesomeness: 0.5
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

[flag(Clone)(Clone)]: Deactivated
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

2/12/2017 7:48:25 PM,AmpYear,AYController onVesselDestroy:flag(Clone)(Clone) (00000000-0000-0000-0000-000000000000)
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

RemoteTech: SatelliteManager: OnVesselDestroy(00000000-0000-0000-0000-000000000000, Flag)
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

RemoteTech: SatelliteManager: UnregisterProto(00000000-0000-0000-0000-000000000000)
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

IR: [ServoController] OnVesselUnloaded, v=Flag
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

Destroying object multiple times. Don't use DestroyImmediate on the same object in OnDisable or OnDestroy.
 
(Filename:  Line: 1364)

1 explosions created.
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

[SCANsat] Unloading Kopernicus On Demand PQSMod For Tekto
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

[SCANsat] Height Map Of [Tekto] Completed...
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

[SCANsat] Loading Kopernicus On Demand PQSMod For Laythe
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

NullReferenceException
  at (wrapper managed-to-native) UnityEngine.Collider:set_enabled (bool)
  at FlagSite.OnPlacementComplete () [0x00000] in <filename unknown>:0 
  at KerbalEVA.flagPlant_OnLeave (.KFSMState st) [0x00000] in <filename unknown>:0 
  at KerbalFSM.RunEvent (.KFSMEvent evt) [0x00000] in <filename unknown>:0 
  at KerbalFSM.updateFSM (KFSMUpdateMode mode) [0x00000] in <filename unknown>:0 
  at KerbalFSM.UpdateFSM () [0x00000] in <filename unknown>:0 
  at KerbalEVA.Update () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

NullReferenceException
  at (wrapper managed-to-native) UnityEngine.Collider:set_enabled (bool)
  at FlagSite.OnPlacementComplete () [0x00000] in <filename unknown>:0 
  at KerbalEVA.flagPlant_OnLeave (.KFSMState st) [0x00000] in <filename unknown>:0 
  at KerbalFSM.RunEvent (.KFSMEvent evt) [0x00000] in <filename unknown>:0 
  at KerbalFSM.updateFSM (KFSMUpdateMode mode) [0x00000] in <filename unknown>:0 
  at KerbalFSM.UpdateFSM () [0x00000] in <filename unknown>:0 
  at KerbalEVA.Update () [0x00000] in <filename unknown>:0 

 

Edited February 13, 2017 by Hesp
log extract added

[strongest_2hu]

On 2/8/2017 at 10:26 AM, joebopie said:

After installing this from the Dev version from Github it seems to have broken B9 procedural wings. one's i previously made show in the editor, but when launched end up the basic rectangle they start as and they seem to have zero aero properties. when i click show wing data, all values are at 0. when i create a new wing no menu comes up if i right click on it. clicking J on a wing does nothing.

The "dev" FAR download doesn't come with Modular Flight Integrator (obviously), which is required.  Without FAR and MFI installed B9 procedural wings work as normal; installing FAR without MFI breaks B9 wings (in addition to FAR, obviously).  Check to see if that is your problem, it was mine: I made a clean install and forgot about MFI.

[Citizen247]

I was wondering about something tangentially related to FAR: FAR calculates aerodynamics for the whole craft rather than each single part as I understand it. Would a similar thing be possible for physics, i.e. only applying physics to the craft as a whole instead of individual parts? It seems computationally wasteful to be calculating physics for individual parts unless the craft is currently breaking up... Most of the time it would seem a better approach to treat the craft as a single "part" and only calculate it as separate ones if it's staging or experiencing forces strong enough to break the connections between parts. Is that possible from a modding perspective?

[DocMop]

27 minutes ago, Citizen247 said:

I was wondering about something tangentially related to FAR: FAR calculates aerodynamics for the whole craft rather than each single part as I understand it. Would a similar thing be possible for physics, i.e. only applying physics to the craft as a whole instead of individual parts? It seems computationally wasteful to be calculating physics for individual parts unless the craft is currently breaking up... Most of the time it would seem a better approach to treat the craft as a single "part" and only calculate it as separate ones if it's staging or experiencing forces strong enough to break the connections between parts. Is that possible from a modding perspective?

How would you know about whether the forces are high enough for breaking or not if you do not calculate the physics for each part?

[Citizen247]

9 minutes ago, DocMop said:

How would you know about whether the forces are high enough for breaking or not if you do not calculate the physics for each part?

You'd know what forces were acting on the craft as a whole, would you not need to just know if those forces rose above the strength of the weakest join, and only calculate physics for each part in those circumstances? It's possible I'm being an idiot in thinking that though.

[neomagus00]

50 minutes ago, Citizen247 said:

FAR calculates aerodynamics for the whole craft rather than each single part as I understand it.

I'm no expert, but from what I've gathered, I think this is a misunderstanding. FAR wraps the whole craft in a mesh (like this), then calculates aero forces on each point of the mesh. So it's actually treating the craft as thousands of separate points.

Doing physics on the parts is pretty similar, actually - each part has a "point" at its center(*), and you calculate physics on each point. They're just joined together in a tree structure, rather than a mesh.

In both cases, it's a cycle of (draw mesh / parts -> calculate and combine forces -> update part positions), which happens every time a frame is rendered(**).

You're right that it would be more efficient to treat the whole craft as a rigid body, and model it as a single point. But DocMop nailed it, your plane wouldn't be able to bend, or move ailerons, and so on. Remember, you don't care only about catastrophic failure: your wings should bend with increasing load, and your center of mass should change as fuel burns off, etc., otherwise it would feel like an old arcade game.

-neo

(*): I assume KSP is detailed enough to use center of pressure, center of mass, etc. accurately, but the center of the part is usually a pretty good approximation to all of these.

(**): This is a guess. Physics updates may be more frequent in KSP, I'm not sure if it does physics at a different rate than graphics. E.g. racing games often calculate physics WAY more often than they update the screen, for better accuracy.

Edited February 15, 2017 by neomagus00
edited to respond to Citizen247's point

[monstah]

22 minutes ago, neomagus00 said:

I'm no expert, but from what I've gathered, I think this is a misunderstanding. FAR wraps the whole craft in a mesh (like this), then calculates aero forces on each point of the mesh. So it's actually treating the craft as thousands of separate points.

You're guessing wrongly, and I think you didn't gather very well because it says so right in the original post by the author:

On 14/09/2012 at 8:22 PM, ferram4 said:

What does this mod do that stock KSP doesn't?

Stock KSP calculates drag as a linear combination of the drag properties of a vehicle's parts, with some interaction changes to handle some of the most obvious aerodynamic interaction effects. FAR instead calculates the drag from the vessel shape as a whole, resulting in a more realistic model of aerodynamic drag and body lift

(emphasis mine)

In fact, this thread is a (long) statement to the evolution of the mod's algorithms, and the implementation of the interactions of many many aerodynamic effects.

[Citizen247]

28 minutes ago, neomagus00 said:

I'm no expert, but from what I've gathered, I think this is a misunderstanding. FAR wraps the whole craft in a mesh (like this), then calculates aero forces on each point of the mesh. So it's actually treating the craft as thousands of separate points.

Those are voxels, which is the method Farram uses to model airflow across the surface of the craft. Stock aerodynamics calculates drag for each part and only, as I understand it, uses a very rudimentary system for interaction between parts. Essentially stock aero sees a craft as a group of parts flying in close formation, with some "cludges" to allow parts to exclude others from airflow. FAR looks at the craft as a whole unit.

Quote

In both cases, it's a cycle of (draw mesh / parts -> calculate and combine forces -> update part positions), which happens every time a frame is rendered(**).

I'm not sure of your point. KSP calculates physics for each part, applying forces and so on, with some of those forces coming from attached parts. I assume it's some form of forward kinematics, so you essentially get a group of parts flying in formation held together by "springs". It just seems to me that that is quite wasteful computationally unless you're applying enough force to overcome the spring joins.
 

Quote

Remember, you don't care only about catastrophic failure: your wings should bend with increasing load, and your center of mass should change as fuel burns off, etc., otherwise it would feel like an old arcade game.

I'm not sure why. There's no reason you couldn't have a changing centre of mass treating the whole craft as one unit that I can think of. You'd have to calculate it differently to the stock game though.

[DocMop]

2 hours ago, Citizen247 said:

You'd know what forces were acting on the craft as a whole, would you not need to just know if those forces rose above the strength of the weakest join, and only calculate physics for each part in those circumstances? It's possible I'm being an idiot in thinking that though.

Forces are only one way to break inter part connections, there is also torque. In the end you would have to implement lots of extra code to catch any and all exceptions. And I guarantee you that there would still be cases where it would not work as intended. Implementing it this way would just create more bugs at the cost of limited performance gain in exceptional cases only.

[joebopie]

12 hours ago, strongest_2hu said:

The "dev" FAR download doesn't come with Modular Flight Integrator (obviously), which is required.  Without FAR and MFI installed B9 procedural wings work as normal; installing FAR without MFI breaks B9 wings (in addition to FAR, obviously).  Check to see if that is your problem, it was mine: I made a clean install and forgot about MFI.

yea that was the problem. I didn't realise as last time I used FAR MFI didn't exist  

[Cratzz]

Having some issues with the dev-build, certain configs cause the craft to be glued to the ground. This often happens when adding the tailsection of the craft. By removing the surface areas of the tail, the craft launches (by obviously don't fly very well)

https://dl.dropboxusercontent.com/u/5191989/Untitled.png

[kcs123]

3 hours ago, Cratzz said:

Having some issues with the dev-build, certain configs cause the craft to be glued to the ground. This often happens when adding the tailsection of the craft. By removing the surface areas of the tail, the craft launches (by obviously don't fly very well)

https://dl.dropboxusercontent.com/u/5191989/Untitled.png

Same craft on runway with FAR flight data window opened could reveal more info if there is issue with FAR or bad design. In case of FAR bug there is usualy "NaN" where number is expected. If there is craft design issue, post it in FAR craft exchange thread, someone will be able to tell proper advice with that. Usualy it is rear wheel position problem rather than surface control error.

In case of "NaNs" proper log file can help too.

[FirroSeranel]

@ferram4

Dev build bug report: possible conflict with BahamutoD's Destruction Effects mod.

The voxelization engine appears to be attempting to voxelize smoke and fire effects from Destruction Effects as part of the aircraft in realtime. I was flying a plane (made with PWings, but I don't think that's the culprit) and on takeoff, the ailerons snapped off. Destruction Effects created trails of flame, and smoke streaming from the connection points, and my physics rate and framerate instantly dropped to maybe 1:10 and 6 fps respectively. The plane was still flyable (just without roll control), so I kept going for a little while. As it approached the sound barrier, I saw white shockwave effects coming off of the smoke particles, as if they were physical objects attached to the plane!

Also, I have a question. Does FAR model the exhaust pressure of engines in determining area ruling? Most engines are quite blunt at the back, but in operation, the pressure of the exhaust forms a much more streamlined effective shape. That should eliminate most if not all drag due to the blunt back edge of the engine, while the throttle is up, shouldn't it? Or is it simply too complex to model in realtime in KSP?

 

[ferram4]

@Cratzz & @FirroSeranel: If you have actual bugs, provide logs and full reproduction steps.  I can't do anything with reports like this.

Cratzz, I don't think there's any wrong behavior with yours just from the report.  It sounds like the difference between a stable overweight plane with too little pitch authority and a barely stable (or even unstable) overweight plane where the instability helps it pitch up.

FirroSeranel, If there's an error, I need the logs.  I don't think it has anything to do with DestructionEffects though, considering there isn't a way for me to get particle effects as a mesh to voxelize.  If that were the case, the flight characteristics would have changed very drastically as a result.

As for engines, for airbreathers FAR models this pretty well as an effective reduction in area for the path of intake air with an approximation for the increased drag from throttling down those.  FAR doesn't try to handle that for rocket engines due to the difficulty in getting real data for what's happening with those engines.

[Cratzz]

2 hours ago, ferram4 said:

@Cratzz If you have actual bugs, provide logs and full reproduction steps.  I can't do anything with reports like this.

Cratzz, I don't think there's any wrong behavior with yours just from the report.  It sounds like the difference between a stable overweight plane with too little pitch authority and a barely stable (or even unstable) overweight plane where the instability helps it pitch up.

Ofcourse, i'll be more thorough in the future. The problem was a simple case of landinggear in relation to CoL, all sorted now!

Edited February 20, 2017 by Cratzz

[GBry]

Is there any progress on KSPWheels? What's triggering it though? It's kinda annoying to test my craft to see it fail to land properly..

[Jagzeplin]

dont feel like reading the ENTIRE thread but im getting the impression that the experimental 1.2.2 compatible FAR build is clandestine and closed to us noobies who dont know how to "compile". is there another similar mod out there that makes airflow realistic and is updated to 1.2.2?

[qromodynmc]

13 minutes ago, Jagzeplin said:

dont feel like reading the ENTIRE thread but im getting the impression that the experimental 1.2.2 compatible FAR build is clandestine and closed to us noobies who dont know how to "compile". is there another similar mod out there that makes airflow realistic and is updated to 1.2.2?

1.2.2 compatible dev build is avaible to public and easy to install. You just have to know how

[Jagzeplin]

Quote

1.2.2 compatible dev build is avaible to public and easy to install. You just have to know how

theres a whole lotta programmers and people who know what the heck C++ is on this forum. what yall consider "easy" can be bewildering to a luddite like myself. i like to pretend im tech savvy because i built the PC im typing on but really i just followed a youtube video

Edited February 20, 2017 by Jagzeplin