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

[foamyesque]

Nope. We can't be sure of anything. Human beings can't reproduce any task exatcly the same way twice. And when we talk about computer games, that's worse either.

You have no idea what you're talking about, so I suggest you stop.

Ferram, (sorry! ) I've got a feature request (well, two, really) for you:

1. Action-group enable/disable of control surfaces, so that you can turn them on selectively during descent (or off altogether in space-- no more stupid flapping!).

2. The ability to assign to RCS units control axis like you can with control surfaces. F'rex, if I put RCS ports on the ends of my wings, I only want them responding to roll commands, not pitch as well.

[Doomydoom]

Ferram, can you shed some light on the reason behind this aircraft's post-stall behavior? Namely, it wants to fly backwards, and does it mildly successfully. And then it blows up. Leading edge slats were an attempt to mitigate this. COI is a teensy bit in front of COM.

[SchroedingersHat]

@SchoredingersHat: I really don't know if I'd be able to handle the Hooligan Labs airships properly, especially since they don't seem to be all that realistic in terms of the payloads they can lift. They just strike me as incredibly cheap and I'm not going to put too much work into having realistic aerodynamics apply to a cheap mod.

You may be interested in Hooligan Labs' response to having the unrealism pointed out. Turns out he was attempting realism and had an oversight with the units KSP uses. He's added a fudge factor to the mod which should produce realistic results when set to 1 (I and others suggested moving to full realism straight away may be untenable with the size constraints of the game and the VAB/SPH as well as people's ships on existing missions).

The sheer size of them seems to be largely sufficient to give acceptable results regarding drag, although I must admit I have no idea when it comes to what degree an airship flies on lift or buoyancy when cruising at altitude.

[Autochton]

Ferram, can you shed some light on the reason behind this aircraft's post-stall behavior? Namely, it wants to fly backwards, and does it mildly successfully. And then it blows up. Leading edge slats were an attempt to mitigate this. COI is a teensy bit in front of COM.

http://i.imgur.com/Gq5Ao2n.jpg

When you say COI, do you mean center of lift? Because it doesn't look quite big enough to have gravity. Anyway, if your CoL is ahead of your CoM, your plane will want to try and rectify that by flipping around. Always strive to put the CoL behind the CoM, unless you have access to a stabilizing control system (like I hope the new ASAS in .21 will become), because otherwise your plane will be very unstable. With such a control system, you can get away with building dynamically unstable planes, and that will mean we can make planes that will do some really wild maneuvers while being reasonable easy to fly.

Also, IIRC, FAR does not currently support leading-edge slats.

[ferram4]

@foamyesque: I guess I can look into the ability to toggle control surfaces. I don't know if I can do anything with the RCS units, since I don't know what the code is doing there. I can look into it though.

@Doomydoom: First, leading-edge slats are intended to prevent stall at high angles of attack, which won't help you if the CoL is in front of the CoM. You'll need to move the CoL back or else it will continue to suffer from the same problem.

[The Lone Wolfling]

I have no idea when it comes to what degree an airship flies on lift or buoyancy when cruising at altitude.

Entirely buoyancy, with very few exceptions.

[TheGadfly]

I noticed that FAR includes a "ModuleManager.dll" which is added from Deadly Reentry. Do I need to consolidate the two?

[SHOT(by)GUN]

Forward-swept wings might have bug, that they cannot recover from stall?

*addition edit* Even tho I'd have 0.05% stall value... it sticks in it, does not recover, but can increase.

** Also I love you Ferram4 <3 its greatest Mod in since ... ever

Edited July 9, 2013 by SHOT(by)GUN

[Van Disaster]

That's fairly amusing ( and I've occasionally struggled to unstall forwardswept surfaces before, but never had one permanently indicate stalled ) - however it is perhaps only indicating that it's stalled, rather than actually being stalled? although that might be confusing more code than the display code...

[ferram4]

@TheGadfly: You must consolidate them. Just keep the latest version of Module Manager (which i think is the one in Deadly Reentry).

@SHOT(by)GUN: There are two things I want you to try: the first is remove the control surfaces on the wing and see if the problem persists. I think the main wing thinks that the control surface is in front of it for some strange reason.

The second is I want you to rebuild the vehicle, but instead sweep the procedural wing backwards and then flip it over so that you have a forward-swept wing again. This will help determine if the bug is in FAR or Procedural Wings.

[SHOT(by)GUN]

@SHOT(by)GUN: There are two things I want you to try: the first is remove the control surfaces on the wing and see if the problem persists. I think the main wing thinks that the control surface is in front of it for some strange reason.

The second is I want you to rebuild the vehicle, but instead sweep the procedural wing backwards and then flip it over so that you have a forward-swept wing again. This will help determine if the bug is in FAR or Procedural Wings.

Thank you for response!

1. Removing standard flight control surfaces fixed problem

2. Making procedural wing swept-BACK and flipping round did NOT fix problem

3. Switching standard control surface to B9 control surfaces fixed the problem

I really had no idea that the control surfaces might been reason behind this thanks

[praise the suuun]

*edit* found the issue. all the mods are fine together with there own modulemnager.dll's except "deadly reentry". thats the one thats messing up my stock parts

[Palec]

Hello,

I have multiple mods installed, I just installed FAR and when I launch my SSTO with B9 Sabre engine and multiple jet engines, jet engines are working fine but Sabre engine is not producing any thrust. Is it a bug or feature?

[ferram4]

@Palec: That is likely a problem stemming from the fact that the current FAR download has an out-of-date ModuleManager.dll. Reinstall the one contained with B9 and it should work fine.

[ferram4]

FAR version 0.9.5.2 is out, fixing some bugs, some lift and drag adjustments and adding compatibility with procedural fairings.

[CaptainArbitrary]

FAR version 0.9.5.2 is out, fixing some bugs, some lift and drag adjustments and adding compatibility with procedural fairings.

The procedural-fairings change certainly seems to work. I've got a vehicle on the way up right now, and the fairings are working perfectly.

However, did you leave some debugging code in? Every part is showing me Cl, Cd and Cm in the right-click menu all the time.

[ferram4]

Oh, apparently I did. I don't think it actually slows anything down though, so I'm in no rush to fix it. I'll fix that when 0.21 comes out and I need to (probably) do a compatibility fix.

[CaptainArbitrary]

Oh, apparently I did. I don't think it actually slows anything down though, so I'm in no rush to fix it. I'll fix that when 0.21 comes out and I need to (probably) do a compatibility fix.

Actually I think it might slow things down. It might be a coincidence or something else going on, but I'm getting significantly worse performance now. I'm in the middle of my first reentry with FAR 0.9.5.2, and I'm dropping frames like mad, whereas before things weren't so severe.

Not entirely sure how to isolate the cause, though, short of reverting to 0.9.5.1 and flying this mission again.

[betaking]

dynamic pressure isn't being kept out by proceedural fairings, as my remote-tech attenae can tell (being ripped off during ascent)

[ferram4]

@CaptainArbitrary: I haven't noticed any change in performance from making the debug values visible or not; make sure that nothing is spamming the log, and if that's not the case, then it's possible that I haven't optimized something as much as I should have.

@betaking: The RemoteTech part you're talking about doesn't interface with FAR in any possible way; there is no way for it to tell that it must first check to see if it is shielded by a payload fairing or a cargo bay before breaking. This is not a bug with FAR, this is a RemoteTech class not being designed to take advantage of FAR's features if it is installed. Long story short, there's nothing I can do; it's not my code that's the problem.

[betaking]

okay, I guess it was a misunderstanding on my part then, sorry

[taniwha]

Ferram4: I just checked, and the static analyzer "sweep AoA out to 90 degrees" bug is still there: set the Upper value to 90 and click on Sweep AoA: KSP "locks up". I guess something is going into an infinite loop: maybe a solver is getting stuck looking for 0 but getting 1e-11.

The bug does not happen with just an FL-T800 tank, but with wings attached, the bug does happen.

[ferram4]

@betaking: No problem, glad to clear it up.

@taniwha: Ok, so it's somewhere in the wing code; that narrows things down a lot. I actually didn't look into that for this release since I was more focused on actual physics-related bugs rather than the GUI bugs. Hopefully I catch it for the next release.

[taniwha]

ferram4: ok, I'm glad I could help. Another point is that it's in a "relatively recent" change: it worked just fine in 0.19.1 and possibly in early 0.20* versions.

I can understand giving it a pass for this release: I doubt many people do full -90 to 90 degree sweeps (and 89 gives me enough info).

[Guest]

Maybe you're using a tg(x) function somewhere, without proper failsafes? That would be my first guess, since it's a common enough trigonometric function, and one that is undefined at both 90 and -90 degrees.