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

[ephemer3al]

Yes but only wing parts are meant to be wings in crafts and produce the expected amount of lift.

afaik it's how FAR accounts for turbulent flow, what happens around the body/frame is fairly simple but stuff around the wings is more taxing to simulate

[dkavolis]

4 hours ago, KerbMav said:

But I thought lifting bodies were a thing?

Lifting body comes from accounting for the shape of the vehicle

1 hour ago, ephemer3al said:

Yes but only wing parts are meant to be wings in crafts and produce the expected amount of lift.

afaik it's how FAR accounts for turbulent flow, what happens around the body/frame is fairly simple but stuff around the wings is more taxing to simulate

Yeah, FAR not only has to calculate lift of each wing part but also account for interactions between each wing. The code is a bit of a spaghetti mess in this area.

[Dundrogen]

On 11/1/2018 at 9:38 AM, dkavolis said:

Emergent Fairings and Cargo Bays - The voxel model method FAR uses allows for the actual shape of the vehicle to play a role in how lift and drag are applied. Build a hollow shell, and close it up, and everything inside it will be protected from the airflow as it

Hi @dkavolis, i wanted to create a set of custom parts to complement custom bays/fairings and what not. I was wanting to clarify if the voxel model used by FAR calculates the shape of the collider mesh of parts to accomplish this feature.

This is so i can design and implement the mesh shape and orientation of said custom parts to function well with FAR. 

Thanks for keeping FAR alive. This mod is life. 

[dkavolis]

10 hours ago, Dundrogen said:

Hi @dkavolis, i wanted to create a set of custom parts to complement custom bays/fairings and what not. I was wanting to clarify if the voxel model used by FAR calculates the shape of the collider mesh of parts to accomplish this feature.

This is so i can design and implement the mesh shape and orientation of said custom parts to function well with FAR. 

Thanks for keeping FAR alive. This mod is life. 

It should use colliders as default but you can change the behaviour with `forceUseColliders` or `forceUseMeshes`. You will have to enable debug voxels in game to see if it works or not. You might need to set `rebuildOnAnimation` to `true` in case the voxels don't update on animations.

[Dundrogen]

1 hour ago, dkavolis said:

It should use colliders as default but you can change the behaviour with `forceUseColliders` or `forceUseMeshes`. You will have to enable debug voxels in game to see if it works or not. You might need to set `rebuildOnAnimation` to `true` in case the voxels don't update on animations.

Thanks for the info. I'll definitely look into this. Very interested in custom ingame interiors using structural parts with robotic parts but keeping internal components of the hull/shell away from atmospheric drag as you'd expect if you closed something up inside an exterior cover. Awesome stuff dude. Keep up the good work. 

[CorvusCorax]

On 11/14/2019 at 11:00 PM, dkavolis said:

Lifting body comes from accounting for the shape of the vehicle

Yeah, FAR not only has to calculate lift of each wing part but also account for interactions between each wing. The code is a bit of a spaghetti mess in this area.

Just so I understood correctly, FAR uses the shape of the whole craft - including body - to calculate the translational static lift when the craft is moving through the air. But only "wing type" surfaces (including ailerons and similar control surfaces) are used to calculate dynamic lift that happens when parts move relative to each other, one part affects the airflow of another, etc...

so FAR would not change the lift calculated by a craft body whether it's rotating around an axis or not (regardless of wether rotation is caused by robotics or control surface deflection or simply the whole craft is rotating) and in each timestep only the current orientation relative to the stationary air around the craft is taken into account, not localized differences in airspeed due to part or craft rotation.

but for wing surfaces, including ailerons, this "local airflow" is taken into account both to calculate "dynamic lift" and effects like increased lift on the downwards moving wing during a roll manouver, as well as shadowing effects such as a deep stall in a T-elevator setup when the horizontal stabilizer ends up shadowed by main wings.

if I got that right, then FAR is even more awesome than I thought

If that's the case, I assume one probably could write a part-mod that just adds the "i am a wing" property to everything - in order to get full dynamic airflow calculation - at the cost of horrible performance impact. is that correct?

 

[KerbMav]

On 11/18/2019 at 11:00 AM, dkavolis said:

You will have to enable debug voxels in game to see if it works or not. You might need to set `rebuildOnAnimation` to `true` in case the voxels don't update on animations.

... I can activate a visualization of what FAR does in game ... ?

[dkavolis]

2 hours ago, CorvusCorax said:

Just so I understood correctly, FAR uses the shape of the whole craft - including body - to calculate the translational static lift when the craft is moving through the air. But only "wing type" surfaces (including ailerons and similar control surfaces) are used to calculate dynamic lift that happens when parts move relative to each other, one part affects the airflow of another, etc...

so FAR would not change the lift calculated by a craft body whether it's rotating around an axis or not (regardless of wether rotation is caused by robotics or control surface deflection or simply the whole craft is rotating) and in each timestep only the current orientation relative to the stationary air around the craft is taken into account, not localized differences in airspeed due to part or craft rotation.

but for wing surfaces, including ailerons, this "local airflow" is taken into account both to calculate "dynamic lift" and effects like increased lift on the downwards moving wing during a roll manouver, as well as shadowing effects such as a deep stall in a T-elevator setup when the horizontal stabilizer ends up shadowed by main wings.

if I got that right, then FAR is even more awesome than I thought

If that's the case, I assume one probably could write a part-mod that just adds the "i am a wing" property to everything - in order to get full dynamic airflow calculation - at the cost of horrible performance impact. is that correct?

 

Partly, some animations cause voxelization to be recomputed which is then used to update shape parameters. Voxelization takes multiple frames to compute so it can't be used in real time in its current state, there may be improvements with jobs (and Burst when KSP includes its binaries). For this reason continuously moving parts should not trigger voxelization. FAR does not compute airflow, it's not a CFD, and the effects computed are only approximations, you might have different mileage with deep stall. You can't just set every part to wing and expect it to work out of the box. Wings use lifting line theory approximation which assumes wings are thin and requires shape parameters to be set.

1 hour ago, KerbMav said:

... I can activate a visualization of what FAR does in game ... ?

In VAB/SPH you can visualize voxels, in flight you can display force arrows and tint parts by lift, drag and stall.

[StoneWolfPC]

I'm trying to track down a potential mod problem, and I doubt it's this one, but I would love some advice.  I've rebuilt, and redesigned several craft, then cheated them into space to reenter to test this and almost EVERY craft has the same problem.........  During reentry, I'm using only sas and rcs.  I turn off all assistance from mechjeb and far.  At the first point the atmosphere thickens, sometimes on Kerbin, but WAY worse on Eve the vessel begins to violently spin (counterclockwise in all cases), but not flip.  These are not shuttles, they are reentry rockets, with the all points lined up according to many builds I've seen working (with tutorials for FAR).  They begin to spin almost as if they hit something, not slowly rotating, and then no amount of rcs thrust will slow them down.  If I have it pointed towards retrograde, it will begin spinning even wilder if I decide to do an aerodynamic reentry using only fins to the point parts fling off, as the physics can't handle what is happening (which pushes my cpu to max before it's over and drops frames to about 5 fps or so).  Mind you during this, I have usually slowed down to nearly 0 horizontal velocity, and less than 100 vertical sometimes.  I can supply logs, but do not know how to take screenshots in game.  If it's not this mod, my apologies.  I highly doubt it is, but as it's physics related from my guess, I figured where better to start?  My logs aren't showing me anything that make sense in my mind, but I'm no coder or modder.  Also, when it happens, textures at ground level will shake.  Something I didn't experience in 1.7.3 (but I didn't have FAR installed then either).  I'm on 1.8.1 on Windows 10.   Counter intuitive thought, but has anyone experienced it with a part mod?  If so, I've got a lot more digging to do (99 mods). >.<

EDIT:  I fixed it....... it was my fault.  It looked like physics but I didn't factor in that I had tail fins, instead of standard rocket fins.  When they adjusted direction to "guide" they created a spinning force........ so it hasn't got anything to do with mods and I feel dumb. lmao

Edited December 1, 2019 by StoneWolfPC
Fixed the problem, as it was a user issue.

[Braden Yonano]

Hey I just downloaded and installed this, but now elevons seem to not be working. They literally just don't move. Even the properties windows for the elevons are broken. Is there a reason for this? Note that they were working before I installed FAR, but right after i installed they stopped working.

Image of issue

[kcs123]

12 hours ago, Braden Yonano said:

Hey I just downloaded and installed this, but now elevons seem to not be working. They literally just don't move. Even the properties windows for the elevons are broken. Is there a reason for this? Note that they were working before I installed FAR, but right after i installed they stopped working.

Image of issue

That looks like messed up mod install. There should be much more options on PAW GUI, but it shows only scaling options. Based on picture I can only assume that you got TweakScale installed. It could be that TS is not installed properly or some other mod have messed things. For a better help you will need to provide log files. You can find info about that in this thread:

It also does not hurt to read how to install mods properly, regardless if you are using CKAN or manual installs. Neither of methods is not completely foolproof.

I can only suggest to do clean re-install of KSP and mods and if that does not help, provide log files for further support. It is hard for anyone to help you without those just from guessing what might be wrong.

[Cruss]

Hi! I have a (maybe) silly question lol.

I'm trying to make the Shuttle Orbiter construction kit RO compatible. Because it's pretty darn close to the real thing and compatible with 1.7.3.

Anyway, the wings in this mod don't support symmetry and rely on b9 part switch to change the orientation between left and right side wings and control surfaces.

My question is: Would this screw with how FAR treats wings and control surfaces? 

EDIT: It doesn't seem to matter

 

 

Edited December 7, 2019 by Cruss

[Cruss]

Nvm

Edited December 10, 2019 by Cruss
Found it out

[Nixod321]

Is it possible in some way to alter the NACA profile of the wings, or is it locked?

[dkavolis]

14 hours ago, Nixod321 said:

Is it possible in some way to alter the NACA profile of the wings, or is it locked?

No way to specify currently but I want to rewrite FAR to work with the job system (and burst if KSP ever uses it) so maybe in the future

[Drew Kerman]

10 hours ago, dkavolis said:

I want to rewrite FAR to work with the job system (and burst if KSP ever uses it)

are you collaborating with ferram at all? He seems to log in fairly often but never posts anymore

[dkavolis]

26 minutes ago, Drew Kerman said:

are you collaborating with ferram at all? He seems to log in fairly often but never posts anymore

No but it would make improving FAR easier

[Drew Kerman]

43 minutes ago, dkavolis said:

No but it would make improving FAR easier

try sending him a PM. He has 0 profile activity since 2018 so it's not like he's logging in to post elsewhere in the forums so I guess he's just lurking. But that's a good sign he may be interested in helping out. At the very least you guys should make sure you're both not working on the same thing he may be doing a FAR revision of his own but reluctant to announce anything and then be under pressure to release it

Edited December 13, 2019 by Drew Kerman

[Sky! (Big nerd)]

How hard would it be to add a primitive ground effect if it is not already there? 

[Chase842]

Note: I am using the latest version of FAR that is compatible with 1.7.3 (Cuz we're all still waiting on Kopernicus lol)

 I've been having an issue with center of lift not displaying correctly in the SPH, but once I launch the vessel, and then revert to SPH the center of lift is in a different location (idk if it's the correct location, or the wrong one).

An additional issue I'm having with the center of lift display in the SPH is no matter how high or low I put a set of wings, the center of lift always places itself (vertically) on (or very close to) the same vertical plane as the center of mass. This is causing an issue when trying to create center of lift below or above center of mass intentionally.

 

Are these known issues? 

Anyone know of any workarounds?

I'm a game dev(engineering mostly, plus other hats) (Not for KSP), and I work in Unity. Now most of the time I am working 70-80 hour weeks, so I don't have a ton of time to spare, but if this is something I can help fix and isn't gonna take a huge amount of time, I'd be happy to help.

It'd help if you can point me at the particular section of code that I need to fix.

Edited December 16, 2019 by Chase842

[kcs123]

2 hours ago, Chase842 said:

An additional issue I'm having with the center of lift display in the SPH is no matter how high or low I put a set of wings, the center of lift always places itself (vertically) on (or very close to) the same vertical plane as the center of mass. This is causing an issue when trying to create center of lift below or above center of mass intentionally.

Do you have only blue dot for COL or you have arrow, like in stock game without FAR. If that is the case, then you have on your craft parts that are not patched properly for FAR. Screenshot or two might explain situation better.

I have noticed few posts in PW thread and APP thread about symmetry issues, but I haven't encountered those for myself. KSP 1.7.3 with FAR seems to work just fine for me, I don't have either proper KSP 1.8.x with mods installed yet.

For coding questions, you will have to wait for someone else to answer. AFAIK, FAR code is kind of spaghetti mess that need to be refactored, so it can use some of advantages of unity game engine. See few posts above (or one-two page back) where it was explaind in better detail.

[Chase842]

@kcs123

Indeed I do not have the arrow. I wondered about that at first, but I just assumed it was a quirk of having FAR.

Edit: I just tested it with some stock only parts, and I am still having the "no arrow issue" with the center of lift dot....

Here's a picture (All stock parts too) shows both the no arrow issue and the vertical location of the center of lift not displaying correctly  :

Edited December 16, 2019 by Chase842

[dkavolis]

5 hours ago, Chase842 said:

Note: I am using the latest version of FAR that is compatible with 1.7.3 (Cuz we're all still waiting on Kopernicus lol)

 I've been having an issue with center of lift not displaying correctly in the SPH, but once I launch the vessel, and then revert to SPH the center of lift is in a different location (idk if it's the correct location, or the wrong one).

An additional issue I'm having with the center of lift display in the SPH is no matter how high or low I put a set of wings, the center of lift always places itself (vertically) on (or very close to) the same vertical plane as the center of mass. This is causing an issue when trying to create center of lift below or above center of mass intentionally.

 

Are these known issues? 

Anyone know of any workarounds?

I'm a game dev(engineering mostly, plus other hats) (Not for KSP), and I work in Unity. Now most of the time I am working 70-80 hour weeks, so I don't have a ton of time to spare, but if this is something I can help fix and isn't gonna take a huge amount of time, I'd be happy to help.

It'd help if you can point me at the particular section of code that I need to fix.

The concept of a point center of lift is wrong. In reality there are infinite number of those points all on a line that lift acts through. The choice of center of lift is arbitrary which in FAR is most likely chosen to lie on a principal axis hence why you don't see it going up or down.

The entire CoL calculation is done in https://github.com/dkavolis/Ferram-Aerospace-Research/blob/2cf406c93ac84899a2da9e667f96be05c3ea5e40/FerramAerospaceResearch/FARGUI/FAREditorGUI/EditorAeroCenter.cs#L77-L153

Edited December 16, 2019 by dkavolis

[Lisias]

On 12/16/2019 at 8:47 PM, dkavolis said:

The entire CoL calculation is done in https://github.com/dkavolis/Ferram-Aerospace-Research/blob/2cf406c93ac84899a2da9e667f96be05c3ea5e40/FerramAerospaceResearch/FARGUI/FAREditorGUI/EditorAeroCenter.cs#L77-L153

There's a potential Division by Zero on the code, at line 115.

O would replace that line to "pos /= (0 == mass ? 1 : mass) ;" or something like that. I acknowledge that highly unlikely that EditorLogic.SortedShipList would have all zero mass parts, but excrements happens and so this could would be pinpointed (wrongly) as the problem.

Shoving a more robust logic (with error handling) would tax a code where performance can be critical, so I think the stunt above is the best compromise.

[taniwha]

@Lisias: I disagree. I find it to be far better for these problems to rear their ugly heads as soon as possible, so masking over them with such bandaids is counter productive.

It's for this reason my mods (in particular, EL) almost never catch exceptions: one of I've done something wrong and need to know, the mod triggering the exception is doing something wrong and needs to be fixed (thus I need to know so I can pass the info on to the relevant developer), or the mod is doing things right but not in the unusual context I've created (thus the ref to EL) and I need to know. Although deciding between the latter two cases can be difficult, I would far rather get a pile of reports that "EL is broken" than complaints of things mysteriously failing to do anything.

Anyway, if a part's mass is 0 (let alone the entire vessel's mass), or negative masses are present, really weird things will happen whether FAR tries to mask them or not. It's just not worth cluttering up the code making it harder to read and slower. Rhinodaemons.