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

[navot]

Thanks for the help with the config file. Now the changes do show up in the configcache file.

Unfortunately, the mesh still isn't voxelised. Here are the Logs created by FAR after creating meshes and calling "GeometryPartModuleRebuildMeshData":
 

[FAR v0.15.10.1] Decoupler.2 - mesh build info:
     Meshes: Decoupler_2
     No renderer found: COL0, COL1, COL2, COL3
[FAR v0.15.10.1] Decoupler.2 - mesh build info:
     Meshes: Decoupler_2, COL0, COL1, COL2, COL3
     No renderer found: COL0, COL1, COL2, COL3
[FAR v0.15.10.1] Decoupler.2 - mesh build info:
     Meshes: Decoupler_2
     No renderer found: COL0, COL1, COL2, COL3
[FAR v0.15.10.1] Decoupler.2 - mesh build info:
     Meshes: Decoupler_2, COL0, COL1, COL2, COL3
     No renderer found: COL0, COL1, COL2, COL3
[FAR v0.15.10.1] Decoupler.2 - mesh build info:
     Meshes: Decoupler_2
     No renderer found: COL0, COL1, COL2, COL3
[FAR v0.15.10.1] Decoupler.2 - mesh build info:
     Meshes: Decoupler_2, COL0, COL1, COL2, COL3
     No renderer found: COL0, COL1, COL2, COL3
[FAR v0.15.10.1] Updating __A
[FAR v0.15.10.1] liquidEngine2 - mesh build info:
     Meshes: engine, obj_gimbal
[FAR v0.15.10.1] Clearing visual voxels
[FAR v0.15.10.1] Voxel Element CrossSection Area: 0.00202024684491434

[FAR v0.15.10.1] Std dev for smoothing: 3 voxel total vol: 22.7010875940323 filled vol: 5.99027710613602

[FAR v0.15.10.1] Voxelization Time (ms): 147

I looked at the hierarchy [Image], and the COL0 - COL3 are the stock colliders of the decoupler.
I think the "No renderer found" is because the COL0-COL3 colliders also have a MeshFilter, but no MeshRenderer. This shouldn't have anything to do with my meshes not working, since they get voxelised fine.

Any ideas why my mesh and meshcolliders don't show up there?
Is there any additional info I could provide to pinpoint the issue?

[dkavolis]

1 hour ago, navot said:

Thanks for the help with the config file. Now the changes do show up in the configcache file.

Unfortunately, the mesh still isn't voxelised. Here are the Logs created by FAR after creating meshes and calling "GeometryPartModuleRebuildMeshData":
 

[FAR v0.15.10.1] Decoupler.2 - mesh build info:
     Meshes: Decoupler_2
     No renderer found: COL0, COL1, COL2, COL3
[FAR v0.15.10.1] Decoupler.2 - mesh build info:
     Meshes: Decoupler_2, COL0, COL1, COL2, COL3
     No renderer found: COL0, COL1, COL2, COL3
[FAR v0.15.10.1] Decoupler.2 - mesh build info:
     Meshes: Decoupler_2
     No renderer found: COL0, COL1, COL2, COL3
[FAR v0.15.10.1] Decoupler.2 - mesh build info:
     Meshes: Decoupler_2, COL0, COL1, COL2, COL3
     No renderer found: COL0, COL1, COL2, COL3
[FAR v0.15.10.1] Decoupler.2 - mesh build info:
     Meshes: Decoupler_2
     No renderer found: COL0, COL1, COL2, COL3
[FAR v0.15.10.1] Decoupler.2 - mesh build info:
     Meshes: Decoupler_2, COL0, COL1, COL2, COL3
     No renderer found: COL0, COL1, COL2, COL3
[FAR v0.15.10.1] Updating __A
[FAR v0.15.10.1] liquidEngine2 - mesh build info:
     Meshes: engine, obj_gimbal
[FAR v0.15.10.1] Clearing visual voxels
[FAR v0.15.10.1] Voxel Element CrossSection Area: 0.00202024684491434

[FAR v0.15.10.1] Std dev for smoothing: 3 voxel total vol: 22.7010875940323 filled vol: 5.99027710613602

[FAR v0.15.10.1] Voxelization Time (ms): 147

I looked at the hierarchy [Image], and the COL0 - COL3 are the stock colliders of the decoupler.
I think the "No renderer found" is because the COL0-COL3 colliders also have a MeshFilter, but no MeshRenderer. This shouldn't have anything to do with my meshes not working, since they get voxelised fine.

Any ideas why my mesh and meshcolliders don't show up there?
Is there any additional info I could provide to pinpoint the issue?

The first line outputs all transform names used for voxelization, either meshes or colliders. The "No renderer found" is for debug purposes only.

Try reparenting your meshes to the part root transform. You can get it by calling "Part.FindModelComponent<Transform>()", FAR uses a similar method to find transforms for voxelization.

[navot]

15 minutes ago, dkavolis said:

The first line outputs all transform names used for voxelization, either meshes or colliders. The "No renderer found" is for debug purposes only.

Try reparenting your meshes to the part root transform. You can get it by calling "Part.FindModelComponent<Transform>()", FAR uses a similar method to find transforms for voxelization.

This fixed it.

This green line is what you would expect from a hollow part, right?

Thank you.

[dkavolis]

11 minutes ago, navot said:

This fixed it.

This green line is what you would expect from a hollow part, right?

Thank you.

Yeah but it seems like the shroud would not provide protection from the airstream. You should expect a constant cross section instead. Try voxelizing with colliders enabled. It might be that your mesh shell is so thin, it's ignored by FAR.

[navot]

I think the bump comes from the Engine. Also, it's smooth if there is another part covering the decoupler from the bottom

[dkavolis]

Ferram Aerospace Research v0.15.11.0 "Mach"

Chute staging now works with stage lock (#68)
Fix German localization formatting (#70, @HebaruSan)
Greatly improve stable angle of attack solver in stability derivative calculation, now works for all cases where stable angle of attack exists and converges faster (#65)
Fix aerodynamic torque simulation and expose total aerodynamic force and torque through API (#22, @BenChung)
Shaders are now platform specific (#60)
Now really fixed ocassional NRE when cleaning up debug voxels (#59)
Fix unsubsribing correct method from GameEvents.onGUIEngineersReportDestroy in EditorGUI (#58)
Fix assymetrical voxelization on some Mk2/Mk3 adapters #56 (#57)
Cache some Unity properties for performance reasons (#53)
Fix Runge Kutta method in transient simulation (#50)
Fix part tinting not cleared after last tint option is disabled (#49)

[dkavolis]

Ferram Aerospace Research v0.15.11.1 "Mach"

Fix #72 (#73)

[klgraham1013]

Thanks for keeping this going.

[Zuthal]

On 5/31/2019 at 10:45 PM, Svm420 said:

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

Problem is, IR parts don't work with FAR either - I have tried to make variable geometry planes with them, and they also do not behave nearly as you'd expect.

[KerbMav]

On 6/27/2019 at 4:22 PM, Zuthal said:

Problem is, IR parts don't work with FAR either - I have tried to make variable geometry planes with them, and they also do not behave nearly as you'd expect.

But putting them into a cargo hold/fairing works?

[Strait_Raider]

I'm struggling to achieve any decent amount of lift in FAR... I've got two craft in the air (see below), but only barely. The light aircraft lifts off neutrally at about 50 m/s and the twin-engine barely takes off with pitch applied at just under 60 m/s. Once in the air they climb... sort of. The engines seem to have more than enough power, despite their low top speed. They can hold either aircraft at 50-60 m/s in level flight or at pretty significant angles of attack. The wings are stock. Both craft stop climbing at just under 2500m, although they're still going about 55 m/s.

Both look like they need about 10 degrees more angle of incidence to fly level, I'm working on that now. The small plane already has some angle of incidence in the picture below. While this will make them better behaved, they still won't be able to carry anything. They're both at minimal fuel loads (about 15 minutes endurance), and won't take off with any more added. Other parts are about as light as they can be while still holding together and overall they are lighter than real-world counterparts. The wing areas are already very large for both craft, but the only solution currently seems to be to make them even larger.

I tried flaps on the smaller aircraft, but they didn't seem to impact takeoff speed or climb rate, just slightly dinged the top speed. Does anyone have any tips for increasing lift in these lower-speed designs?

 

[Svm420]

44 minutes ago, Strait_Raider said:

I'm struggling to achieve any decent amount of lift in FAR... I've got two craft in the air (see below), but only barely. The light aircraft lifts off neutrally at about 50 m/s and the twin-engine barely takes off with pitch applied at just under 60 m/s. Once in the air they climb... sort of. The engines seem to have more than enough power, despite their low top speed. They can hold either aircraft at 50-60 m/s in level flight or at pretty significant angles of attack. The wings are stock. Both craft stop climbing at just under 2500m, although they're still going about 55 m/s.

Both look like they need about 10 degrees more angle of incidence to fly level, I'm working on that now. The small plane already has some angle of incidence in the picture below. While this will make them better behaved, they still won't be able to carry anything. They're both at minimal fuel loads (about 15 minutes endurance), and won't take off with any more added. Other parts are about as light as they can be while still holding together and overall they are lighter than real-world counterparts. The wing areas are already very large for both craft, but the only solution currently seems to be to make them even larger.

I tried flaps on the smaller aircraft, but they didn't seem to impact takeoff speed or climb rate, just slightly dinged the top speed. Does anyone have any tips for increasing lift in these lower-speed designs?

 

 

Lower your wing load. If you are familiar with FAR go to the second page of the FAR analysis and check reference area. That how much area you have generating lift. Then divide mass in Kg by the area in m2. For reference here is some standard aircraft wing loads. The Cessna 172 has a wing load of ~70Kg/m2 so aim for that if you want good low speed characteristics. Right now I see you craft has a mass of ~5900kg so you'd need an area of ~85m2, 9mx9m, or ~68mx1.25m for the width of the wings you have there.

Crafts in KSP are notoriously heavy because of Kerbal/KSPs reduced scale. In stock they buff lift for the area you use so that crafts look Kerbal sized. FAR is designed where real area = real lift force. They are by design different. It takes adjustment, but can be rewarding if you appreciate the realism and depth compared to stock.

Edited July 1, 2019 by Svm420

[Strait_Raider]

1 hour ago, Svm420 said:

Lower your wing load (....)

Crafts in KSP are notoriously heavy because of Kerbal/KSPs reduced scale. In stock they buff lift for the area you use so that crafts look Kerbal sized (...)

You were exactly right. I'd figured "more wing" was the answer but couldn't figure out why my craft seemed to look proportional and match the mass of real-world planes but didn't fly like them. I didn't think about the fact that S1 is actually only 1.25m, that does throw things pretty out of whack.

Those wing loadings were 130 and 122 kg/m2, and 130 must be almost the limit of what FAR will let fly at 60 m/s. Scaled the single-engine's wings by 30% to give me 91 kg/m2, immediately improved ceiling from 2500m to 4500m, take-off speed from 50 m/s to 40 m/s, cruising speed is a hair better due to less AOA, and all handling characteristics are miles better making it much easier to fly and land.

Thanks, now I'm off to find out if flaps can actually change the coefficient of lift... they only seem to function as airbrakes for me so far.

[kcs123]

8 hours ago, Strait_Raider said:

Thanks, now I'm off to find out if flaps can actually change the coefficient of lift... they only seem to function as airbrakes for me so far.

They do. A lot. But as side efect, also increasing a drag. Therefore, both are desireable on landing as long as you have some fuel in engine to make thrust stable, to not decrease velocity below acceptable handnling values. Once you touch down runway and cut off throttle, increased drag from flaps helps a lot to stop airplane. I usually start to use wheel brakes only after slowing down to ~30 m/s using flaps only. much less sliding that wa if you have porr landing gears.

[Svm420]

@dkavolis

Do you think FAR could model/simulate boundary layer control to replicate blown flaps, or is that too complicated to model?

[dkavolis]

12 hours ago, Svm420 said:

@dkavolis

Do you think FAR could model/simulate boundary layer control to replicate blown flaps, or is that too complicated to model?

Only if you or someone else can find some simple models how blowing affects transition Reynolds number and stall. Simulation is out of the scope for real time computations, even CFD can struggle with boundary layers.

[Bla Bla]

On 7/1/2019 at 6:38 AM, Svm420 said:

Crafts in KSP are notoriously heavy because of Kerbal/KSPs reduced scale. In stock they buff lift for the area you use so that crafts look Kerbal sized. FAR is designed where real area = real lift force. They are by design different. It takes adjustment, but can be rewarding if you appreciate the realism and depth compared to stock.

I see! So this is why crafts that have only minimal part clipping still have so hugely different behaviours with or without FAR! It is much more simple that what I thought!

For instance, a plane created with FAR will easily take-off at 40 m/s when the mod is off, but it's take-off speed will be around 90 m/s with the mod on. Manoeuverability is also vastly different with the two aerodynamic models for the same control surfaces area... Similarly the drag with FAR will be greatly reduced for the same craft. I once created a reusable lifter for Eve that punched quite greatly the thick atmosphere with FAR, but couldn't get nearly high enough to fulfill it's role with the stock model. So on one hand the smaller area lift (and drag) of FAR might greatly increase the engineering challenge and wing area needed of making a slow moving plane (like a seaplane), but on the other hand it feels almost cheaty compared to stock for making rockets or plane applications where drag is a bigger concern than lift...

If you are correct, most of the disbalance between the two aerodynamic models then (must) simply come from this single area lift variable... The rest of it being of course precisely what we expect and love from a mod that enhance the aerodynamic model such as FAR. ^^

I doubt that Squad would change it's lift area value to be closer to the real life deal. Now that FAR is forked, couldn't it be possible then to have a version where the lift area value is more similar to that of the stock model?

This way the planes (or other crafts) designed with FAR wouldn't have so radically different flight characteristics when the mod is off. This would mean installing FAR would still add to the stock game : dynamic voxelization, shape related lift and drag, shock cone modelisation, stability derivatives, critical mach number, area rule curves and all... Without implying that any craft designed with FAR will work as intended only with FAR on, effectively separating the FAR crafts from the rest of the game.

I want to be clear : I'm used to FAR, I love it and mostly play with it. I'd prefer if it was Squad who choosed to change it's model to the real life values to unify the game's experience between FAR and non FAR users.

But when I think it real through, I think I give much more importance to the practicality of being able to use a craft I carefully designed with FAR even when the mod is off, and even share it as "stock" and complete challenges with it, than to know that its scale is somewhat right for human use on earth according to some value in the game's code (which is quite a niche use, isn't it?).

I'm not capable of coding that, but it'd be amazing if someone could consider making a more stock like version of FAR! Let me know what you think of that ! (maybe like this post if you agree so it'd be like a poll?)

[The-Grim-Sleeper]

I guess I am in a similar position as @Bla Bla when it comes to aircraft design, and need some pointer.

Question for the day: Where do I place flaps?
I've seen the set_Flaps and how_much_deflection options in the part-context menu and I've seen (and understand to some extent) the numbers and the 'flaps'-button on the FAR 'Stability Derivatives' screen. I know that flaps are to 'increase lift at the cost of increased drag' which in that SD-screen means 'make more negative Z_u and way more negative X_u'.
But where do I actually place those flaps and why should I decide that they are flaps and not just 'pitch controls with extra buttons that ultimately just limit their functionality'?

[kcs123]

5 hours ago, The-Grim-Sleeper said:

I guess I am in a similar position as @Bla Bla when it comes to aircraft design, and need some pointer.

Question for the day: Where do I place flaps?
I've seen the set_Flaps and how_much_deflection options in the part-context menu and I've seen (and understand to some extent) the numbers and the 'flaps'-button on the FAR 'Stability Derivatives' screen. I know that flaps are to 'increase lift at the cost of increased drag' which in that SD-screen means 'make more negative Z_u and way more negative X_u'.
But where do I actually place those flaps and why should I decide that they are flaps and not just 'pitch controls with extra buttons that ultimately just limit their functionality'?

Flaps works best if they are positioned very near, but still behind CoM. That way, they would not introduce much of undisered efect of changing pitch authority. They would probably cause some of pitching down momentum, but that should be easy to conpensate with regular pitch controls on tails. It is hard to tell how much degrees to set as it strongly depends on each craft designs and how large flap surface area is. I usualy use something between 25 to 40 degrees.

It is much easier to control craft if you have dedicated flaps control surfaces without any use for pitch/yaw/roll. Set all pitch/yaw/rolls of regular controls to zero and use it only as flaps to desired degree. Check out degrees of AoA for leveled flight when you use flaps. Should be lower than without flaps. Set max deflection that would give you maximum lift(lowest possible AoA on leveled flight) that would not cause "red" stability derivatives and would not cause too much pitch down momentum that is hard to conpensate with other control sufaces.

I usually use slightly lower deflection angle than max benefit and reposition main wing slightly closer or further from CoM until I got desired effect in flight.
But, craft design questions are better to be asked/answered in FAR craft repository thread.

[Beetlecat]

On 6/23/2019 at 3:29 AM, dkavolis said:

Fix #72 (#73)

This is probably funnier to me at the moment than it actually is.

[infinite_monkey]

I need some advice for parachutes - I have an Mk16 and two Mk12-R chutes on my vessel (I installed ReStock explicitly for the pretty chutes, not sure if they are different in size). All 3 chutes keep clipping into each other, so the effective area is basically the same as with just the Mk16 chute. Is there a way to make the chutes spread out?

[Jognt]

On 7/9/2019 at 5:01 PM, Bla Bla said:

I see! So this is why crafts that have only minimal part clipping still have so hugely different behaviours with or without FAR! It is much more simple that what I thought!

For instance, a plane created with FAR will easily take-off at 40 m/s when the mod is off, but it's take-off speed will be around 90 m/s with the mod on. Manoeuverability is also vastly different with the two aerodynamic models for the same control surfaces area... Similarly the drag with FAR will be greatly reduced for the same craft. I once created a reusable lifter for Eve that punched quite greatly the thick atmosphere with FAR, but couldn't get nearly high enough to fulfill it's role with the stock model. So on one hand the smaller area lift (and drag) of FAR might greatly increase the engineering challenge and wing area needed of making a slow moving plane (like a seaplane), but on the other hand it feels almost cheaty compared to stock for making rockets or plane applications where drag is a bigger concern than lift...

If you are correct, most of the disbalance between the two aerodynamic models then (must) simply come from this single area lift variable... The rest of it being of course precisely what we expect and love from a mod that enhance the aerodynamic model such as FAR. ^^

I doubt that Squad would change it's lift area value to be closer to the real life deal. Now that FAR is forked, couldn't it be possible then to have a version where the lift area value is more similar to that of the stock model?

This way the planes (or other crafts) designed with FAR wouldn't have so radically different flight characteristics when the mod is off. This would mean installing FAR would still add to the stock game : dynamic voxelization, shape related lift and drag, shock cone modelisation, stability derivatives, critical mach number, area rule curves and all... Without implying that any craft designed with FAR will work as intended only with FAR on, effectively separating the FAR crafts from the rest of the game.

I want to be clear : I'm used to FAR, I love it and mostly play with it. I'd prefer if it was Squad who choosed to change it's model to the real life values to unify the game's experience between FAR and non FAR users.

But when I think it real through, I think I give much more importance to the practicality of being able to use a craft I carefully designed with FAR even when the mod is off, and even share it as "stock" and complete challenges with it, than to know that its scale is somewhat right for human use on earth according to some value in the game's code (which is quite a niche use, isn't it?).

I'm not capable of coding that, but it'd be amazing if someone could consider making a more stock like version of FAR! Let me know what you think of that ! (maybe like this post if you agree so it'd be like a poll?)

Honestly? I'd LOVE the voxelized "Makes Sense™" approach to drag, but stuff like area ruling makes me feel limited due to the legoblock nature of the parts. I think there used to be a version of FAR that was greatly simplified, yet still more logical than stock, called NEAR but I might be wrong.

I hate building sweet looking rockets only to realize "oh right.. all those parts in that structural tube aren't actually shielded from drag.. because stock aero and no ModuleCargoBay..". Anything that'd address that would receive my firstborn child.¹

¹- Terms and conditions may apply.

[kcs123]

6 hours ago, infinite_monkey said:

I need some advice for parachutes - I have an Mk16 and two Mk12-R chutes on my vessel (I installed ReStock explicitly for the pretty chutes, not sure if they are different in size). All 3 chutes keep clipping into each other, so the effective area is basically the same as with just the Mk16 chute. Is there a way to make the chutes spread out? 

Real chute versions ? Only real chutes work properly with FAR. Anyhow, for those, there is option under action group page. When you click on real chute part while having action page opened, you got bunch of other stuff to customize, like chute material, altitude or preassure deployment, pre-deployment speed, number of chutes inj pack etc. Among those options there should be spreading on angle too. But can't tell for sure if spreading on angle is available for all chute parts from top of my head.

[Agustin]

Is it safe to change some parameters on the gui to save performance?  What could I change to do this? Thanks...

[Bla Bla]

12 hours ago, Jognt said:

Honestly? I'd LOVE the voxelized "Makes Sense™" approach to drag, but stuff like area ruling makes me feel limited due to the legoblock nature of the parts. I think there used to be a version of FAR that was greatly simplified, yet still more logical than stock, called NEAR but I might be wrong.

I hate building sweet looking rockets only to realize "oh right.. all those parts in that structural tube aren't actually shielded from drag.. because stock aero and no ModuleCargoBay..". Anything that'd address that would receive my firstborn child.¹

¹- Terms and conditions may apply.

That's not exactly what I meant: I really love FAR in all of its complexity. But I am really annoyed by the fact that planes with no part clipping (where the voxelization shouldn't really change the drag compared to stock) will still have a huuuuge difference in behavior between FAR and stock, separating the crafts between two irreconciliable worlds : FAR and stock : crafts created with FAR will perform poorly (and always very differently) with stock and vice-versa.

This is not due to the voxelization (mainly), but mostly to a single number apparently : the lift provided per square meter of (wing) area has been buffed up by Squad in the stock model in order to create earth like looking planes at the scale of kerbal pilots (who are much smaller than humans). Whereas the Newton/m² lift per area value of FAR is not buffed, so it is smaller. THIS is the main reason why a stock plane usually doesn't have enough wing area to lift off with FAR and will sink into the air, and why a craft in FAR will also experience much less drag than in stock (again, I am not talking about the voxelization).

It seems to me that modifying that single value in FAR to be closer to the stock one should be quite easy, and would allow the crafts designed with FAR to perform much more similarly in stock when the mod is off, thus reuniting the FAR and non FAR users when it comes to sharing crafts ! And while retaining ALL the features of FAR when the mod is on, including the voxelization and the rest. As a side note, FAR rockets wouldn't be so cheated anymore due to a decreased drag for the same diameter (as they don't care about reduced lift anyway)...

It would certainly be great to have the real life N/m² value with FAR when using realism overhaul... But with FAR alone, I don't see the point for not using the same buffed value than Squad, appart from segregating FAR users from the rest of the players...

 

Edited July 20, 2019 by Bla Bla