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

[endl]

what am i doing wrong its always red no matter how i build it

Javascript is disabled. View full album

[NathanKell]

You have almost no vertical tail at all, and almost no horizontal tail in pic 2.

Look at how big the tail fins (both the tails and the stabilators) are on, say, an F-15. And then recall for the vertical tails, it has *two*.

[AetherGoddess]

Why does it disable itself on Win64? Does it not work at all? Because if it does, I kind of want to use it. I understand the instability issue. I do not understand why you can't make people aware of it and make an "unsupported" build.

shamelessly Quoting myself because i can't be bothreed to write an original response.

ya, it's probably not going to happen until the flaky Win x64 is better, and the disable code isn't for your protection, it's for Ferram's. there is a fairly obvious function in the source code that does the disable. if you can pull and compile the source, and make that very minor change to the code, then you probably have the programming skills to interpret crash logs and not blame FAR/NEAR for crashes that are actually KSP stock bugs in the x64 version. if you can't, then you don't have the very specialized coding skills required to make those subtle distinctions in an experimental environment.

May I request a feature?

I understand why the mod author would want to exclude support for Win64 KSP, especially since x64 KSP is not stable. However, 64 bit KSP with opengl enjoys, at least with my experience, the same stability as the x64 Linux version.

My feature request is simple: a way to re-enable the mod on win64 KSP through a config file, or other means that would not normally be accessible to those who don't know its there along with the disclaimer that problems on Win64 won't be addressed.

Thank you.

It's probably not going to happen. a config option would probably defeat the whole purpose of the disable code as it is right now. consider this related NEAR conversation:

How do I force enable this on Win_x64? I know you don't support it. My game crashes about once a day due to 64 bit instability anyway. I don't care. Due to memory issues, I refuse to go back 32 bit, and I really do hate the base aero model. What do I need to decompile, edit, etc.

And yes, I promise not to harass you about sh*t breaking. I know I'm straining the game's stability and I accept whatever hardware wrecking bugs I bring upon myself.

you have already exceeded the quota of support for Win x64 with this post. yes, you can get the source and turn off the disabling code, and then recompile it and use it. that task works as a sorting filter. if you can make that minor code change and compile it for yourself, then you are certainly knowledgeable enough to tell the difference between a crash caused by FAR and a crash caused by KSP_x64. if you can't, then it doesn't mean you are dumb, and it doesn't mean that you are somehow unworthy, it just means that we can't be sure that you have the necessary skills to run and troubleshoot an unstable version. you can think of it as a driving test: if you can download the zip and install it, then you can drive an automatic passenger car. if you want to drive a F-18, then you need to pass a higher bar.

[...]

i'm speculating on the purpose. don't blame Ferram for my reasons.

With love,

Sarah.

[endl]

You have almost no vertical tail at all, and almost no horizontal tail in pic 2.

Look at how big the tail fins (both the tails and the stabilators) are on, say, an F-15. And then recall for the vertical tails, it has *two*.

i followed your advice, the numbers are worse

[jrandom]

Have you actually tried flying it? I've built craft with some numbers in the red that were still perfectly flyable. Besides, that's the kerbal way!

[ferram4]

The number that is wrong is for pitch control. It's telling you that pitching up will cause the plane to pitch down; your elevator controls are reversed, fix them.

[DundraL]

I love FAR.

I never even tried to make a rocket for the first week or two after getting ksp. I just wanted to make planes. I almost uninstalled the game after launching my first aircraft and seeing what the flight "physics" consisted of. After a search for how to "fix the aerodynamics bug", I found FAR. Haven't played without it since. I like FAR because its a much superior aerodynamic model... To me, FAR = mod for aerodynamic model. Am I wrong about this?

With the recent changes to parts, it feels like an entirely different mod got installed. It feels like I installed two mods: FAR and "realism changes for certain parts". I understand new features get added, but the earlier changes to jet engines and the wing strength/mass features seem to be from another mod entirely. Im not trying to say these changes are good/bad, or even about their implementation. Im asking if they should be in FAR or another, more complete aircraft overhaul mod, with more realism for intakes, jet engines, wing strength, control surfaces that aren't stupidly strong etc... ye know... a realism mod.

So with this in mind, I just want to ask: what is your goal with FAR? Is it an all-in-one thing or an aerodynamic model? Why is bacon so delicious? Would having the changes to parts in a separate mod allow more control or be easier to support etc, or is it easier for it to be all in one?

PS: Im not tying to knock anything here, I got nothing but respect for you and your work. Its litterally the reason I still play KSP, I just wanna know where its going.

[ferram4]

An aerodynamics mod, with the necessary changes to work around issues that only exist because they are workarounds of issues caused by the stock model. The jets only overperform in stock because it is necessary to fight the stock model has drag that is so high. I'd rather people just use AJE, but most won't, and enough people complained that I nerfed jets to more realistic thrusts. Wings weighing so little is a stock thing... that has never made much sense, and raising the masses is necessary to fix a lot of the floating wing tendencies that people could still get with FAR.

FAR has a history of making such changes. It has long shifted the CoM of the Mk1 pod lower, closer to the heat shield, because that is more realistic and is necessary to make it behave properly during reentry. Should I remove that as not being in scope?

The basic answer is: if there is some non-aerodynamic unrealistic error that makes flight with FAR behave wrong (like the CoM of a pod being too high, making it unstable, or wings being too light, making them floaty, or jets being too powerful, giving them higher TWRs than rocket engines, somehow), FAR will change them to the smallest extent necessary to make the aerodynamics behave properly.

FAR has always been a realism mod. Nothing has changed, though I wish that things were not so messed up that I needed to make these changes in the first place.

Edit:

And now, the 0.14.3.1 patch is out fixing wing interaction stalling issues, some lag in the editor when going to attach wings, and some GUI funkiness.

Edited October 19, 2014 by ferram4

[endl]

The number that is wrong is for pitch control. It's telling you that pitching up will cause the plane to pitch down; your elevator controls are reversed, fix them.

as usual you are right on the money, good day to you sir

[blowfish]

I'd rather people just use AJE, but most won't, and enough people complained that I nerfed jets to more realistic thrusts.

I'd really like to use AJE, but it seems like the balance depends on RF which isn't a can of worms I'm interested in opening just yet. Not to mention off-size rescales which would require something like Tweakscale to be useful.

[NathanKell]

AJE needs nothing from RF. It runs just fine with LiquidFuel.

[blowfish]

AJE needs nothing from RF. It runs just fine with LiquidFuel.

Yes, but I don't think the balance is quite there. I'll give you an example: the B9 Sabre is given an ISP of 460s in rocket mode. That's fine if you're rescaling all of the other rocket engines to real-world values, but it's significantly more efficient than any other stock liquid engine other than the LV-N. And then there's the fact that the SABRE and RAPIER CFGs need to be changed manually, which is just an annoyance but still...

[Patrick Kerbivan]

I have a question about how FAR models aerodynamics - and specifically the potential for damage due to aerodynamic stress - that may or may not have been answered before. I did search the thread but didn't have much luck...

So, I know that fairings and cargo bays will provide the "shielded" value to parts contained within, which I'm assuming zeroes out any aerodynamic forces applied to or created by those parts. I'm wondering if FAR's aerodynamic modelling actually goes far enough to essentially be able to fake shielding with an adequately protective structure. As an example, suppose that I have a delicate rover that cannot withstand the aerodynamic forces of reentry without being torn apart; if I build a shell of structural panels around the rover and reinforce the heck out of it will that shell actually deflect the oncoming atmosphere and reduce aerodynamic stress on the rover?

[Jovus]

Yes. I've done it. It works. If you keep things pointed properly.

[ferram4]

@Patrick Kerbivan: No, it doesn't do that, because there isn't enough data known about the part's shape in order to do that. It would require each part to include a bit of info about its shape, which would break the plug-and-play thing FAR has going on.

[Jovus]

Really, ferram? 'cause I've seen behaviour that's at least very similar to that. Namely, I put on a piece that got ripped off (it was a basic battery), then I got curious and put said battery on a structural girder behind and inline with a pod, and it didn't get ripped off even though I was intentionally pulling more extreme maneuvers.

[ferram4]

No, it's not. Aerodynamic forces are still applied.

[Patrick Kerbivan]

Ah, drat. Thanks though!

Is there any sort of simplified summary kicking around that gives an overview of how FAR does what it does? I always had this grand vision of the overall craft model being tossed into a sort of virtual wind tunnel behind the scenes to determine its performance, but if one part doesn't block another's airflow then I'm assuming it's more like it's calculating the aerodynamic properties of each individual part then applying that force at the part's location?

[iamzac]

I found a bug that I think it's recently introduced, probably in 0.14.3.1 or maybe in the last dev versions before 0.14.3:

If I modify general settings for FAR in the menu from the space center window the COL of all my ships is modified, in my case it moves forward and it remains there even if I change the settings back.

I noticed before 0.14.3.1 that my COL moved forward while using a recent dev version but I assumed that this might have been an intentional modification but today I installed 0.14.3.1 then I checked my ships and the COL was again as before, more to the rear, then I changed some settings and it moved again forward, I changed the settings back and it was still forward.

I don't know which of the two COL positions is the right one and which is the buggy one...

Update: I did additional tests and this is NOT related to changing settings as I thought the first time: when you first load a ship after installing a new FAR it shows the COL closer to the rear, if I load it again later without changing anything it shows the COL closer to the front.

Edited October 19, 2014 by iamzac

[velusip]

I'm kinda stuck. I suppose I need to test on other computers. Anything launched on the launchpad has a chance to instantly smash the vessel and send the pod at impossible speeds with FAR. This doesn't always happen when launching on the runway (from SPH). Furthermore, reverting to launch puts the game in a strange state. I have a feeling this is related to a bug with how FlightGlobals.ActiveVessel.parts is managed during scene transitions? Some reports regarding that here: http://bugs.kerbalspaceprogram.com/search?utf8=✓&q=FlightGlobals

Anyway, for nothing more than entertainment purposes, here's the screenshots and log:

Upon launch I see my craft on the launchpad while things load.

As soon as simulation starts, the next frame is this: http://i.imgur.com/jnvtQGE.png

Broken state after reverting the flight: http://i.imgur.com/X7sERwg.jpg and http://i.imgur.com/T7PuqD5.png

Log: http://sprunge.us/FXON

This is with several other mods, but the same results with only FAR. Works fine with all other mods without FAR.

[ferram4]

@Patrick Kerbivan: It handles each part mostly independently, with some empirical corrections to try and account for part interactions, but of course that can't get everything. In the ideal case, most of what it simulates can be calculated from the 1978 USAF Stability and Control DATCOM (which is the latest version I could find).

@iamzac: I cannot confirm the issue; your reproduction steps are not complete at all. Did you follow all of the instruction steps to the letter (including deleteing the entire FAR folder, as stated in the zip, when updating from earlier versions to 0.14.3+? I'll also need a copy of the output_log.txt

@velusip: I don't know what to tell you. No one has been able to provide reproduction steps that work for me. FAR doesn't even set anything for the vessel state, so if that is breaking, then it is likely a stock bug of some kind. Unless someone can get me a working set of reproduction steps, the best I can do is set FAR to not do anything for the first few frames and then hope that the same error doesn't occur when it starts up again. I'd prefer not to do that, but I see no other options besides such hacks.

Does the same behavior occur with NEAR?

I'll try uploading something to the github repo in a few minutes, but I have no ability to test or know if it will work.

Edited October 19, 2014 by ferram4

[iamzac]

@iamzac: I cannot confirm the issue; your reproduction steps are not complete at all. Did you follow all of the instruction steps to the letter (including deleteing the entire FAR folder, as stated in the zip, when updating from earlier versions to 0.14.3+? I'll also need a copy of the output_log.txt

To be sure that no other mods i have are causing this problems I tested again like this:

Step 1: Removed all the mods including FAR, loaded a stock ship in the SPH and took a screenshot: https://www.dropbox.com/s/bhvqdsfbsohr2v1/no_far.png?dl=0

Step 2: Added only FAR 0.14.3.1 as it was downloaded, with no customizations, clean install, loaded the same ship and made another screenshot: https://www.dropbox.com/s/rclx24i4ch353z8/far_firstload.png?dl=0

Step 3: Exit SPH, then return to SPH and made another screenshot, now the COL has moved: https://www.dropbox.com/s/eiuegpwhrtgsmlm/far_secondload.png?dl=0

Here is the KSP_Data\output_log.txt.

[Wanderfound]

No, it's not. Aerodynamic forces are still applied.

So what are the limits? If I have a 2.5m Rockomax tank with a 1.25m docking port on top of it, is there any point in putting a little 1.25m nosecone on that? If I'm building a spaceplane with an open-air cargo bay, is there any way to at least partially shield the contents from drag?

[ferram4]

@iamzac: I cannot reproduce the issue. The CoL is always in the same location. There are some errors that require my attention, but they don't seem to cause the behavior you're describing.

You must still be missing steps, or it is an installation error.

@Wanderfound: Maybe? It depends very much on the exact configuration, and I don't keep a log of all the data in my head. You'll also probably find some really old, known issues in the process if you go exhaustively detailing this stuff. In the real world, there wouldn't be much point in adding the nosecone though.

And if you have an open-air cargo bay, there's pretty much no way to shield the payload; you have to build it as if it's an open-air payload.

[iamzac]

@iamzac: I cannot reproduce the issue. The CoL is always in the same location. There are some errors that require my attention, but they don't seem to cause the behavior you're describing.

You must still be missing steps, or it is an installation error.

I did further tests, I downloaded the older 0.14.3 version and there this bug doesn't exist and the COL is like it is with 0.14.3.1 at the first load, so the bug appeared between 0.14.3 and 0.14.3.1 .

I also tested the latest dev version with the "let's try this" change and the bug is still there.

I also found that I don't need to reinstall FAR to reproduce this bug, everytime I start KSP the COL changes if I follow this simple steps: load the ship (I get the COL from 0.14.3), exit SPH, and return to SPH (I get a new COL that is closer to the front).

Edit: After having a quick look at the output log errors and the github changes maybe this might be the problem:

[spoiler=]

- Collider[] colliders = p.GetPartColliders();
+ FARPartModule farModule = p.GetComponent<FARPartModule>();
+
+ Collider[] colliders;
+
+ if ((object)farModule != null)
+ colliders = farModule.PartColliders;
+ else
+ colliders = new Collider[1] { p.collider };

Since I have no experience with the FAR code this sugestion might be completely nonsense.

Edited October 19, 2014 by iamzac