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

[ferram4]

@sh5525: Some editor issue I'm looking into. Not sure what causes it.

@DaMichel: I can confirm, but have on clue what's going on.

@Behemoth1702: Well, without pictures, none of us have any idea what's wrong. We can guess, but that's probably not going to help too much. Odds are that you don't have enough wing far enough back though.

[Behemoth1702]

Hey guys, thanks for the helpful replies.

Unfortunately I am not able to re-create the issue. It seems that a restart fixed SOMETHING. I know for sure that the graphs did not look like that before. Also the craft controlled kind of differently. Mhh. Sorry to have sturred up worries. Everything is fine I suppose.

@ferram4: Could you explain a little bit on the %AoA setting on control surfaces? I can not understand them yet. It has something to do with AoA but how exactly my craft benefits from this is beyond me. :-/ As I said I am a newbie at all this advanced aerodynamics stuff.

Thanks!

EDIT: BTW I really admire the magnificent Firehound, amazingly flying beast! Did you model it after the Su27 series by any chance?

EDIT2: I made a screenshot of the "yellow stability graph going up" issue. Any comments on design are welcome, I want to get better at this.

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

Edited December 25, 2014 by Behemoth1702

[ferram4]

So the %AoA setting (which needs a better name, but I can't think of one) is simply automatic deflection of the control surface when it's at a set AoA. If it's at 100%, and the control surface (undeflected) would be at 5 degrees, then the control surface will deflect 5 degrees against the flow, and you'd end up with 10 degrees of deflection; this is good for adding some automatic additional stability even though you don't quite have the wing area / tail area needed for it. If it's at -100% it will deflect with the flow and effectively maintain 0 degrees AoA; this is very good for having wing area "magically" appear when you reach high enough AoAs, because the surface will stop being able to deflect and start producing lift. It's very good for hypersonic designs.

So, what you've got going on there with the Cm (yellow) line is that once the plane stalls it becomes unstable. This is very, very bad, but not unexpected. The trick is to force the forward lifting surface to stall before the rearward lifting surface, which results in the plane becoming more stable once it stalls and helping to pull it out of the stall. So, how do we do that? Increasing the aspect ratio (span / chord or span^2 / wing area; compare a U2 [high AR] against an F-104 [low AR] to see the difference) or decreasing sweep angle of the forward-most surface. That will force that surface to stall sooner, making the plane much more stable.

Also, the Firehound is part Su-27, part F-18. The front is very Su-27-ish, the back is more F-18-ish, with the wings themselves being their own kinda thing.

[Behemoth1702]

Thank you for your helpful reply! I can kind of understand why I was unstable now.

I decreased span without reducing wing area and VOILLA, perfect stats!

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

Thank you very much for your help! But this AoA thing needs some more brain matter from me to understand. I will have to do some tests to fully understand this, lol.

So as you say when an UNDEFLECTED control surface with %AoA set to 100 gets into 5° area of attack, it will ADD deflection so you end up with 10° AoA at that control surface? So it sort of amplifies the control? And if set to negative values it will move "into" the flow to reduce AoA?

Thank you!

[Wanderfound]

Behemoth: If you have a neutrally set elevator to start with, and then pull the nose up to a 10° AoA:

* If it is set it to 100% AoA, it will deflect to 10° down (relative to the plane, not the airstream; it's now effectively 20° down relative to airstream), helping to stop the nose from climbing too high.

* If it is set to -100% AoA, it will deflect to 10° up (again, relative to the plane) making it effectively 0° deflection relative to the airstream. But if the maximum deflection of that control surface is set to 10° and you then pull the AoA up further to 20°, the surface will not be able to continue compensating for the AoA and will stay at 10° up (relative to the aircraft, now effectively 10° down relative to airstream). Again, this can get you out of an excessive pitch-up situation.

[Behemoth1702]

Thank you for your answer!

I've done some testing and it's a bit different from what you describe above. But that is because I used a canard at the FRONT of the plane, haha, so it went the other way around! Positive values increased the AoA, negative ones tried to decrease it.

Thank you for your explanations! Might want to add them to the FAR wiki or a readme or something.

I have to figure out now how to use this to improve hypersonic flight. Thanks everybody! I am really anjoying FAR right now with spaceplanes. Now - onto rockets! Haha.

[Hoss]

Hello ppl im new to this mod and was wondering if there is something i need to do in order for my ailerons/elevators/rudders to work. I see the balls moving in the lower left but I see no movement on plane... Im using KSP v25....Ive tried .90 aswell...any idears and thanks

[sh5525]

Thank you , I am looking forward for answer of that~ best wishes for you and FAR!

[jaredjeya]

Why have you blocked FAR from working on 64 bit? For me 64 bit massively improves my FPS and never crashes. Surely a warning on loading the game that "64 bit is not supported and I will not fix bugs that do not arise in 32 bit" would be enough? It seems heavyhanded to simply cut off use of the mod for all the users of 64 bit KSP.

[Superfluous J]

Why have you blocked FAR from working on 64 bit? For me 64 bit massively improves my FPS and never crashes. Surely a warning on loading the game that "64 bit is not supported and I will not fix bugs that do not arise in 32 bit" would be enough? It seems heavyhanded to simply cut off use of the mod for all the users of 64 bit KSP.

It's not enough. The people who complain about it "breaking mah stuff 64 bit works great except all these crashes" are the exact same people who blow past warnings without reading them. The ONLY way to keep these people from hounding modders so hard that the modders end up quitting is to deprive the entire community from the option to run the mod in 64 bit.

[blowfish]

Why have you blocked FAR from working on 64 bit? For me 64 bit massively improves my FPS and never crashes. Surely a warning on loading the game that "64 bit is not supported and I will not fix bugs that do not arise in 32 bit" would be enough? It seems heavyhanded to simply cut off use of the mod for all the users of 64 bit KSP.

FYI, you can find unofficial recompiles around with x64 enabled. They aren't officially supported of course.

[bdito]

Why have you blocked FAR from working on 64 bit? For me 64 bit massively improves my FPS and never crashes. Surely a warning on loading the game that "64 bit is not supported and I will not fix bugs that do not arise in 32 bit" would be enough? It seems heavyhanded to simply cut off use of the mod for all the users of 64 bit KSP.

It's in bold letters on the first page.

Note: This mod disables itself on 64-bit Windows builds of KSP to avoid exacerbating its inherent instability.

[Hodo]

Why have you blocked FAR from working on 64 bit? For me 64 bit massively improves my FPS and never crashes. Surely a warning on loading the game that "64 bit is not supported and I will not fix bugs that do not arise in 32 bit" would be enough? It seems heavyhanded to simply cut off use of the mod for all the users of 64 bit KSP.

LOL..... fail.

The reason behind this is because Ferram got sick AND tired of telling each and every person who blew past that warning on launch with FAR and complaining here in this thread about how 64bit version was doing this or doing that. So he just disabled 64bit all together. Which was the best choice he had.

Sorry but 64bit is a hot mess right now Squad knows it and so does everyone else in the community this is why no one really uses it any more.

[cantab]

For clarity, with the %AoA function on control surfaces, what AoA is used? Just the one for that control surface? Some sort of average for all the wings? The angle between the heading and the prograde marker?

[BudgetHedgehog]

Why have you blocked FAR from working on 64 bit? For me 64 bit massively improves my FPS and never crashes. Surely a warning on loading the game that "64 bit is not supported and I will not fix bugs that do not arise in 32 bit" would be enough? It seems heavyhanded to simply cut off use of the mod for all the users of 64 bit KSP.

Rather than speak for ferram4 himself, here's why:

Fine, this conversation has been had about thirty times by now, and it always goes the same way, but I'll bite.

First, we don't shut down mods on 64-bit KSP. If we did, we'd throw the Linux 64 build under the bus, and that build has been quite stable with only few quirks. We shut down mods on win64 builds only, and do you know why?

Huge disclaimers don't work. They never have. People don't care, especially if they perceive that if maybe they scream at a faceless modder enough that everything will magically work. And that assumes they actually read the damn thing; most people don't.

So what happens when people waste time doing this? Let us count the problems:

1. Legitimate issues suffered by all users get buried by win64 crash reports that cannot be fixed.
   
2. Bug reports for issues that might be legit are made more difficult to resolve because no one can be sure if it's a mod / KSP issue or a win64 issue.
   
3. Users spend lots of time screaming (incorrectly) that mods are the source of win64 instability, rather than the fact that the engine is just broken, meaning that problems 1 and 2 become worse over time.
   
4. Users share "common knowledge" about which mods "break" win64 or "quick fixes" that hold things together, but the ultimate fact is that they rarely do, and then when we inevitably get bug reports, there are even more variables and issues going on.
   
5. Time spent dealing with all of this delays bug fixes, features, and overall just slows down mod development.
   

We've dealt with all of this. I've dealt with all of this, I was originally not locking my mod down on win64 and was trying to provide support to users on it. Go, search the FAR thread back into the 0.24 release days, it's all there.

Add on to this that until we locked out many mods, Squad didn't realize how bad the stability was and similarly, users did not accept that win64 was broken at all. Hell, some still don't, you're an example; you wouldn't be ranting about wanting to run mods on a broken piece of software, you just think that we're all full of it, that things aren't that bad, that all the reports of constant crashing are overblown.

There are no problems to cover up; they exist in the engine itself, no amount of mods will hide it. There is not a damn thing we can do to make win64 stable, but we can do a damn thing to provide support to our users that don't insist on running a broken build by ensuring that not only is win64 not supported, but that people running our mods simply can't spam about win64 issues.

Think I'm full of it? Then go and recompile the mods you want, and go prove that I'm wrong. Go ahead, no license can stop you for personal use. But you're not a mod developer, you don't know how? Oh, it's simple, there's a tutorial in the tutorials forum on how to do it. But you don't think you should have to? Well, you're the one saying that it hides problems rather than solving them, so go and show us the way. But you don't know how? You can learn, just like we did.

I'd love to discover that there's a way around whatever's breaking in win64 KSP. It would be wonderful to get the embargo out of the way, make win64 stop being a disaster, get rid of the complaints about crashes from it, and stop the win64 advocate drama. But there's nothing we've been able to do but wait on Squad or the Unity engine devs to fix the issues deep within code that we can't touch.

[Gobur]

I have problem. I use FAR with real chute and DRE. With this mod chute cannot be deployed with mach>1. But stock capsule not drop spead from orbital to mach<1. In level 0 i have 400 m/s. Is capsule drag to small or i change setup by mistake? I have this problem with most reentry vehicle, and before 0.25 most of it reach terminal velocity near 5000m of hight.

[ferram4]

The Mk1 pod has a terminal velocity of 160 m/s at 5 km, unless you are somehow confusing FAR by clipping unnecessary heat shields into the bottom of the pod. Just like everyone else who seems to think the pod with a built-in heat shield doesn't have one.

[Gobur]

ech, then i must change something :-(. Need reinstall all :-(. i test stock pod with stock chute and hit sea 420 m/s. I think maybe i left file from RO or change seting. TY for help.

Edited December 26, 2014 by Gobur

[Zeenobit]

For some reason, I can't get the FAR window to show up in flight. It's fine in VAB/SPH and KSC menus. But during flight, when I click the FAR button, simply nothing happens. I tried re-installing FAR already, thinking my window position might be messed up.

Any suggestions?

[Behemoth1702]

For clarity, with the %AoA function on control surfaces, what AoA is used? Just the one for that control surface? Some sort of average for all the wings? The angle between the heading and the prograde marker?

Behemoth: If you have a neutrally set elevator to start with, and then pull the nose up to a 10° AoA:

* If it is set it to 100% AoA, it will deflect to 10° down (relative to the plane, not the airstream; it's now effectively 20° down relative to airstream), helping to stop the nose from climbing too high.

* If it is set to -100% AoA, it will deflect to 10° up (again, relative to the plane) making it effectively 0° deflection relative to the airstream. But if the maximum deflection of that control surface is set to 10° and you then pull the AoA up further to 20°, the surface will not be able to continue compensating for the AoA and will stay at 10° up (relative to the aircraft, now effectively 10° down relative to airstream). Again, this can get you out of an excessive pitch-up situation.

This is pretty clear to me.

Measures AoA of the plane (cockpit/nose), applies degrees of deflection relative to the plane (cockpit/nose), right?

[Behemoth1702]

For some reason, I can't get the FAR window to show up in flight. It's fine in VAB/SPH and KSC menus. But during flight, when I click the FAR button, simply nothing happens. I tried re-installing FAR already, thinking my window position might be messed up.

Any suggestions?

Try deleting the config.xml inside the FAR pluginData folder. It should reset all the GUIs. I think I've read this in some readme or maybe on front page.

EDIT: Indeed I have:

I've installed FAR, and the GUI isn't appearing in the Editor or in Flight; what's wrong?

It's possible that you haven't installed FAR properly. Make sure that the FerramAerospaceResearch folder is properly placed in the GameData folder and that ModuleManager is placed in the GameData folder. If problems persist, make a post containing your output_log.txt so that I can try and find the source of the problem.

The GUIs don't appear to load; what gives?

It's possible that the GUI has loaded off of your screen. Go into GameData/FerramAerospaceResearch/Plugins/PluginData/FerramAerospaceResearch and delete config.xml. This should fix the problem.

[Zeenobit]

Try deleting the config.xml inside the FAR pluginData folder. It should reset all the GUIs. I think I've read this in some readme or maybe on front page.

EDIT: Indeed I have:

Yup. I saw that, which is why I tried re-installing FAR. Twice. I deleted the GameData/FerramAerospaceResearch/Plugins/PluginData/FerramAerospaceResearch directory and re-downloaded/installed the mod.

I'll try to provide a log when I get a chance though.

[Czerky]

I have problem. I use FAR with real chute and DRE. With this mod chute cannot be deployed with mach>1. But stock capsule not drop spead from orbital to mach<1. In level 0 i have 400 m/s. Is capsule drag to small or i change setup by mistake? I have this problem with most reentry vehicle, and before 0.25 most of it reach terminal velocity near 5000m of hight.

Are you running Advanced Jet Engine by any chance? I had the same issue and removing AJE restored normal drag behavior. Why this worked I have no idea.

[cantab]

The Mk1 pod has a terminal velocity of 160 m/s at 5 km, unless you are somehow confusing FAR by clipping unnecessary heat shields into the bottom of the pod. Just like everyone else who seems to think the pod with a built-in heat shield doesn't have one.

This is a potential problem with any thin parts now. Because the editor no longer checks for part intersection it can be frustrating to get the right node connected. Meanwhile the offset tool allows the player to work around this and create a ship that looks right and in stock would fly right, but in FAR behaves unexpectedly. It's not only a DRE issue, it just affects DRE users more thanks to the combination of the heat shields being extra thin and the pre-chute terminal velocity mattering.

By way of example, here are two simple ships that look identical but in FAR have very different aerodynamics

Test A, built how it looks: https://flic.kr/p/qxZjbc

Test B, with the battery connected by its lower node then offset down: https://flic.kr/p/qxVyNJ

I know it's easy for me to say and not so easy for you to code, but I feel you should aim to have FAR give correct behaviour in situations like this.

[Behemoth1702]

So, after trying to design cool looking, maneuverable and STABLE(!) aircraft, this is what I came up with that works really good for me. It even sometimes manages to get out of a large scale stall!

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

Any feedback/comments are welcome.

http://www./download/91o11v1w7xm3kx5/Explorer_mk2_VAMP.craft

Question though - ferram4:

When I offset a part in the editor, will FAR take this into account or does it connect wings only to the surface they have been attached to in the POSITION they have been attached to? This refers to the post before this one where the capsule with the battery has 2 different aerodynamic behaviours although looking the same.

Also you said - to make a plane stable when stalling/after stall make sure that the forward surface stalls first. I kind of want to understand this more.

1. Do wings in FAR have "multiple areas"? A front, back, middle? Or are they counted as ONE part. Because that would mean - make your wings out of many parts so the wing can stall partially instead of stalling the whole thing.

2. I don't really understand how stalling the forward wing earlier will help the plane. Does that mean that this wing does not generate any lift anymore and therefore the AoA gets a reduced effect on the plane -> the plane wants to reduce AoA automatically? Also - there are these "spins of death" that I can barely manage to escape. Is there a way to design a plane to kind of recover out of this by itself?

Thanks for your mod man, you opened up a whole new world of fascination for me in KSP! Any way I can donate something?

Edited December 26, 2014 by Behemoth1702