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

[taniwha]

@Proximity4: it does not seem that you have pressed the "sweap AoA" button, but yes, the icon is definitely broken. I installed using the zip (I don't use CKAN) and it works well.

[SpaceFoon]

10 hours ago, Proximity4 said:

Stock system isn't aerodynamic at all, just stupid multiplication of drag values. It is quite hard to build a REALLY FLYING plane with FAR but it will be very realistic. FPS will not be affected much, if you have more than 40-50 then don't worry. It is all loading the processor, if your CPU is good in single-core, then no problem

Well my SSTO just became a SSTEve.. Before I could only fly 100 m/s at sea level now I'm at about 300m/s. I had a lot of stuff in cargo bays I think is why.

Edit: Yea this doesn't seem realistic at all. This thing should not fly that good. https://imgur.com/gallery/38IXzqn Also when I hit the air brakes it slows down so fast my kerbals pass out from the g force(says 15 plus). Does FAR just not do Heisenberg airship parts or all the tweakscale I did? 

Also that craft can just coast at 50 m/s and not slow down like .01 m/s every few seconds. Literally can coast for 30 mins.

Edited February 3, 2019 by SpaceFoon
more info

[Gordon Fecyk]

On 2/2/2019 at 4:25 PM, Proximity4 said:

Hello people, how do you play with FAR since official KSP became 64-bit only? I have heard that FAR works only on 32-bit versions.

Architecture lock was removed back in the KSP 1.1 release for FAR; that was ferram4's doing a while ago and it was because of pre-1.1 KSP 64-bit being 'crash-tastic' on Windows. I'd been playing in 64-bit since KSP 1.1.3, and official releases go as far as KSP 1.3.1 64-bit.

This port to KSP 1.4 and later is also not architecture-locked. I'm using it on 1.6.1 on Eve and my planes there fly on 1.6.1 as well as they have on 1.3.1. Same goes for stock builds back at Kerbin.

As for CKAN, it's really up to dkavolis to make a repository entry. Though I've read too many horror stories of CKAN installing the wrong versions of dependencies and such. There's a big ol' warning on the first post here to make sure, if you use Kopernicus, to use the same version of Modular Flight Integrator that comes with Kopernicus instead of the one that comes with FAR. Try explaining that to CKAN's code. You're best installing FAR Continued by hand and not with CKAN.

[Marxon]

Real shame that when I uninstalled this due to performance issues, all my craft were locked out due to FAR and realchute data embedded in the craft files.

Gotta say while I love the idea of better aerodynamic models, my computer does not. Also, why exactly is realchutes included into this?

[Alioth81]

Question for the FAR experts. I was under the assumption that FAR is based on shape (so it does take clipping thing into each other into account).

I created an aircraft in FAR with procedural parts and wings (see image below)

When I check the debug voxels it seems to recognize the shape and my general feeling is that it does do this also in flight.

However when I check the calculation tab the numbers seem to be not correct. (e.g. adding structural parts like tubes does not change the wing area in square meters and also moving a wing into a structural part or cockpit (clipping) seems to have no effect. Changing the procedural wing size however does have an effect.

My question:

Is the displayed calculation wrong and the plane is actually affected in flight (my personal guess at least drag seems to depend on shape)?

Or is FAR ignoring some parts and clipping of parts into each other for some behavior (e.g. lift of a part?)?

[Gordon Fecyk]

3 hours ago, Marxon said:

Real shame that when I uninstalled this due to performance issues, all my craft were locked out due to FAR and realchute data embedded in the craft files.

Really. I haven't experienced that. On occasion I'd take a FAR craft and loaded it into a stock game. Modern KSP editions will complain about unsupported modules, but as long as the parts are all stock parts it should still load. KSP will re-apply the stock modules to those that had FAR Aero and RealChute Lite modules added.

Do you have an example craft that wouldn't load without FAR?

I think RC Lite was put in because the stock parachutes couldn't deal with the FAR aero model. Or something. You could remove the RC Lite modules from the stock parachutes, and you'd get the stock parachute animations, but no stock parachute drag. You could put the full RealChute in there and use those parachutes with FAR.

3 hours ago, Alioth81 said:

when I check the calculation tab the numbers seem to be not correct. (e.g. adding structural parts like tubes does not change the wing area in square meters and also moving a wing into a structural part or cockpit (clipping) seems to have no effect.

I'd like to know: When you attach or adjust your procedural wings, does the Centre of Lift indicator display an arrow?

Something I noticed, was if a wing part had the Stock Aero lift module applied to it and didn't have a FAR Aero module, that arrow would appear. If all wing parts had FAR aero module or no aero module, the arrow would not appear. It might also appear in a different place if the arrow appeared vs not appeared.

Edited February 6, 2019 by Gordon Fecyk
Grammar

[Cratzz]

Im a little confused, im on KSP 1.5.1 should i get the latest (v0.15.9.6) or stay on v0.15.9.5? Thanks.

[Alioth81]

@Gordon Fecyk

No it is just a simple blue bubble with no arrow (it has a FAR module and the stock lifting surfaces are disabled/patched out.)

I think I found out part of the problem. FAR seems to calculate the surface in the wrong direction - the surface area is the area of a circle related to the diameter of the "tubes" e.g. fueltanks,

This can be easily shown also with  stock parts. If you connect 2 fuel tanks behind each other the surface area will be that of one tank. However if you place them side by side you get the area of to circles and if you clip them into each other a fraction of it.

Edit:interesting fact as soon as you add the first wing it seems that the values of "body parts" are disregarded.

Edited February 6, 2019 by Alioth81

[Agustin]

Hello  Dkavolis.
I am playing RP1 on ksp 1.3.1 and using a lot of avionics on stages.
So when I have a command module on a stage that is being decoupled, I have terrible lag for some moments with lots of exceptions thrown on log.
They all look like this:

[EXC 23:24:07.549] NullReferenceException: Object reference not set to an instance of an object
    FerramAerospaceResearch.FARAeroComponents.FARVesselAero.SimulateAeroProperties (UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, Vector3 velocityWorldVector, Double altitude)
    FerramAerospaceResearch.FARAPI.InstanceCalcVesselAeroForces (.Vessel vessel, UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, Vector3 velocityWorldVector, Double altitude)
    FerramAerospaceResearch.FARAPI.CalculateVesselAeroForces (.Vessel vessel, UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, Vector3 velocityWorldVector, Double altitude)

I know 1.3.1 is old but its what RP1 runs on. I saw that you've seen this messages in the original thread of FAR so maybe you fixed this on current versions of your fork? I don't know but if that is true would a backport for 1.3.1 be possible? or even one with a fix for this? I hate that lag in an important event as decoupling in RP1.
Thanks for your help.
 

Edited February 7, 2019 by Agustin

[dkavolis]

4 hours ago, Agustin said:

Hello  Dkavolis.
I am playing RP1 on ksp 1.3.1 and using a lot of avionics on stages.
So when I have a command module on a stage that is being decoupled, I have terrible lag for some moments with lots of exceptions thrown on log.
They all look like this:

[EXC 23:24:07.549] NullReferenceException: Object reference not set to an instance of an object
    FerramAerospaceResearch.FARAeroComponents.FARVesselAero.SimulateAeroProperties (UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, Vector3 velocityWorldVector, Double altitude)
    FerramAerospaceResearch.FARAPI.InstanceCalcVesselAeroForces (.Vessel vessel, UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, Vector3 velocityWorldVector, Double altitude)
    FerramAerospaceResearch.FARAPI.CalculateVesselAeroForces (.Vessel vessel, UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, Vector3 velocityWorldVector, Double altitude)

I know 1.3.1 is old but its what RP1 runs on. I saw that you've seen this messages in the original thread of FAR so maybe you fixed this on current versions of your fork? I don't know but if that is true would a backport for 1.3.1 be possible? or even one with a fix for this? I hate that lag in an important event as decoupling in RP1.
Thanks for your help.
 

If you want help with bugs, short excerpts from the log are not enough. I'm sorry but I don't have enough time to go bug hunting by guessing what sets it off. A proper bug report needs:

1.  Steps to reproduce said bug
2. Possible mod conflicts
3. Full log file

However, in your case, it looks like the bug is caused by Trajectories calling FARAPI before the voxelization is complete. This bug is fixed in my fork. If you need a backport, the fastest way would be to recompile it yourself. You would only need to change to KSP version in CompatibilityChecker.cs.

[Agustin]

Thanks for that Dkavolis!
My experience is that to reproduce the bug, you should decouple a stage that has a command probe in atmosphere.
Possible mod conflicts?
Rp1 - Principia
ksp.log: https://www.dropbox.com/s/t3h8pmwg4fvvz3x/KSP.log?dl=0

output.log: https://www.dropbox.com/s/jik0m7nngcv7tv2/output_log.rar?dl=0

I will try to do the recompile though.
Not sure if I will be succesfull as I know nothing about that but well. I'll do my best.

(also, I don't have the mod Trajectories installed)

Edited February 7, 2019 by Agustin

[dkavolis]

2 hours ago, Agustin said:

Thanks for that Dkavolis!
My experience is that to reproduce the bug, you should decouple a stage that has a command probe in atmosphere.
Possible mod conflicts?
Rp1 - Principia
ksp.log: https://www.dropbox.com/s/t3h8pmwg4fvvz3x/KSP.log?dl=0

output.log: https://www.dropbox.com/s/jik0m7nngcv7tv2/output_log.rar?dl=0

I will try to do the recompile though.
Not sure if I will be succesfull as I know nothing about that but well. I'll do my best.

(also, I don't have the mod Trajectories installed)

Just had a quick look at the log, you forgot to include that the NREs come from MechJeb calls into FAR but the bug seems to be the same one as with Trajectories.

[Agustin]

Thanks for that. So your fix might work for that too, right?

I am trying to recompile, sent you private message. Please can you help me?

[Ocid]

Hi,

I seem to be having some problems with FAR in that it causes anything in space to spin widly out of control.

Didn't notice at first as SAS seems to hide the problem. Only noticed it when i went to undock stuff and it showed the problem.

Removing FAR seems to fix the issue. I'm not sure if theres a conflict or something but I've uploaded a short video to show the problem as well as attached a log.

It happens on anything launched before or after installing FAR. I didn't start with it on this save if thats a problem.

 

https://drive.google.com/open?id=1RRZU6VYa4YfFHnExvw3QkuwusUg1Swu7

The log isn't from the install initially noticed on. Thought maybe it was cause i was using it on 1.4.5 so tried updating to 1.6 but the same thing persists.

Any help would be appreciated. Would like to keep using FAR. Its fun

 

Edited February 19, 2019 by Ocid

[taniwha]

@Ocid: ensure FAR's flight assistants (roll, yaw pitch) etc are turned off. They have caused me no end of trouble by being on without my noticing.

[Ocid]

7 hours ago, taniwha said:

@Ocid: ensure FAR's flight assistants (roll, yaw pitch) etc are turned off. They have caused me no end of trouble by being on without my noticing.

That did the trick thank you

Feel so dumb now. Assumed they were atmospheric flight assistance.

Thanks again.

[taniwha]

Oh, they are atmospheric flight assistance, but they operate anywhere (because they are relevant when reentering).

[Ocid]

Oh sorry. Should have said thought they were atmospheric only

Or maybe a few km cutoff after leaving atmosphere.

[Eridan]

Good day. The file "FerramAerospaceResearch.cfg" removes ModuleLiftingSurface from all parts that aren't EVA kerbals.

But two of the parts (the command pods) have newer versions that replace the classic versions. The newer parts, mk1pod_v2 and mk1-3pod, need to be included in the config.
Please check Pull Request #24 if it is sufficient.

https://github.com/dkavolis/Ferram-Aerospace-Research/pull/24

Edited March 9, 2019 by Eridan

[dkavolis]

New release is here. Fixed long-standing bug with how skinned meshes were voxelized which was exposed by ReStock. Also, debug voxels no longer cripple your game, although there might be some issues with shader compatibility since I can only test it on my one Win10 machine.

Ferram Aerospace Research Continued v0.15.9.7 "Lumley"

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

Update to MM 4.0.2

Fix skinned meshes having scale applied twice in voxelization (#30)
Fix new stock parts (#24, thanks @HSJasperism)
Greatly improved debug visual voxels framerate (#18, #29)
Enlarged debug voxel texture for higher fidelity (#18)

[ble210]

I am very curious to try this mod, and I'm curious as to other players' experiences with it.  I've heard that it makes flying planes harder (naturally), but that it makes rocketry easier, in that it takes less fuel to reach space and orbit (especially with larger rockets).  Is this true?  I fly very few planes, and I would like to make my rocket experiences more realistic and more difficult.

[kcs123]

12 hours ago, ble210 said:

I've heard that it makes flying planes harder (naturally), but that it makes rocketry easier, in that it takes less fuel to reach space and orbit (especially with larger rockets).

I would not tell that it is easier or harder to play with FAR, rather it is completely different experience.

True, in general, rockets would receive less overall drag and your rocket may need less fuel to orbit. But, at the same time it is more difficult to control, you have to plan your stages carefully to avoid aerodynamic breakdowns, figure out at what stages you must have fins, when you can get away with only gimbal controled steering, etc. You would probably take much different trajectory than in stock, to accomplish orbit. In my opinion, while you might create rocket that would have more dV, once in orbit, you will also need to tackle down different set of other obstacles. Something that is fun to do for some people and at the same time may be annoying for others.

[ble210]

11 hours ago, kcs123 said:

I would not tell that it is easier or harder to play with FAR, rather it is completely different experience.

True, in general, rockets would receive less overall drag and your rocket may need less fuel to orbit. But, at the same time it is more difficult to control, you have to plan your stages carefully to avoid aerodynamic breakdowns, figure out at what stages you must have fins, when you can get away with only gimbal controled steering, etc. You would probably take much different trajectory than in stock, to accomplish orbit. In my opinion, while you might create rocket that would have more dV, once in orbit, you will also need to tackle down different set of other obstacles. Something that is fun to do for some people and at the same time may be annoying for others.

Thank you for the input, I appreciate it.  If you don't mind one last question- in your experience, is the decrease in dv required to reach orbit significant?  I think this is my main sticking point prior to jumping into FAR.

[Maeyanie]

6 hours ago, ble210 said:

Thank you for the input, I appreciate it.  If you don't mind one last question- in your experience, is the decrease in dv required to reach orbit significant?  I think this is my main sticking point prior to jumping into FAR.

It's not all that huge any more, since the updated stock aerodynamics are less soupy than they once were.

It used to be quite a lot less, and I think a lot of the people who complain about that are basing it on how FAR compared with the original stock atmosphere model, or repeating other people who were.

Edited March 22, 2019 by Maeyanie

[Eridan]

On 3/21/2019 at 10:36 AM, ble210 said:

I am very curious to try this mod, and I'm curious as to other players' experiences with it.  I've heard that it makes flying planes harder (naturally), but that it makes rocketry easier, in that it takes less fuel to reach space and orbit (especially with larger rockets).  Is this true?  I fly very few planes, and I would like to make my rocket experiences more realistic and more difficult.

tl:dr there are certain "peculiarities" in stock. Without FAR, you'll have to use patches like the one below to address issues with parts. In effect, FAR is easier because you don't have to deal with the bugs in stock.

The most difficult change from stock to FAR for me was FAR's implementation of aerodynamic failures. High G turns with planes are more difficult, and planning landings with heavy craft in Kerbin or Eve became more difficult. Being jostled into a angle during reentry meant broken chutes or even disintegration.

Edited March 22, 2019 by Eridan