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

[ferram4]

@GBry: You mean issue #165, which should have been fixed on @Shadowmage's end, IIRC.  There should be no issues with that now.

@Jagzeplin: "Easy to install" means literally, "find the right place, download a bunch of files, and place them in the correct location."  Which is why keeping the location secret is the barrier to entry, because it is literally the only thing preventing everyone from using it.  Fortunately, people are good and realize the value of keeping this on the down-low for now.

Alright, news update: an actual release should be ready soon, the only remaining thing I want to do is some more irritation involving the AppLauncher button, because changing everything to share a single button for a mod as intended (and as required now) doesn't play well when it toggles multiple variables, so I'm currently waiting on getting it to update its on/off state right.  Small, but irritating.  There should be no more serious bugs in the latest build, yell at me if you find any.

[Shadowmage]

2 hours ago, ferram4 said:

@GBry: You mean issue #165, which should have been fixed on @Shadowmage's end, IIRC.  There should be no issues with that now.

@GBry Indeed, should be fixed up as far as I know.  Make sure you have the latest KSPWheels release.  If there are still problems at that point, please open a ticket on the KSPWheels repo with the relevant details ( https://github.com/shadowmage45/KSPWheel/issues ).

[VentZer0]

I am on 1.2.2 and currently using the dev build and I was wondering in general, does FAR change the scale height of Kerbins atmosphere? I nocticed this while I was making atmCurves for my AL31 Jet Engine.
I made the velCurve constant and only changed the atmCurve to drop linear between 0.4 and 0.3 atm. I had 0kN thrust at about 8.4km Altitude(MSL). 8.4km does not correspond with 0.3 atm pressure according to the scale height of 5.6km that Kerbin is supposed to be having.
So yeah does FAR change the scale height of Kerbin or am I missing something else?

[Hesp]

42 minutes ago, VentZer0 said:

I am on 1.2.2 and currently using the dev build and I was wondering in general, does FAR change the scale height of Kerbins atmosphere? I nocticed this while I was making atmCurves for my AL31 Jet Engine.
I made the velCurve constant and only changed the atmCurve to drop linear between 0.4 and 0.3 atm. I had 0kN thrust at about 8.4km Altitude(MSL). 8.4km does not correspond with 0.3 atm pressure according to the scale height of 5.6km that Kerbin is supposed to be having.
So yeah does FAR change the scale height of Kerbin or am I missing something else?

The best way to check is to put on a PresMat barometer on your craft and fly up there

Anyway AFAIK FAR doesn't change pressure values or scale height, and the threshold for 0.3 bar should be around 8000m altitude.

[VentZer0]

32 minutes ago, Hesp said:

The best way to check is to put on a PresMat barometer on your craft and fly up there

Anyway AFAIK FAR doesn't change pressure values or scale height, and the threshold for 0.3 bar should be around 8000m altitude.

I did that pressure test... yeah the pressure and scale height are in the same ball park. +- 200 or 500meters is the accuracy I get from the indicated pressure readings and calculating those into altitude.
But the atmCurve says 0.10 and I find that my engine thrust goes to zero at 0.08atm. Engine cuts off at ~14000m (<= ~0.082) and full thrust is at anything below 10700m (>= ~0.15atm). I don't know is that normal behaviour? The curve is linear y=0 from x=0 to x=0.1, positive linear slope between 0.1 and 0.2, and is y=1 from x=0.2 til x=1. I wonder where this fussiness is coming from.

Thought maybe FAR changed the atmosphere too.

[strongest_2hu]

2 minutes ago, VentZer0 said:

The curve is linear y=0 from x=0 to x=0.1, positive linear slope between 0.1 and 0.2, and is y=1 from x=0.2 til x=1.

Are you using tangents?

 

[VentZer0]

10 minutes ago, strongest_2hu said:

Are you using tangents?

 

yes I do use that floatcurve editor

http://imgur.com/a/rYCbY
 

[blowfish]

5 hours ago, VentZer0 said:

I am on 1.2.2 and currently using the dev build and I was wondering in general, does FAR change the scale height of Kerbins atmosphere? I nocticed this while I was making atmCurves for my AL31 Jet Engine.
I made the velCurve constant and only changed the atmCurve to drop linear between 0.4 and 0.3 atm. I had 0kN thrust at about 8.4km Altitude(MSL). 8.4km does not correspond with 0.3 atm pressure according to the scale height of 5.6km that Kerbin is supposed to be having.
So yeah does FAR change the scale height of Kerbin or am I missing something else?

e^-8.4/5.6 = 0.22, which is lower than 0.3, but the image you just posted shows a different curve.

[VentZer0]

3 minutes ago, blowfish said:

e^-8.4/5.6 = 0.22, which is lower than 0.3, but the image you just posted shows a different curve.

I see. I think I might have jumped between the graphs in my calculator. What I meant was:
The engine flamedout way later than thought. It should have cut off at 0.3atm but it did at 0.22atm.

yes it is this one : "The curve is linear y=0 from x=0 to x=0.1, positive linear slope between 0.1 and 0.2, and is y=1 from x=0.2 til x=1. "
 

[AccidentalDisassembly]

This is probably a case of me not understanding something, but... is it currently possible to set FAR's default keys for extending and retracting flaps to any keys of my choice? I try to set them to "custom09" and "custom10" (which I assume are the 9 and 10 keys, and also therefore action groups), but this reverts every time I change scenes and I end up having to manually set action groups to control flaps in the editor. I suspect some kind of conflict: either with AGX, or perhaps a mod like ThrottleControlledAvionics which used to commandeer many action groups keys for its own purposes, and might be overwriting settings, or something. I don't know. I tried altering FAR's conf

At any rate: is there currently a way of setting the flaps keys to something like the - and + keys, or some other arbitrary combination, and having those settings preserved forever and ever?

 

Edit: Second behavior that I've noticed.. I swear FAR changes the way craft interact with water, is this the case? Specifically, without FAR, I can more or less steer the Mallard at moderate speeds on the water - say, 25-30 m/s. However, with FAR installed (and ModuleFlightIntegrator, but nothing else changed), steering becomes incredibly difficult. A slight steer at most any speed will result in a violent jerk of the craft, and if you steer around 25-30m/s the whole thing will lurch violently around and blow up spectacularly.

Along those lines as well, I have noticed that, in my FAR games, I am unable to control a craft underwater - in stock, control surfaces (or airbrakes) seem to interact with water. For instance, if the Mallard is moving in the water at 5-10 m/s with its airbrakes submerged, and activates the airbrakes, the aero forces overlay tells me the brakes produce quite a lot of drag. With FAR however, in the same situation the airbrakes produce a negligible amount of drag. What gives?

Edited February 21, 2017 by AccidentalDisassembly

[blowfish]

20 minutes ago, VentZer0 said:

I see. I think I might have jumped between the graphs in my calculator. What I meant was:
The engine flamedout way later than thought. It should have cut off at 0.3atm but it did at 0.22atm.

yes it is this one : "The curve is linear y=0 from x=0 to x=0.1, positive linear slope between 0.1 and 0.2, and is y=1 from x=0.2 til x=1. "
 

Well I'm confused now.  You have your curve begin to drop at 0.2 but you expect it to cut off at 0.3?

Also can I ask what the purpose of this curve is compared to the stock curves?  Real jets will have their mass flow scale perfectly linearly with atmospheric pressure*, so the stock curves already give you a bonus in the mid atmosphere compared to real life.

* ok, there are secondary effects like bleed air requirements, but that will be pretty small.  Also, performance will vary a bit with temperature, which will cause some variation with altitude, but that's not the same as pressure changing.

[VentZer0]

24 minutes ago, blowfish said:

Well I'm confused now.  You have your curve begin to drop at 0.2 but you expect it to cut off at 0.3?

Also can I ask what the purpose of this curve is compared to the stock curves?  Real jets will have their mass flow scale perfectly linearly with atmospheric pressure*, so the stock curves already give you a bonus in the mid atmosphere compared to real life.

* ok, there are secondary effects like bleed air requirements, but that will be pretty small.  Also, performance will vary a bit with temperature, which will cause some variation with altitude, but that's not the same as pressure changing.

Have you seen my second post after the first one got a response?

Quote

I did that pressure test... yeah the pressure and scale height are in the same ball park. +- 200 or 500meters is the accuracy I get from the indicated pressure readings and calculating those into altitude.
But the atmCurve says 0.10 and I find that my engine thrust goes to zero at 0.08atm. Engine cuts off at ~14000m (<= ~0.082) and full thrust is at anything below 10700m (>= ~0.15atm). I don't know is that normal behaviour? The curve is linear y=0 from x=0 to x=0.1, positive linear slope between 0.1 and 0.2, and is y=1 from x=0.2 til x=1. I wonder where this fussiness is coming from.

Thought maybe FAR changed the atmosphere too.

I changed the curve to falloff between 0.2 and 0.1, and redid the test with this curve. In the initial post I tried between 0.2 and 0.3.

I am testing which atm pressure corresponds to which altitude so that I can fit my atm pressure curve to my engine, basically control at which altitude it should cutoff. Currently I am tweaking the AL31 engine for my SU-27 replica craft. I want a fair approximation of the real world behaviour translated into Kerbins atmosphere - that is why I use FAR, so that it can perform like the real aircraft (with FAR I can do cobras without thrust vectoring yay \o/ ). FAR helps with the stock behaviour of engines which seems to be very weird. Wasn't able to break mach 1.2 at sea level in stock KSP. With FAR I have to tune down the engine pretty much or I go mach 2 at sea level.
 

[blowfish]

@VentZer0 not sure then, but I will mention that flameout actually happens when the flow mutliplier drops below a certain threshold.  The flow multiplier is affected by % propellant available as well as all the curves (velCurve and atmCurve in this case).  By default, the engine will flame out if this drops below 0.07 (but you can set this by setting flameoutBar on ModuleEngines(FX) ).

You're definitely right that stock engines are too powerful in FAR.  They're balanced for stock aero.  The biggest problem I've seen, and probably why you're hitting mach 2 at sea level, is that thrust grows too much with mach number (machCurve).

If you want more realistically behaving engines in general, you could try AJE (linked in my signature).  It completely replaces stock atmospheric engines with an actual (though approximate) simulation of their actual behavior.  Not perfect, but much better than stock.  Creating your own engines has a bit of a learning curve, but I believe there's an AL-31 config included by default.

[VentZer0]

2 minutes ago, blowfish said:

@VentZer0 not sure then, but I will mention that flameout actually happens when the flow mutliplier drops below a certain threshold.  The flow multiplier is affected by % propellant available as well as all the curves (velCurve and atmCurve in this case).  By default, the engine will flame out if this drops below 0.07 (but you can set this by setting flameoutBar on ModuleEngines(FX) ).

You're definitely right that stock engines are too powerful in FAR.  They're balanced for stock aero.  The biggest problem I've seen, and probably why you're hitting mach 2 at sea level, is that thrust grows too much with mach number (machCurve).

If you want more realistically behaving engines in general, you could try AJE (linked in my signature).  It completely replaces stock atmospheric engines with an actual (though approximate) simulation of their actual behavior.  Not perfect, but much better than stock.  Creating your own engines has a bit of a learning curve, but I believe there's an AL-31 config included by default.

I see. Yeah maybe this accounts for the fussiness I was seeing.

Exactly that is the problem, that is why I wanted to edit the atmCurve to compensate for this behaviour. Shouldn't the drag be much higher this deep into the atmosphere?
Together with the velCurve I've brought it down to about mach1.4 at sea level. So far so good. I am going to tinker a bit more with this, since I want to include this engine in a parts mod with my SU-27 parts. Why not make it correct-ish  now
 

I've already downloaded the latest version to see if there are any velCurves or atmCurves in there that resemble something remotely realistic to have a starting point. To my surprise there aren't any
I will try AJE when I've tweaked this engine and then compare them.

[ferram4]

@VentZer0: Since you're asking, no, FAR doesn't change the atmospheric pressure or temperature.  No reason to, it's close enough to reality and it breaks interacting with planet mods like RSS.

3 hours ago, AccidentalDisassembly said:

At any rate: is there currently a way of setting the flaps keys to something like the - and + keys, or some other arbitrary combination, and having those settings preserved forever and ever?

Because the flaps function through KSP's action groups, you must set them to work with an action group.  I'm not going to add a bunch of code to rebuild the action group system for arbitrary bindings because that's way too much work to be useful.  That said, the default bindings can be changed in FAR's space center menu, because those bindings are annoying to set.  Those function perfectly as far as I am aware with FAR alone and if there is a conflict I have no idea how I would fix it on my end considering the small amount that FAR does to set those, so if that does not work, take it up with the other modders.

3 hours ago, AccidentalDisassembly said:

Edit: Second behavior that I've noticed.. I swear FAR changes the way craft interact with water, is this the case? Specifically, without FAR, I can more or less steer the Mallard at moderate speeds on the water - say, 25-30 m/s. However, with FAR installed (and ModuleFlightIntegrator, but nothing else changed), steering becomes incredibly difficult. A slight steer at most any speed will result in a violent jerk of the craft, and if you steer around 25-30m/s the whole thing will lurch violently around and blow up spectacularly.

Along those lines as well, I have noticed that, in my FAR games, I am unable to control a craft underwater - in stock, control surfaces (or airbrakes) seem to interact with water. For instance, if the Mallard is moving in the water at 5-10 m/s with its airbrakes submerged, and activates the airbrakes, the aero forces overlay tells me the brakes produce quite a lot of drag. With FAR however, in the same situation the airbrakes produce a negligible amount of drag. What gives?

Yes, FAR changes the water behavior.  In particular, it applies the same drag and lift coefficients as in air but with the density scaled properly for water vs. air (read: 800x).  As it turns out, moving on water at pretty high speeds like that (for water, remember) can result in very bad things happening, particularly if you try to drift around.

Also, I'm confused by your second paragraph, considering it directly contradicts your first on water behavior.  The first paragraph is complaining that FAR applies water forces that are too high for what you feel they should be.  The second is saying that it applies forces that are too low for what you feel they should be.  So which is it?  Everything gets the same scalar, so at this point I don't know what you're talking about.

[AccidentalDisassembly]

1 minute ago, ferram4 said:

@VentZer0: Since you're asking, no, FAR doesn't change the atmospheric pressure or temperature.  No reason to, it's close enough to reality and it breaks interacting with planet mods like RSS.

Because the flaps function through KSP's action groups, you must set them to work with an action group.  I'm not going to add a bunch of code to rebuild the action group system for arbitrary bindings because that's way too much work to be useful.  That said, the default bindings can be changed in FAR's space center menu, because those bindings are annoying to set.  Those function perfectly as far as I am aware with FAR alone and if there is a conflict I have no idea how I would fix it on my end considering the small amount that FAR does to set those, so if that does not work, take it up with the other modders.

Yes, FAR changes the water behavior.  In particular, it applies the same drag and lift coefficients as in air but with the density scaled properly for water vs. air (read: 800x).  As it turns out, moving on water at pretty high speeds like that (for water, remember) can result in very bad things happening, particularly if you try to drift around.

Also, I'm confused by your second paragraph, considering it directly contradicts your first on water behavior.  The first paragraph is complaining that FAR applies water forces that are too high for what you feel they should be.  The second is saying that it applies forces that are too low for what you feel they should be.  So which is it?  Everything gets the same scalar, so at this point I don't know what you're talking about.

Indeed it is very contradictory, and I can't figure out a good way of describing it, but maybe this will make sense.

I checked numbers this time on drag on airbrakes - in water, they do produce a roughly similar amount of drag as in stock. But shouldn't they be producing a lot more than in stock, or am I misunderstanding the correction of the "properly scaled" part? At 10 m/s in stock, it was about 23kN of drag per stock airbrake (submerged), and in FAR it was about 25kN. Perhaps that's not enough speed to show the real difference, but it is 33mph or so... 

Part of the problem was the aero forces overlay (vs. the aero forces info in right-click menu), which (apparently) works differently in Stock vs. FAR.

For the operations on water, things just seem.. well, contradictory. Short version: for a craft like the mallard, unmodified or with a keel (I added a keel to try to make it work better), it should be hard to "sideslip"  or drift when moving at any speed; it seems like a (relatively) long/slender "boat" (especially when equipped with wing pieces as a keel) should create a big turning force with a small AoA. But:

- Even with the keel, it ISN'T terribly hard to get the plane to sideslip (says the navball), and it can start with a very small application of (not-submerged) rudder. At 30-40m/s, if you DO apply a very slight turning force, the turn becomes self-sustaining and unrecoverable, BUT the plane's vector doesn't seem to change very much until some arbitrary AoA where it finally seems to get a turning force from the water, and the force ramps up very quickly - you can't pull the Mallard out of the turn, and when it hits that magical AoA, it's too great, causes the craft to either lurch and halt or fly apart (if the speed is really spectacular).

- So: it just "feels" (yeah, yeah) like the interaction between plane/water is not quite right for the shape of the plane/plane's parts/however it works. Whereas drifting should be hard to get started, a small force makes it mostly inevitable...

Maybe that's just the Mallard itself, and nothing to do with FAR? Maybe just my perception about how it's "supposed" to feel?

 

[GBry]

20 hours ago, Shadowmage said:

@GBry Indeed, should be fixed up as far as I know.  Make sure you have the latest KSPWheels release.  If there are still problems at that point, please open a ticket on the KSPWheels repo with the relevant details ( https://github.com/shadowmage45/KSPWheel/issues ).

 

22 hours ago, ferram4 said:

@GBry: You mean issue #165, which should have been fixed on @Shadowmage's end, IIRC.  There should be no issues with that now.

@Jagzeplin: "Easy to install" means literally, "find the right place, download a bunch of files, and place them in the correct location."  Which is why keeping the location secret is the barrier to entry, because it is literally the only thing preventing everyone from using it.  Fortunately, people are good and realize the value of keeping this on the down-low for now.

Alright, news update: an actual release should be ready soon, the only remaining thing I want to do is some more irritation involving the AppLauncher button, because changing everything to share a single button for a mod as intended (and as required now) doesn't play well when it toggles multiple variables, so I'm currently waiting on getting it to update its on/off state right.  Small, but irritating.  There should be no more serious bugs in the latest build, yell at me if you find any.

Wait, sorry. I thought the KSPWheels issue was related to the stock landing gear bogey locking up in the tilted position after taking off.. I assume this is a separate problem? Haven't done any troubleshooting, but has anyone experienced the same problem? I think it's not even related to FAR...

Image :

https://drive.google.com/open?id=0Bw0o5Cj-WWayQnRxZmVkR1d3TVU

Edited February 21, 2017 by GBry
Lacking detail

[Shadowmage]

@GBry  That is a stock problem, completely unrelated to KSPWheels, and probably not related at all to FAR either.  I believe it was actually their design intent to have the bogeys hang like that when not landed.

[Volatar]

On 2/20/2017 at 10:30 AM, ferram4 said:

Alright, news update: an actual release should be ready soon, the only remaining thing I want to do is some more irritation involving the AppLauncher button, because changing everything to share a single button for a mod as intended (and as required now) doesn't play well when it toggles multiple variables, so I'm currently waiting on getting it to update its on/off state right.  Small, but irritating.  

Hmmm, didn't know about that change. I wouldn't mind requiring/packaging Blizzy's Toolbar so you can keep using a set of buttons. It'll be just like the old days again

[FirroSeranel]

5 minutes ago, Volatar said:

Hmmm, didn't know about that change. I wouldn't mind requiring/packaging Blizzy's Toolbar so you can keep using a set of buttons. It'll be just like the old days again

Agreed. Blizzy's is basically required for a significantly modded install anyway, and I shove as many buttons into it as I can, and still wind up with a scrolling app launcher, heh.

[GBry]

20 hours ago, Shadowmage said:

@GBry  That is a stock problem, completely unrelated to KSPWheels, and probably not related at all to FAR either.  I believe it was actually their design intent to have the bogeys hang like that when not landed.

It is. As most prominently seen in the 777. But the problem I am experiencing is that when landed, it stays locked in the tilted position, and makes the gears like landing legs, and thus destroys my entire plane by shuddering the entire craft upon landing xD  (no, the landing is soft enough to not make the tires break) (please open my Google Drive link for pics) 

 

Edit : Apparently the problem was MechJeb, for using the Vessel.findWorldCenterOfMass method. Thank you @ferram4& @Shadowmage~!

Edited February 22, 2017 by GBry

[Ser]

 

On 21.02.2017 at 4:27 AM, AccidentalDisassembly said:

is it currently possible to set FAR's default keys for extending and retracting flaps to any keys of my choice?

Part commander helps me a lot with handling flaps. Also ASET mk1 cockpit has an authentic lever for them (if you use mk1 cockpit IVA, of course)

14 hours ago, FirroSeranel said:

Agreed. Blizzy's is basically required for a significantly modded install anyway, and I shove as many buttons into it as I can, and still wind up with a scrolling app launcher, heh.

I believe Janitor's closet has a functionality to deal with stock toolbar.

Edited February 22, 2017 by Ser

[ISE]

Hype intensifies

 

count me in too  

Edited February 23, 2017 by ISE

[Gordon Fecyk]

For those of us playing with testing the dev build, what can we do to help? Are there specific things that need closer testing?

I see only 17 issues in GitHub and these haven't changed since early January, or maybe there's an issue list specific to this build I haven't found yet. There are more recent updates though, things like asteroid voxelization.

ferram4 has told us that folks who report issues to GitHub are awesome, and to please consider being awesome.

[eberkain]

I started getting parts exploding when decoupling at high speeds, anyone else experienced this?