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

[Shadowmage]

16 minutes ago, kcs123 said:

Just guessing here, but thing of influence is only COM. Center of lift may work only for stock parts. FAR calculates his own COL based on mesh trough voxelization process. Other reason why it does not behave as expected could be wrong mesh collision. Try to take a screenshoot with transonic curves visible in editor. Also screenshoot with showed voxels in editor might help to detect faulty collision. Hopefully, with those you might get better answer what is going on.

Thanks for the info.

How can I turn on the feature to show voxels?  When I took a gander through the source it looked like it was all commented out and not accessible as an option in-game, and would require custom-recompiling in order to enable it (is there a debug build with this enabled that I haven't run across yet?).

Will certainly provide some screenshots after I get home from work.

[Svm420]

@Shadowmage Open the FAR GUI in the editor go to the transonic page. Click show debug voxels . I really appreciate the proactive FAR support!

[blowfish]

52 minutes ago, Shadowmage said:

Thanks for the info.

How can I turn on the feature to show voxels?  When I took a gander through the source it looked like it was all commented out and not accessible as an option in-game, and would require custom-recompiling in order to enable it (is there a debug build with this enabled that I haven't run across yet?).

Will certainly provide some screenshots after I get home from work.

You can show voxels in the editor by opening up the FAR GUI, selecting the transonic design window (I think that's what it's called), and selecting show voxels (or something like that).  Note that displaying voxels usually degrades performance a lot.  I'd recommend doing most of your investigation with only the cross section displayed (selectable from the same location), and only showing voxels if the cross section looks off.

[Shadowmage]

7 minutes ago, blowfish said:

You can show voxels in the editor by opening up the FAR GUI, selecting the transonic design window (I think that's what it's called), and selecting show voxels (or something like that).  Note that displaying voxels usually degrades performance a lot.  I'd recommend doing most of your investigation with only the cross section displayed (selectable from the same location), and only showing voxels if the cross section looks off.

 

10 minutes ago, Svm420 said:

@Shadowmage Open the FAR GUI in the editor go to the transonic page. Click show debug voxels . I really appreciate the proactive FAR support!

Thanks for the response guys   I must have missed that option when looking through things (don't think I even looked at the trans-sonic page though...). 

With this info, I should at least be able to figure out a bit more about what is going on.

Re: Parachutes -- thinking on it, I'm pretty sure that using a force-based setup (rather than drag-cubes) should likely still work fine in stock (might require different simulated areas in FAR/stock, but that easy enough to patch), and possibly clean up a bit of the oddities from my implementation.  Will do a bit of experimenting on this as well.

[linuxgurugamer]

I saw a comment somewhere that you were working on doing your development on Linux.

I currently use Xamian on Windows, and would like to be able to work on Linux.

Any suggestions or hints?

Thanks in advance

[TheSarge1975]

23 hours ago, ss8913 said:

So.. installed dev build of FAR without mechjebfarext.dll - works great and it *fixes the rendezvous overheating problem 100%*.  Whatever you did in this dev build has definitely solved it and I no longer need any ALT-F12 cheats to dock without explosions   Hopefully it makes its way into an official build soon.

I can confirm this fix does work also, had similar problems of station exploding due to overheating upon reaching physics range.

Good job guys !!

 

Edit:

Just seen that there is a mechjebfarext.dll update for dev version on https://github.com/sarbian/MechJebFARExt

Edited January 25, 2016 by TheSarge1975

[Shadowmage]

Re: Command pods -- apparently this is/was entirely a CoM based problem, and my thinking that the CoL marker in the editor was something useful.  Had I bothered to flight-test after CoM changes last night, I would have seen that it the pod does indeed stabalize heat-shield down with an adjusted CoM.  Rather, I was relying on the CoL marker in the editor, which... I'm not sure what it is supposed to represent (its not there in stock, so I figured it was something FAR added, but perhaps its just an artifact of the interaction).

Thank you all for your assistance though, without looking into the voxel and curve-output for these parts compared to others I likely would have been lost as far as finding a solution.  So.. thanks

I'm fairly certain I can get the parachute interaction sorted out through use of physics rather than drag cubes, which should work in stock as well.

And, because I went ahead and took all the screenshots during testing... might as well use this to show how to -not- set up a re-entry pod's COM (e.g. pics 1&2 are bad, 3&4 and the rest work fine though )

 

P.S.  Anyone know what the blue marker actually represents, if anything?

Edited January 26, 2016 by Shadowmage

[blowfish]

3 minutes ago, Shadowmage said:

P.S.  Anyone know what the blue marker actually represents, if anything?

It's somewhat meaningful in FAR, but it's not entirely reliable at all flight conditions.  FAR assumes that the air stream is coming from the top, so if you place a pod in the default orientation, it will only tells you how it behaves going nose first.

[NathanKell]

@linuxgurugamer ferram is on Windows. @taniwha would be the guy to ask for linux dev.

[ola]

This can't be good...

[ratchet freak]

10 hours ago, blowfish said:

It's somewhat meaningful in FAR, but it's not entirely reliable at all flight conditions.  FAR assumes that the air stream is coming from the top, so if you place a pod in the default orientation, it will only tells you how it behaves going nose first.

in other words if you want to get reentry characteristics you'll need to turn it upside down.

 

Maybe there should be an option for which stage of flight (Ascent and Reentry) the blue marker in the VAB is calculated for?

[taniwha]

3 hours ago, ratchet freak said:

Maybe there should be an option for which stage of flight (Ascent and Reentry) the blue marker in the VAB is calculated for?

No need. Just pull off the other stages when you want to check. Really, since FAR would have to do the same thing¹, and getting such automation correct would be a lot of effort², that's a feature that would cost a lot of other goodies (actual aerodynamic features) in FAR. I'd much rather have to pull the stages myself and get more accurate aerodynamics than be able to push a button in the VAB.

^1,2 Yes, MJ and KER do something vaguely similar for their delta-v calculations, but not only is delta-v much simpler than aerodynamics, MJ and KER sometimes get confused.

[edit] Realy, you should be checking the aerodynamics of each relevant stage as you go, not at the end.

Edited January 26, 2016 by taniwha

[kcs123]

On 26.01.2016. at 2:00 AM, Shadowmage said:

P.S.  Anyone know what the blue marker actually represents, if anything?

Center of pressure. Aerodynamic center - Ferram explained in post below. I found it useful to some degree when you need to place main wings. Just to give you general idea if main wing lift is close enough to center of mass. After I attach main wing on craft hull, I use offset gizmo and FAR graph for AoA sweep to fine tune yellow line slope (torque).

So, yes, blue marker still have some purpose, although it is recommended to use pressure coefficient curve on transonic area ruling analysis tool.

Edited January 27, 2016 by kcs123

[kcs123]

8 hours ago, ola said:

This can't be good...

Yep. Your craft design is not so good for given altitude and speed when comes to dynamic stability.

Lateral simulation graph is good though, showing you the truth that your craft will be unstable despite "green" numbers. That is a reason why those graphs exists in FAR tools.

You may even create quite stable craft for sea level and low speed, all "green" numbers and even oscilation is lowered over time, but same stable craft can become quite unstable on high altitudes and supersonic velocity. You may also have "greeen" numbers for high altitude/velocity but craft might behave unstable like shown on your graph.

That is reason why it is not such good idea to steer some crafts on supersonic velocity. It is better idea to point craft in desired ascent(pitch) and heading profile much earlier and don't touch controls other than throttle until you reach space.

Not everything is so bad as might be on first sight on those graphs though. Sometimes even when simulation shows unstable behaviour, it can be corrected to large degree trough SAS and usage of "magical" reaction wheels and/or vernor/RCS engines. IIRC @Wanderfound used quite a lot vernor engines on his craft designs to stabilize crafts on high altitudes.

[ferram4]

2 hours ago, kcs123 said:

Center of pressure. I found it useful to some degree when you need to place main wings. Just to give you general idea if main wing lift is close enough to center of mass. After I attach main wing on craft hull, I use offset gizmo and FAR graph for AoA sweep to fine tune yellow line slope (torque).

So, yes, blue marker still have some purpose, although it is recommended to use pressure coefficient curve on transonic area ruling analysis tool.

No, no, no, no, no!  The blue marker is *not* the center of pressure.  The center of pressure is absolutely useless for stability calculations and should never be used ever for it, which is why FAR does not display it.  FAR displays the aerodynamic center, which is similar, but rather than finding the location where all aerodynamic effects can be modelled with just a force instead allows for a constant moment.  This allows situations where the vehicle can have a pitch tendency, but no lift and still result in a meaningful aerodynamic center location; under those circumstances the center of pressure would end up moving out to infinity, as it would have to to attempt to produce a pitching moment with no lift force to act perpendicular to the CoM.

Also, the pressure coefficient curve in the transonic area ruling tool provides virtually no quick model of stability.  Considering that it's only modelling it in the forward-backward direction it simply doesn't account for lift at all and so is utterly useless for modelling the stability of planes, where most of the stability is from wing lift.  The transonic pressure coefficient curve is good for determining if your vehicle is stupidly draggy at transonic speeds because of some weird bit of shaping you added, not for determining stability.  Instead, you'd want to use the static analysis AoA sweep's yellow (moment coefficient) curve and look for a downward sweep.

If you're going to try to be helpful, please, try to be sure you're right first.  This sort of stuff results in more confusion and bug reports in the long run.

[sashan]

Would it be possible to have at least rudimentary simulation of proximity effects? Like ground effect, which I guess is the most needed and known.

[Wanderfound]

11 hours ago, kcs123 said:

IIRC @Wanderfoundused quite a lot vernor engines on his craft designs to stabilize crafts on high altitudes.

Most of the time when I'm putting Vernors on things it's for low-g VTOL rather than any atmospheric use.

But, yes, a little bit of directed thrust can cover for a multitude of aerodynamic sins, particularly in thin air. One each side of the nose if you have yaw problems, a couple under the cockpit if you're having trouble keeping the nose up, a pair under the wingtips for roll issues.

They shouldn't be necessary on a well designed aircraft, although it's a handy trick to keep in mind if you're trying to fly something with minimal control surfaces (gliding reentry pods, VTOLs, etc).

[Razum]

I figured out that my Pwing mass problem caused by this mod: https://github.com/Crzyrndm/B9-PWings-Fork

In the original B9 PWings mod, mass calculates normally, no matter FAR installed or not.

Thanks for advices.

Edited January 31, 2016 by Razum

[kcs123]

Encountered no drag calculation bug. It was with dev build from couple of days ago, missed latest one released on weekend.

It is two craft mission. First craft in orbit carry probe and science parts. Second vessel is sent to dock with first craft and refuel it for interplanetary flight.
I did same thing several times in this career game without any issues. I don't know if it is related or not, but on this bugged session I have let MJ to execute few maneuver nodes. Another difference from previous sessions is also that I didn't switched scenes once craft was in orbit, I have done all docking/refuelling and deorbit craft in one game session.
 

I don't know if I will be able to give reliable reproducing steps. I will try to reproduce same thing, but it might be time consuming until I figure out proper triggers.
Meanwhile, here is archive with saved games,crafts and output log if it is of any help.

It seems to me that for some reason MFI didn't started properly on re-entry and because of it FAR also didn't wokred as it should.

[ferram4]

You need to reproduce it with fewer mods, reliable reproduction steps and less speculation.  The only errors in the log that are visible are in the legacy FARWingAerodynamicModel, and in a method that points to either KSP breaking very hard underneath the entire thing or else MM not applying its patches properly, the latter of which would result in no drag being applied ever under any circumstances.  There are no other signs of any kind of issue whatsoever in the log.

[ss8913]

I think there's either a bug in FAR or in my understanding of the planet Eve.  I have a VTOL antimatter-powered spaceplane that performs flawlessly on Kerbin, Duna, and Laythe.  Like, operate to any of those planets from the administration helipad and back, precision landings at all points.  Flies like a dream both normally and in VTOL mode.  Using FAR of course.

Problem comes on Eve.  Flies fine in the upper atmosphere.  Once I get lower down and slow down and go VTOL mode... I pretty much lose control of it.  it starts spinning around (yaw) which I cannot counter, and below that point I also lose the ability to control pitch and roll, and the craft crashes.  Is there something to explain this or is this a bug in Eve's aero model WRT FAR?

[NathanKell]

Recall that thrust varies with Isp. Do all your engines have the same fraction of their Kerbin thrust at Eve? My guess would be some do and some don't, imbalancing things.

[ferram4]

Alright, so we have the update to v0.15.5.5 "Hugoniot", which is almost entirely a bugfix update.  Some sonic drag and water drag issues have been fixed; changelog is available at Github and KS.

[Hunne]

Hello ferram4, hello guys,

 

I seem to have a strange issue, my aircrafts won´t take off at all from the runway until they pass over the grassy part and when the landscape banks down, they suddenly do fly...some designs are able to go way past mach 1 and still are glued to the runway until see above

 

also, anything I come up with beyond really basic design tends either to go to the right (not rolling, I think yaw is the proper word) and as soon as I try to lift the nose simply breaks into pieces...with rockets it´s all fine

I attached a screenshot of my currently installed mods, so maybe someone has an idea about what the hey

[taniwha]

Hunne: Your rear landing gear are too far behind your CoM: your elevators are unable to provide enough torque to lift the nose. You have two options: move your gear forward closer to your CoM, or add canards. The former is preferable as canards add drag, and worse for stability, the drag is near the nose.