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

[dkavolis]

19 hours ago, Kroslev Kerman said:

I dont really understand this mod so the Heavy Aerodynamic stress you mean Max Q or when you pitch too hard right?

The latter, heavy aerodynamic stress means large aerodynamic forces on your vehicle which for aircraft happens when the airstream hits it at a large angle. Max Q is only relevant for rockets.

2 hours ago, Gordon Dry said:

I tried the latest repo from 2 hours ago - with Procedural Fairings.

No chance. I even set the start of the gravity turn (MechJeb) at 12 km / 300 m/s.

Too much of a drag from the top. And the fairing is not too blunt.

It's like the whole rocket is "too light" ...

No idea, sorry. PF works as it should on my install. Next time please provide logs and any other information that might be relevant (screenshots, steps to reproduce, save files, craft files, mod list).

 

[Hodo]

On 11/17/2018 at 6:54 PM, Kroslev Kerman said:

I dont really understand this mod so the Heavy Aerodynamic stress you mean Max Q or when you pitch too hard right?

To give you a real world example.   Get in a car have someone else drive, sit in the passenger seat and stick your hand out the window with your palm facing the front of the car.   While stationary you feel nothing.   But once the car is moving you start to feel the air.   When you hit about 50mph (80KM/H) you start to feel like something is pushing your hand back.   If you continue to about 100mph you will feel like your arm is about to break, this is Max Q.   The maximum pressure you can take before the craft fails.  

[Gordon Fecyk]

On ‎11‎/‎18‎/‎2018 at 10:34 AM, Gordon Dry said:

I tried the latest repo from 2 hours ago - with Procedural Fairings. No chance. I even set the start of the gravity turn (MechJeb) at 12 km / 300 m/s.

Too much of a drag from the top. And the fairing is not too blunt. It's like the whole rocket is "too light" ...

I've had this happen with stock fairings and the official FAR on KSP 1.3.1. I've had to take care to keep my fairings as narrow as possible to avoid adding drag to the top of the rocket. If they are a close match to the diameter of what's underneath the fairing, they seem to work better.

This problem was much more pronounced in my Purple Space Program playthrough, with Eve's thicker air, but it also happens back at Kerbin. I think that's just the centre of drag being ahead of the centre of mass as a result of the fairing being too wide.

[Maeyanie]

10 hours ago, Gordon Fecyk said:

I've had this happen with stock fairings and the official FAR on KSP 1.3.1. I've had to take care to keep my fairings as narrow as possible to avoid adding drag to the top of the rocket. If they are a close match to the diameter of what's underneath the fairing, they seem to work better.

This problem was much more pronounced in my Purple Space Program playthrough, with Eve's thicker air, but it also happens back at Kerbin. I think that's just the centre of drag being ahead of the centre of mass as a result of the fairing being too wide.

 

One trick that real-world rocket designers do to make them less unstable is put the denser of their fuel or oxidizer near the front of the rocket. That's not really an option in KSP (technically possible with RealFuels or similar, but complicated to get the ratio right), but if you have more than one tank on your first stage, setting flow priorities to empty starting from the back gives a similar stabilizing effect. I don't see too many people using this, but it can help quite a bit for rockets that normally somewhat aerodynamically unstable... won't save the very unstable ones though.

[Gordon Dry]

6 hours ago, Maeyanie said:

setting flow priorities to empty starting from the back gives a similar stabilizing effect

tbh that's what I'm doing for nearly two years (incl. the hiatus times).

I use GPOSpeedFuelPump and the lower the stage, the higher the number.

[Freds]

FAR  for 1.5.1?  I think it's time to re-install Kerbal!!! Thanks!

[AloE]

 

On 11/22/2018 at 3:02 PM, Gordon Dry said:

tbh that's what I'm doing for nearly two years (incl. the hiatus times).

I use GPOSpeedFuelPump and the lower the stage, the higher the number.

Do the "debug voxels" reveal anything strange?  For example, a part does not show any pink dots thus suggesting it is not seen by FAR? 

I am interested if anyone finds any FAR related behavior that is different from 1.3.1...

I decided to post in case newer users of FAR read this thread rather than searching the original FAR thread since I get surprised occasionally like with KerbalEDU tool holograms being detected by FAR as a physical object as in the following image.

Spoiler

In my case, I excluded the KerbalEDU Force Indicator in FARPartModuleTransformExceptions.cfg

On 11/21/2017 at 4:08 AM, SuicidalInsanity said:

2 ways of excluding something from the FAR aero calcs. First way is via the FARPartModuleTransformExceptions.cfg. This is a more selective method, and allows hiding select segments of a part from the Aero calcs - Parachute canopies/firespitter propeller blades/etc, but requires said segment to have a PartModule referencing it.
Second way is the nuclear option, via !MODULE[GeometryPartModule] {}, which completely removes the entire part from all aero calculations.

 

Edited November 29, 2018 by AloE
clarity & part exclusion quote

[Agustin]

Was hving lag

Edited December 3, 2018 by Agustin

[Agustin]

Nevermind. Scrapyard i think was the one causing lag. Far just sends messges to log but not necessarily causes lag. Removing scrapyard did it.

Edited December 3, 2018 by Agustin

[KerbalSofaProgram]

hey thanks for keeping far up! i had never used it before and i wasnt going into all the recompiling of the outdated version myself to try it out. im glad you did though because its waaaay better than stock

anyways ive got a request for a small fix, and really im not even sure if its ferram... but im almost sure. it seems like far is loading a plugin or what have you for realchutes even though i dont have realchutes. effectively all this results in is disabling the chute spread option but that hurts me pretty bad. maybe im ocd but those chutes clipping into one another kills me. anyways if anyone can guide me in the right direction itd be greatly appreciated.

[Maeyanie]

On 12/3/2018 at 5:03 PM, KerbalSofaProgram said:

hey thanks for keeping far up! i had never used it before and i wasnt going into all the recompiling of the outdated version myself to try it out. im glad you did though because its waaaay better than stock

anyways ive got a request for a small fix, and really im not even sure if its ferram... but im almost sure. it seems like far is loading a plugin or what have you for realchutes even though i dont have realchutes. effectively all this results in is disabling the chute spread option but that hurts me pretty bad. maybe im ocd but those chutes clipping into one another kills me. anyways if anyone can guide me in the right direction itd be greatly appreciated.

Yes, FAR includes a "RealChutes Lite" plugin, due to the fact regular stock parachutes don't work in it. You could remove this from your FAR installation, but while that would give you nice spread parachutes, they wouldn't actually slow you down... which might kill you a little more literally. 

[dkavolis]

FAR seems to work on KSP 1.6 with the latest versions of MFI and MM (updated for KSP 1.5). If anyone wants to test for bugs, you can find DLLs on Github PR.

[KerbalSofaProgram]

On 12/4/2018 at 5:17 PM, Maeyanie said:

Yes, FAR includes a "RealChutes Lite" plugin, due to the fact regular stock parachutes don't work in it. You could remove this from your FAR installation, but while that would give you nice spread parachutes, they wouldn't actually slow you down... which might kill you a little more literally. 

i realized that might be the case after i posted this. then i effectively made the same request on the realchutes page... but as far as the chute spread vs. chute function, kerbals arent cheap, but they apparently are more than willing to ride any death coaster i can make.

[Pds314]

Recommend we all thumbs up this thread because we've now been saved from having to manually patch it with ExtremeTrader's 0.15.9.4.x updates and of course from some of the error spam and pink UI. Full support for this!

@dkavolis Thank you for this blessed thread.

@ExtremeTrader Thank you for your work in keeping FAR usable in the current KSP versions as well.

@ferram4 Thank you for making FAR to begin with, and dealing with an amount of people's issues and bugging you for updates that frankly would probably warrant several restraining orders for serial harassment on the part of the community. TBH this is the most important KSP mod hands down. I have used FAR for stuff beyond KSP, up to and including designing and testing real life RC gliders. I know there might be aero simulations out there that are more realistic, but I have yet to see one of them that works in anything like real time, nor in a flight sim that lets you strap flexible blended multiplane ring wings on an MBT and still handles the aero sensibly. Most other sims I've seen use something more like drag cubes or even whole-aircraft drag cubes, and I think voxelFAR is probably one of the most impressive pieces of realtime physics simulation technology I have ever seen.

Edited December 22, 2018 by Pds314

[Pds314]

Question about 1.6-compatibility, do I need to tell it it's compatible or just update KSP and MM and MFI?

[dkavolis]

3 hours ago, Pds314 said:

Question about 1.6-compatibility, do I need to tell it it's compatible or just update KSP and MM and MFI?

Just replace FAR DLLs with the ones from #12 and it will work, MM and MFI for KSP 1.5 work on KSP 1.6. I'm also trying out a more relaxed compatibility checker since Squad has done a great job at preserving mod compatibility between minor KSP versions so those DLLs will work on KSP 1.4-1.6. I'll do a release when a few of the open PRs are merged in.

[DasCostaNix]

On 12/20/2018 at 9:50 PM, dkavolis said:

FAR seems to work on KSP 1.6 with the latest versions of MFI and MM (updated for KSP 1.5). If anyone wants to test for bugs, you can find DLLs on Github PR.

Even with 125 other Mods, everything seems just fine. No problems so FAR.

[kcs123]

@dkavolis, does you know what things breaks FAR when you use parts from Airplane Plus mod ?

I know that wing parts and control surfaces need extra piece of code in config files, for FAR to properly calculate lift. But, strange things is that even if you use only cockpit and fuselage parts it also breaks FAR somehow. Anyhow, that was issue few KSP versions ago, haven't tried yet if same things happen with your forked version of FAR and latest KSP.

First sign that something is wrong when you use those parts is that in SPH/VAB editor you get stock balls for lift with arrow. You should see jsut blue ball without arrow with FAR. Another issue is that while you still can fly crafts with those parts, drag is not properly calculated, you got NaNs in FAR data window while in flight scene. Nothing is catched in log files regarding this, so would be necessary to add some debug messages in code to be able to catch this when something breaks FAR calculation.

[dkavolis]

19 minutes ago, kcs123 said:

@dkavolis, does you know what things breaks FAR when you use parts from Airplane Plus mod ?

I know that wing parts and control surfaces need extra piece of code in config files, for FAR to properly calculate lift. But, strange things is that even if you use only cockpit and fuselage parts it also breaks FAR somehow. Anyhow, that was issue few KSP versions ago, haven't tried yet if same things happen with your forked version of FAR and latest KSP.

First sign that something is wrong when you use those parts is that in SPH/VAB editor you get stock balls for lift with arrow. You should see jsut blue ball without arrow with FAR. Another issue is that while you still can fly crafts with those parts, drag is not properly calculated, you got NaNs in FAR data window while in flight scene. Nothing is catched in log files regarding this, so would be necessary to add some debug messages in code to be able to catch this when something breaks FAR calculation.

Sorry, I have never tried Airplane Plus. I've created an issue #16 to keep track of it. The issue with cockpits and fuselages should be with MM configs, they are probably not patched currently. Other configs for FAR should come with the mod and not FAR itself. See https://github.com/ferram4/Ferram-Aerospace-Research/wiki/Deriving-FAR-values-for-a-wing-using-Blender-2.7 for more information.

[theonegalen]

@kcs123

I have some FAR configs for APP wings, but they're on my computer at home. I won't be back there for about a week.

[kcs123]

4 hours ago, theonegalen said:

@kcs123

I have some FAR configs for APP wings, but they're on my computer at home. I won't be back there for about a week.

No worries, I have not much free time for KSP recently, so no rush with this. I almost exclusively use wings from B9PW for aircrafts. For rockets, stock wings and fins suffice for me on first rocket stage. Other users who use more wings from APP would benefit more from your configs. Thanks anyway for this. Might be good idea to send PR with those configs on APP github when you get time.

@dkavolis, yes I know about that blender/wing info that need to be created for FAR. However, have no idea why cockpits and fuselage a-like parts from this mod cause issue. Tried to compare configs from APP parts with similar parts from other mods, but that ways not give me any clue what kind of info is missing for APP parts. That leaded me to speculation that something with coliders is different, but again have no idea if coliders can be handled trough config files or need to be handled in blender and exported for unity usage.

Thanks for opening issue, once we know what cause this, it will be easier to create proper config files or MM patches later on.

EDIT:

I see that you try to handle ground effect in FAR. IIRC Ferram was not handling this because it would not be accurate  when you are near sloped surface, like taking turns very close to mountains, for example. Or if you are on some angle of attack instead of perfectly normal with wings against ground/surface.

So, I was thinking if it can be handled in similar way as shadows are casted/rendered. Not exactly shadow, but whole code should be similar. I will try to explain in semi pseudo code.

• Set a fake light source above plain, distance should depend on wingspan
• do raycasting only on each frame downwards to detect if you are near ground, so ground effect calculation does not need to be calculated at all. Raycasting is pretty cheap on CPU usage, so that alone would not cause performance issue. Have no idea what would be proper height when ground effect calculation should start, more info about it is needed, but my guess is that is same as wingspan length or half of wingspan length.
• instead of calculating ground effect from wings geometry, use projected image on surface, or fake shadow from that mentioned "light source". Probably not most accurate, but should be much closer to real thing when comes to mentioned issues near mountain or sloped ground
• for more simple calculation and being easier on CPU load, you can assume that whatever raycasting result gives you, that area below aircraft is perfectly flat for that frame of calculation. Area for calculation on surface where "shadow" is projected should be simple square of wingspan X aircraft lenght.

Probably not the best way to do this, but in games you need to fake a lot of things. Of course that "shadow" is not need to be rendered on screen at all, but calculation is very similar. I was thinking about it as watching aircraft shadow at noon while aircraft si on the ground. Shadow from wings is biggest when aircraft is close to the ground, same as ground effect lift force (assuming that aircraft is moving with enough speed). As aircraft climbs up, shadow becomes smaller and smaller same as ground effect too.

I hope that I was able to describe my thoughts properly, becasue english is not my native language.

Edited December 23, 2018 by kcs123
ground effect thoughts.

[Critter79606]

I'm having some issues with some wings giving lift correctly and other not having any lift with FAR.  I'm running "Lighthihll" on 1.5.1.

FAT-T3R has good lift

But most of the other Fat* (Fat-455 below) along with OPT, C7 and even Squad give no lift.

I've looked at the original config files, and don't see anything wrong, and am wondering what I'm missing that makes some wings work and other don't.

Even things that should be lifting bodies don't have lift.

I installed from CKAN and have MFI 1.2.6 as well.

Logs are here https://drive.google.com/uc?export=view&id=1BGjsEMdhVlNGw8Sln2ofYa2brHJADVF9

Thanks!

EDIT:

Ok, I figured out what is missing on the parts, I just don't know how to fix it.

In the parts list, the ones that work have the "Lifting Surface" "Relative wing area: x".  On the ones that don't are missing this entry on the part.

Edited December 23, 2018 by Critter79606

[dkavolis]

33 minutes ago, Critter79606 said:

I'm having some issues with some wings giving lift correctly and other not having any lift with FAR.  I'm running "Lighthihll" on 1.5.1.

FAT-T3R has good lift

But most of the other Fat* (Fat-455 below) along with OPT, C7 and even Squad give no lift.

I've looked at the original config files, and don't see anything wrong, and am wondering what I'm missing that makes some wings work and other don't.

Even things that should be lifting bodies don't have lift.

I installed from CKAN and have MFI 1.2.6 as well.

Logs are here https://drive.google.com/uc?export=view&id=1BGjsEMdhVlNGw8Sln2ofYa2brHJADVF9

Thanks!

EDIT:

Ok, I figured out what is missing on the parts, I just don't know how to fix it.

In the parts list, the ones that work have the "Lifting Surface" "Relative wing area: x".  On the ones that don't are missing this entry on the part.

It seems that those parts are missing configs for FAR. FAR replaces ModuleLiftingSurface with FARWingAerodynamicModel (you can see it in FerramAerospaceResearch.cfg). In addition, kerbalEVA and a couple new parts are also missing configs. Just find all the parts that have ModuleLiftingSurface or ModuleControlSurface in your MM cache.

[dkavolis]

On 12/23/2018 at 10:29 PM, kcs123 said:

No worries, I have not much free time for KSP recently, so no rush with this. I almost exclusively use wings from B9PW for aircrafts. For rockets, stock wings and fins suffice for me on first rocket stage. Other users who use more wings from APP would benefit more from your configs. Thanks anyway for this. Might be good idea to send PR with those configs on APP github when you get time.

@dkavolis, yes I know about that blender/wing info that need to be created for FAR. However, have no idea why cockpits and fuselage a-like parts from this mod cause issue. Tried to compare configs from APP parts with similar parts from other mods, but that ways not give me any clue what kind of info is missing for APP parts. That leaded me to speculation that something with coliders is different, but again have no idea if coliders can be handled trough config files or need to be handled in blender and exported for unity usage.

Thanks for opening issue, once we know what cause this, it will be easier to create proper config files or MM patches later on.

EDIT:

I see that you try to handle ground effect in FAR. IIRC Ferram was not handling this because it would not be accurate  when you are near sloped surface, like taking turns very close to mountains, for example. Or if you are on some angle of attack instead of perfectly normal with wings against ground/surface.

So, I was thinking if it can be handled in similar way as shadows are casted/rendered. Not exactly shadow, but whole code should be similar. I will try to explain in semi pseudo code.

• Set a fake light source above plain, distance should depend on wingspan
• do raycasting only on each frame downwards to detect if you are near ground, so ground effect calculation does not need to be calculated at all. Raycasting is pretty cheap on CPU usage, so that alone would not cause performance issue. Have no idea what would be proper height when ground effect calculation should start, more info about it is needed, but my guess is that is same as wingspan length or half of wingspan length.
• instead of calculating ground effect from wings geometry, use projected image on surface, or fake shadow from that mentioned "light source". Probably not most accurate, but should be much closer to real thing when comes to mentioned issues near mountain or sloped ground
• for more simple calculation and being easier on CPU load, you can assume that whatever raycasting result gives you, that area below aircraft is perfectly flat for that frame of calculation. Area for calculation on surface where "shadow" is projected should be simple square of wingspan X aircraft lenght.

Probably not the best way to do this, but in games you need to fake a lot of things. Of course that "shadow" is not need to be rendered on screen at all, but calculation is very similar. I was thinking about it as watching aircraft shadow at noon while aircraft si on the ground. Shadow from wings is biggest when aircraft is close to the ground, same as ground effect lift force (assuming that aircraft is moving with enough speed). As aircraft climbs up, shadow becomes smaller and smaller same as ground effect too.

I hope that I was able to describe my thoughts properly, becasue english is not my native language.

There's a way to calculate ground effect approximately by using method of images and the ground as a mirror but that would require finding the reflection in the ground and recomputing wing interactions for each part each frame and that is very likely to kill frame rate near the ground. Screening interactions between physical and reflected parts may alleviate it a bit. I agree with ferram and won't add a highly inaccurate feature that very few people will use anyway. Unless anyone can find a CPU cheap implementation that will be at least approximate, ground effect is not planned.

 

In other news:

Ferram Aerospace Research v0.15.9.6 "Lin"

Note for Kopernicus users: DO NOT overwrite MFI that comes with Kopernicus since it is locked to that particular version

FAR is out for KSP 1.4-1.6 this time (one DLL to rule them all!) since RO is pushing for KSP 1.4.5 release.

Update for KSP 1.6
Update to MM 3.1.2
Update to MFI 1.2.6

Mainly a release for RO
Trying out enabling FAR for KSP 1.4-1.6

Much nicer looking anti-aliased line plots
Fix NRE when Trajectories tried to access simulation before the vessel was initialized
Changed icon to "FARc" to avoid confusion with the original FAR
Fix MM pass in a config that is only used on first start of FAR
Fix NRE when trying to save stability augmentation settings on closing KSP

Get it from Github or CKAN.

Edited December 25, 2018 by dkavolis

[Critter79606]

16 hours ago, dkavolis said:

It seems that those parts are missing configs for FAR. FAR replaces ModuleLiftingSurface with FARWingAerodynamicModel (you can see it in FerramAerospaceResearch.cfg). In addition, kerbalEVA and a couple new parts are also missing configs. Just find all the parts that have ModuleLiftingSurface or ModuleControlSurface in your MM cache.

Thanks for the explanation dkavolis.  At least I understand why it's not working.  Looks like I have 109 parts that don't have configs.  Is there any documentation on calculating conversions?  Maybe I could take some time and try to convert some of them (If my pea brain can figure it out).