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

[Sokar408]

It does not safe its VAB location, but its inflight one - for me at least.

That seems to reset aswell though not all the times. Isn't there a file somewhere, where I can set the default location?

[Wahgineer]

Uhh...

So from what I hear, this plugin should allow me to look at a plane and say: "since it looks a lot like a real plane, it should at least fly like one.". What I'm trying to say is that if I build an airplane, the more it looks like a real plane, the better it flies; where as with regular KSP aerodynamics, the more it looks like a real plane, the worse it flies. Is this true?

Also, would the plugin allow me to build a capsule with a slightly offset CoM so that when I tip it during re-entry, the capsule generates lift?

[ferram4]

@Sokar408 & KerbMav: Get v0.10. The Editor GUI remembering its location was a feature added in v0.9.7, which was specifically complained about because it allowed people to lose the minimize button behind the craft name field.

@awsumindyman: Both of those are correct. The same will also apply to rockets, where building a gigantic pancake of boosters will fly worse with FAR installed than a tall, slender rocket.

[sarbian]

For those interested I released the first part of the FAR / MJ2 compatibility patch Read this post

[rpayne88]

How can I make FAR recognize KW and NP fairings? The parts under them are shielded, although FAR gives the line "is shielded= false."

[ferram4]

It should automatically detect that the parts are shielded unless you have changed the "title" field of the fairings so that "payload fairing" is not in the name. Could you show a picture of the problem craft so that I can figure out what's going on? Are you using the most recent version of FAR?

[a.g.]

For those interested I released the first part of the FAR / MJ2 compatibility patch

Code: https://github.com/sarbian/MechJebFARExt

Your code will affect the stall state of the control surface, and the interaction coefficients used for applying actual forces to the surface and the wing it is attached to. Until you do something with ClIncrementFromRear and stall, you cannot call any of that stuff in flight. Also, through that very change in ClIncrementFromRear on the wing, the effect of deflecting the surface is amplified to an extent dependent on the size difference.

[goldenpeach]

For those interested I released the first part of the FAR / MJ2 compatibility patch Read this post

Thank you so much!

As a mechjeb dependant(please, don't start any debate on this) it wi really help me!

As soon as I can,I will dowoad this mod.

Ps: this plugin is a lot more complex that I was expecting(more than 8000 lines fo codes)!

[sarbian]

Your code will affect the stall state of the control surface, and the interaction coefficients used for applying actual forces to the surface and the wing it is attached to. Until you do something with ClIncrementFromRear and stall, you cannot call any of that stuff in flight. Also, through that very change in ClIncrementFromRear on the wing, the effect of deflecting the surface is amplified to an extent dependent on the size difference.

Well maybe, maybe not. But again you could share the magic patch that you said you have.

[Frederf]

Since FAR can adjust which axes aero control surfaces are assigned to (realtime?) is it possible to have a "disable aero surfaces" button for FAR so they don't flap around needlessly in space?

[ferram4]

FAR can only assign control surfaces to specific axes in the editor; it can't do it in flight, at least not right now. I could add a "disable surfaces" button for each control surface, and make them drain electric charge when the deflect to justify doing that.

[a.g.]

Well maybe, maybe not. But again you could share the magic patch that you said you have.

I said (or meant) that I was doing some patches to fix stuff in editor like CoL and graphs, which was broken in part due to not handling these specific stateful interactions properly, and thus I know what I'm talking about here. Most of the changes are already in v0.10.

FAR can only assign control surfaces to specific axes in the editor; it can't do it in flight, at least not right now. I could add a "disable surfaces" button for each control surface, and make them drain electric charge when the deflect to justify doing that.

To me it seems all around simpler if the pitch/yaw/roll surfaces just returned to neutral when atmospheric density dropped to zero and remained there. After all, the whole point is what are they moving for if there is no air. Flaps and spoilers are separately controllable, so they should follow these commands as usual.

[Sokar408]

@Sokar408 & KerbMav: Get v0.10. The Editor GUI remembering its location was a feature added in v0.9.7, which was specifically complained about because it allowed people to lose the minimize button behind the craft name field.

@awsumindyman: Both of those are correct. The same will also apply to rockets, where building a gigantic pancake of boosters will fly worse with FAR installed than a tall, slender rocket.

I got 0.10 though, so I assume you mean I should get 0.10 to have it NOT remember its location. I specifically want it to remember. Is there a setting somewhere where I can able it?

[Tharios]

Ferram, this isn't directly related to your mod, though this particular issue does get worse when I use it. Which is unfortunate, because up until this problem began, I was really enjoying your mod, along with B9 and Interstellar.

All craft, planes and rockets both, no matter how I arrange the wings or control surfaces (or how many I use or don't use), roll clockwise, slowly...without ASAS on.

The instant I turn it on, it starts to wiggle-roll back and forth, and still slowly rolls clockwise. It's always clockwise.

Even the unmodded KSP (completely fresh install, no files or folders preserved at all) does this.

It's pretty much making the game unplayable, because any attempt to correct in-flight causes the craft to lose control...ASAS or not. "Soft" controls do not seem to make a difference at all.

Any thoughts on the problem?

[Snjo]

All craft, planes and rockets both, no matter how I arrange the wings or control surfaces (or how many I use or don't use), roll clockwise, slowly...without ASAS on.

...

It's pretty much making the game unplayable, because any attempt to correct in-flight causes the craft to lose control...ASAS or not. "Soft" controls do not seem to make a difference at all.

Firespitter has a trim tool you can throw on your plane. It allows for super fine control over trim, with presets. Set up a -0.1 roll trim for instance, and keep flying straight.

Stock roll and roll trim will always be super crazy because of a bug in the range of input that is actually used in roll. Only the first 20% or so is used.

Can't say I've noticed that problem as consistently as you say though.

[sarbian]

I said (or meant) that I was doing some patches to fix stuff in editor like CoL and graphs, which was broken in part due to not handling these specific stateful interactions properly, and thus I know what I'm talking about here. Most of the changes are already in v0.10.

Sorry, I was a bit grumpy when I replied.

I'll check again but the value change should not impact the flight model since I change them in onUpdate and they are rebuild in onFixedUpdate. If not then I'll see what I need to save and restore when running the patch.

[a.g.]

These values are not 'rebuilt', they carry on between frames and it is critical for correct operation. The stall value is stateful by definition in order to provide the hysteresis property of stall, and the increment variable relies on the adjacent frames being pretty similar to each other to avoid the issue of the undefined order in which the parts are processed. This means however that you must run at least two passes of computation in order to compute the effect of wing interaction correctly (see CoL code), and you also must call computations exactly once per part every pass or you'd effectively apply the interaction effect multiple times. The original code for computing a sample for the graphs in the editor was basically something like:

for all parts:

do 3 times:

compute stuff

Which produced completely incorrect (as in completely different from in-flight behavior) Cm graphs when flaps were deployed. All that was needed to fix that particular issue was to change it to:

do 3 times:

for all parts:

compute stuff

[LORDPrometheus]

I've noticed a bizarre incidence wherein the drag coefficient of parts decides to change mid flight causing immediate rocket disassembly

* I've solved the issue: my modified procedural fairings would cause parts shielded by them to multiply their drag model by a factor of something like a gazillion and basically make the rocket run vertically through them before physics says that's not right and detonates everything. This kept happening at around 13000m.

A mod update and an edit or two later and I'm good

Edited November 19, 2013 by LORDPrometheus

[UberFuber]

I've noticed a bizarre incidence wherein the drag coefficient of parts decides to change mid flight causing immediate rocket disassembly

Where do you read those drag coefficients?

Also, are you sure you have the right cause and effect? Rocket disassembly could have happened first, causing a change in drag.

[Dante80]

I installed this, and I'm finding getting a certain payload to orbit much easier.

A question. In stock KSP you needed about 4500dV for a good LKO orbit. How much do you need with FAR?

[NathanKell]

I've done it in 3100dV expended. If you're just going off vacuum dV, and/or you don't fly insanely optimized trajetories, assume nominal vac dV to orbit of 3500.

Unless your rocket is unaerodynamic, of course.

[Traches]

I installed this, and I'm finding getting a certain payload to orbit much easier.

A question. In stock KSP you needed about 4500dV for a good LKO orbit. How much do you need with FAR?

If you fly a good profile with a streamlined rocket, less than 3000 m/s. For planning purposes, I usually give myself 3500 m/s.

[Dante80]

Thanks, figured as much. Time to make smaller/slender rockets..C:

[ferram4]

@Sokar408: The editor GUI will remember its position in v0.10 unless you're trying to shift it too high off of the screen where the minimize button will be hidden behind stuff. If you want to manually set it, go into the config.xml in the FerramAerospaceResearch/Plugins/PluginData folder and mess with it there.

@Tharios: It's an issue with the way joints are set up; they don't have consistent strengths for some reason. Use more struts and that should minimize the issue. However, if small attempts at roll control are causing your plane to lose control then either it is only marginally stable in yaw (add more vertical tail) or you have too many roll control surfaces.

[sarbian]

Until you do something with ClIncrementFromRear and stall, you cannot call any of that stuff in flight. Also, through that very change in ClIncrementFromRear on the wing, the effect of deflecting the surface is amplified to an extent dependent on the size difference.

Ok I made a new version that save the value of stall, cl, cd, ClIncrementFromRear, PartInFrontOf.ClIncrementFromRear and restore them after each of my calls. It should be OK now, but I can't go thru all FAR code to check for now.

Commit 1 Commit 2

Link is the same.