[1.8-1.12] Ferram Aerospace Research Continued: v0.16.0.5 "Mader" 03/04/22

[kcs123]

4 hours ago, Kitspace said:

FAR, I suppose, is not computational fluid dynamics software? No way that is happening in real time, is there?  Therefore it has to make some assumptions, and use empirical approximations, which is very difficult to do with an arbitrary shape, from the voxel model. That is why it is so interesting what it does.

I am closely related to aerospace engineering in real life, and I have been thinking for some time now, about some of the things that the mod does, and how it can be improved further, to be a more accurate model of real physics. The problem is I know pretty much nothing about coding.
So, if anyone, who understands the mod source code, could tell me in normal language, or even in equations form, what it does, I would greatly appreciate that, and possibly, be able to contribute to improving the aerodynamics.

Well, for those question you should look inside code, to see how exactly calculations are done. I was not looking more deeply in code, so can't tell you much about it. However, I recall that similar questions are asked answered by ferram in old FAR thread. You may try to search trough that thread. Don't know how much in detail current maintainer, @dkavolis can answer, or maybe @taniwha, I think he contributed to some pieces of FAR code in the past.

But, yes, you are right, FAR is not computational fluid dynamics software, it use some assumptions and approximations, as much as I can recall from conversations in old thread, but don't know accurate details about it. IIRC, one of assumptions is that wings are thin and it does not calculate curved top/flat bootom wing cross section shape for fluid separations. I think that ferrram mentioned somewhere that in supersonic flight that have too low impact on lift compared to influence of AoA. You may also try to send PM to ferram, if he is still reading forum threads from time to time.

Edited April 19, 2019 by kcs123

[dkavolis]

3 hours ago, Kitspace said:

Thank you for your reply!

Though, the wiki only talks about it from the end user perspective, while my questions are more about the maths, happening inside, to convert all these values into a flight model.
Also that page talking about Blender, refers to the wing planform shape as an "airfoil", which is an entirely different thing. Airfoil normally means the cross section of a wing, or more broadly, its characteristics, such as lift drag and pitching moment as a function of the angle of attack. Similar to the static graphs the mod makes, but for a section of a wing.

FAR, I suppose, is not computational fluid dynamics software? No way that is happening in real time, is there?  Therefore it has to make some assumptions, and use empirical approximations, which is very difficult to do with an arbitrary shape, from the voxel model. That is why it is so interesting what it does.

I am closely related to aerospace engineering in real life, and I have been thinking for some time now, about some of the things that the mod does, and how it can be improved further, to be a more accurate model of real physics. The problem is I know pretty much nothing about coding.
So, if anyone, who understands the mod source code, could tell me in normal language, or even in equations form, what it does, I would greatly appreciate that, and possibly, be able to contribute to improving the aerodynamics.

I'm fairly sure the wing lift is calculated using lifting line theory with additions for interactions (coded with a ton of circular references) between aerodynamic surfaces so it can't really handle thick airfoils. Though it's still good enough for a game that needs to run in real time. There's no way any CFD can run in real time, certainly not one that would work with arbitrarily shaped vehicles in KSP. Specifying some parameters in the configs greatly reduces the amount of calculations that would need to be done. The supersonic/hypersonic behaviour is pretty approximate, there are a lot of simplifications in the code.

Haven't gone into voxelization that deeply since it's one huge monolithic (not the only one) class that handles it... If I'm not mistaken, the voxelized shape is only used for cross sectional data - mainly body lift and drag.

FAR could really use some refactoring, i.e. moving all aerodynamics/voxelization code into a separate library (and making everything thread safe preferably) that does not depend on KSP assemblies so that tests could run in Unity editor. It could be split into multiple libraries such as GUI/Unity, Maths/Aerodynamics/Voxelization and KSP plugin that binds everything together. It's a lot of work though but that would make FAR much easier to maintain, scale and understand. The part modules should really not do any maths.

If you want to look at the source code more closely, I recommend installing an IDE such as Visual Studio (often overkill) or VSCode which will let you navigate the code much easier, lookup references and usage. If you're a student (or can afford it) and want to do some coding I recommend Rider or ReSharper for Visual Studio with Heap Allocations Viewer and Unity plugins which will greatly help getting started. VSCode has a unity plugin that lets you directly search unity docs on the internet. C# is not hard to pickup unlike FAR.

[Kitspace]

21 hours ago, dkavolis said:

I'm fairly sure the wing lift is calculated using lifting line theory with additions for interactions (coded with a ton of circular references) between aerodynamic surfaces so it can't really handle thick airfoils. Though it's still good enough for a game that needs to run in real time. There's no way any CFD can run in real time, certainly not one that would work with arbitrarily shaped vehicles in KSP. Specifying some parameters in the configs greatly reduces the amount of calculations that would need to be done. The supersonic/hypersonic behaviour is pretty approximate, there are a lot of simplifications in the code.

Haven't gone into voxelization that deeply since it's one huge monolithic (not the only one) class that handles it... If I'm not mistaken, the voxelized shape is only used for cross sectional data - mainly body lift and drag.

FAR could really use some refactoring, i.e. moving all aerodynamics/voxelization code into a separate library (and making everything thread safe preferably) that does not depend on KSP assemblies so that tests could run in Unity editor. It could be split into multiple libraries such as GUI/Unity, Maths/Aerodynamics/Voxelization and KSP plugin that binds everything together. It's a lot of work though but that would make FAR much easier to maintain, scale and understand. The part modules should really not do any maths.

If you want to look at the source code more closely, I recommend installing an IDE such as Visual Studio (often overkill) or VSCode which will let you navigate the code much easier, lookup references and usage. If you're a student (or can afford it) and want to do some coding I recommend Rider or ReSharper for Visual Studio with Heap Allocations Viewer and Unity plugins which will greatly help getting started. VSCode has a unity plugin that lets you directly search unity docs on the internet. C# is not hard to pickup unlike FAR.

Thank you, that is very interesting indeed.

Could it be, that the ton of circular references that you mentioned, is making the software iterate a solution, and causing inconsistency in results?
I do not remember ever seeing this reported, or discussed here, as an issue, but I can not help noticing, that the calculations are often quite inconsistent.
For example sometimes moving or rotating some parts, and returning them to the exact same place, produces a noticeable change in stability.

[dkavolis]

1 hour ago, Kitspace said:

Thank you, that is very interesting indeed.

Could it be, that the ton of circular references that you mentioned, is making the software iterate a solution, and causing inconsistency in results?
I do not remember ever seeing this reported, or discussed here, as an issue, but I can not help noticing, that the calculations are often quite inconsistent.
For example sometimes moving or rotating some parts, and returning them to the exact same place, produces a noticeable change in stability.

I don't know about that, my guess is that some values required for computations are not updated in some cases.

Circular references are often simply bad code design. In managed languages such as C# this prevents the objects from being GCed, i.e. memory leaks, and makes maintaining the code harder.

[kcs123]

With surface attached parts it is very hard to place some parts on exact position as before. And on some craft designs few pixels of diffrence can result in high difference with stability derivative values. I know that because I was spend a lot of time in attempt to re-create crafts from previous KSP version to latest one. You may think that you have placed something on exact spot, but usualy it is not case. You can only be sure about placing on exact spot with node attached parts, not with surface attached ones.

[Arrowstar]

Does FAR have a method of outputting data from it's VAB/SPH analysis tools to a file?

[dkavolis]

2 hours ago, Arrowstar said:

Does FAR have a method of outputting data from it's VAB/SPH analysis tools to a file?

Not yet

[Arrowstar]

9 minutes ago, dkavolis said:

Not yet

Okay thanks!  It would be great if this could be a near term feature of FAR.

[dkavolis]

7 minutes ago, Arrowstar said:

Okay thanks!  It would be great if this could be a near term feature of FAR.

Soon™

I'm not a fan of Unity IMGUI so it will be after I replace it (there's some progress there)

[muckytuja]

Hi Everyone,

I have a problem with this FAR Continued. I am in KSP 1.4.2. The Mod starts, I've got the icon, but when I get in VAB or SPH the COL sphere doesn't show any arrows and when I click on the FARc icon it doesn't show any data no matter what i do. There is no lift at all and the center of lift stuck by the first part what i put in the hangar. I haven't found any similar problems like this. I've made a clean install without any other mods, but it's still the same.

Edit: So, I have tried the old 1.4.3 recompiled version (FAR_0_15_9_2_ferram4) and that seems to work with KSP 1.4.2.

I haven't played much with it, so it's probably buggy as mentioned here in the forum, but at least I can use FAR with Infernal Robotics, wich is awesome to make some swing-wing F-14ish planes and VTOLs, Yeeehaaa! And I've figured that the CoL sphere doesn't have to have arrows, as somebody wrote here in the forum. But it still bugs me what could be the problem for me with the latest FAR releases?! I use the 64 bit version, no other mods, installed only FAR by hand, no CKAN, but still no luck with FARContinued. 

If anyone had similar problem, I would really appreciate His/Her help, and would give a virtual kiss on His/Her belly ;-x

Edited May 2, 2019 by muckytuja
Situation changed of my question.

[dkavolis]

I've created a pinned issue FAR#55 to keep track of what should be done. If anyone has any suggestions, leave a comment there and I'll add it to the list if it's worth pursuing.

[EnfieldOneOne]

I've been thinking about installing this mod for a while.  I just have one important question.  The OP says that FAR doesn't work with modded wings because the need to have their characteristics input manually, which makes sense.  However I play with quite a few mods installed, some of which happen to have wings in them.  This raises the question of how does FAR handle wings that aren't stock?  Do they just apply stock aerodynamics to them?  Or do they perhaps cause some sort of catastrophic failure within FAR?  Or maybe something in between those two extremes?  Thanks in advance for a reply.

[dkavolis]

2 hours ago, EnfieldOneOne said:

I've been thinking about installing this mod for a while.  I just have one important question.  The OP says that FAR doesn't work with modded wings because the need to have their characteristics input manually, which makes sense.  However I play with quite a few mods installed, some of which happen to have wings in them.  This raises the question of how does FAR handle wings that aren't stock?  Do they just apply stock aerodynamics to them?  Or do they perhaps cause some sort of catastrophic failure within FAR?  Or maybe something in between those two extremes?  Thanks in advance for a reply.

Wings without configs will produce no lift.

[kcs123]

6 hours ago, EnfieldOneOne said:

The OP says that FAR doesn't work with modded wings because the need to have their characteristics input manually, which makes sense. 

 

3 hours ago, dkavolis said:

Wings without configs will produce no lift.

However, it depends on mod you have installed. Some of mods support FAR and have config files included for it from mod author. Some other mods, like APP for example, does not have support for FAR from mod author, but there is MM patches available for that mod from other community members. @theonegalen have made some for APP for personal usage and he shared those configs to others, for example.

Personaly, I use stock wing/control surface for some simple craft designs early in career. For better optimised planes I prefer B9PW. Reason is that for FAR you want on some craft designs specific wing swept angles and surface areas where 1-2 degree in shape makes significant changes. It is difficult to achieve that with cluttered wing parts overlaping each other etc. if you build it with fixed shape/size wing parts. You end up then with much more parts on craft then you should be necessary and your craft weight more then it need to be.

It is quite possible to create good crafts with fixed wing size/shape though, being stock or moded, but only for certain overall craft size and weight. And it is more difficult to optimize such craft to fly better in FAR atmosphere.

EDIT:
It is being mentioned before, but might be good to mention again. How to notice if you have craft parts that FAR does not handle properly. Usually, FAR replace lift blue ball with arrow indicator to just ball. When you place unsuported part on your craft, lift blue ball indicator in SPH/VAB have arrow on it like stock game.

You can usualy use other parts from mod just fine if you avoid just ones that produce issues.

Edited May 11, 2019 by kcs123

[EnfieldOneOne]

8 hours ago, kcs123 said:

 

However, it depends on mod you have installed. Some of mods support FAR and have config files included for it from mod author. Some other mods, like APP for example, does not have support for FAR from mod author, but there is MM patches available for that mod from other community members. @theonegalen have made some for APP for personal usage and he shared those configs to others, for example.

Personaly, I use stock wing/control surface for some simple craft designs early in career. For better optimised planes I prefer B9PW. Reason is that for FAR you want on some craft designs specific wing swept angles and surface areas where 1-2 degree in shape makes significant changes. It is difficult to achieve that with cluttered wing parts overlaping each other etc. if you build it with fixed shape/size wing parts. You end up then with much more parts on craft then you should be necessary and your craft weight more then it need to be.

It is quite possible to create good crafts with fixed wing size/shape though, being stock or moded, but only for certain overall craft size and weight. And it is more difficult to optimize such craft to fly better in FAR atmosphere.

EDIT:
It is being mentioned before, but might be good to mention again. How to notice if you have craft parts that FAR does not handle properly. Usually, FAR replace lift blue ball with arrow indicator to just ball. When you place unsuported part on your craft, lift blue ball indicator in SPH/VAB have arrow on it like stock game.

You can usualy use other parts from mod just fine if you avoid just ones that produce issues.

This is exactly the answer I was looking for.  Will be installing tonight when I get home from work!

[suzuki]

FAR Continued seems way less like FAR versions developed by Ferram himself. I've been finding ascent profiles much easier and far more similar to that of stock aerodynamics in 1.6.1 RSS/RO, even with AV551 flying at any desired ascent profile compared to the strict flight profile it has to fly today. What were the changes to FAR? 

[dkavolis]

7 hours ago, suzuki said:

FAR Continued seems way less like FAR versions developed by Ferram himself. I've been finding ascent profiles much easier and far more similar to that of stock aerodynamics in 1.6.1 RSS/RO, even with AV551 flying at any desired ascent profile compared to the strict flight profile it has to fly today. What were the changes to FAR? 

So far there have been almost exclusively bug fixes, quite a few of them are related to voxelization. You can see all the changes in the changelog.

[Maeyanie]

On 5/11/2019 at 12:50 PM, EnfieldOneOne said:

This is exactly the answer I was looking for.  Will be installing tonight when I get home from work!

You can also use a .cfg file like this to mark non-FAR parts:

@PART[*]:HAS[@MODULE[ModuleLiftingSurface],!@MODULE[FARWingAerodynamicModel]]:NEEDS[FerramAerospaceResearch]:FINAL
{
	@title ^= :$: *Non FAR*:
}

@PART[*]:HAS[@MODULE[ModuleControlSurface],!@MODULE[FARControllableSurface]]:NEEDS[FerramAerospaceResearch]:FINAL
{
	@title ^= :$: *Non FAR*:
}

(Just create a plain text file anywhere in GameData named whatever.cfg and copy-paste that into it.)

Those parts do still work, they just only produce blunt-body lift. This is perfectly fine in some cases, like some flat-bottomed plane parts which the author gave stock-aero fake body lift; FAR simulates that fine without needing any special settings, so them being marked as a "non FAR" wing doesn't matter. This just acts as a reminder when you're looking through all those wings and trying to pick ones which are properly simulated.

Edit: As an idea, it might be useful to have links to 3rd party FAR compatibility patches in the OP, to make them easy for everyone to find... unless there's some thread for those I don't know about or something.

Edited May 13, 2019 by Maeyanie

[Cratzz]

@dkavolis Hi, im on KSP v1.6.1 and im wondering if the latest version is backward compatible?

Edited May 23, 2019 by Cratzz

[dkavolis]

34 minutes ago, Cratzz said:

@dkavolis Hi, im on KSP v1.6.1 and im wondering if the latest version is backward compatible?

Yes, it should work down to KSP 1.4 as the topic title or CKAN shows.

[BrawlerAce]

I haven't seen anything on this, so I decided to make a forum account for this.

With the Breaking Ground DLC having come out yesterday, I decided to try to make a variable geometry aircraft. In stock, there are no aerodynamic changes, which i assume is because of stock's simplified aerodynamics. However, in FAR, I've noticed that when I build a craft, having the wings swept back actually degrades high speed performance, as if they were acting like air brakes engaging. To test this, I made two aircraft without the robotic parts, one with the wings mounted forwards (as if they were swept forwards) and one with the wings mounted back (as if they were swept back), and they demonstrated performance that made sense (the first aircraft didn't perform as well at high speed, while the second one had a higher max speed). I also tested this with Infernal Robotics because I was curious to see if it was just an issue with the DLC or not, but I ran into the same issues.

Interestingly enough, if I build an aircraft with variable geometry wings swept back by default, it seems to fix the issue sometimes, while other times I'll still have the same issues.

Not sure if this is a FAR issue, but do you know anything about it? It almost seems like when wings are deployed, they act as airbrakes regardless of their actual purpose. 

[dkavolis]

13 minutes ago, BrawlerAce said:

I haven't seen anything on this, so I decided to make a forum account for this.

With the Breaking Ground DLC having come out yesterday, I decided to try to make a variable geometry aircraft. In stock, there are no aerodynamic changes, which i assume is because of stock's simplified aerodynamics. However, in FAR, I've noticed that when I build a craft, having the wings swept back actually degrades high speed performance, as if they were acting like air brakes engaging. To test this, I made two aircraft without the robotic parts, one with the wings mounted forwards (as if they were swept forwards) and one with the wings mounted back (as if they were swept back), and they demonstrated performance that made sense (the first aircraft didn't perform as well at high speed, while the second one had a higher max speed). I also tested this with Infernal Robotics because I was curious to see if it was just an issue with the DLC or not, but I ran into the same issues.

Interestingly enough, if I build an aircraft with variable geometry wings swept back by default, it seems to fix the issue sometimes, while other times I'll still have the same issues.

Not sure if this is a FAR issue, but do you know anything about it? It almost seems like when wings are deployed, they act as airbrakes regardless of their actual purpose. 

Yeah, FAR doesn't handle animated parts well. What makes it even harder, robotic parts do not actually use animations but move mesh transforms and do not have any API hooks to detect the events (at least I have not found any yet). So just assume that robotic parts are unsupported in FAR and no ETA when they will be, if ever.

[Gordon Dry]

No API hooks.
I would say that is the most dramatic nightmare for any mod dev.

Or am I wrong?

[dkavolis]

21 minutes ago, Gordon Dry said:

No API hooks.
I would say that is the most dramatic nightmare for any mod dev.

Or am I wrong?

I could probably register callbacks to KSPFields and KSPActions and intercept start/end that way but it is not the cleanest solution.

[Svm420]

53 minutes ago, dkavolis said:

I could probably register callbacks to KSPFields and KSPActions and intercept start/end that way but it is not the cleanest solution.

If squad doesn't care to help stock work with mods why waste time trying to make mods work with stock. IR parts should be the standard for moving parts with FAR. If squad doesn't care to build in easy support I would just drop it. Pretend they don't exist. My 2c