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

[Hsinyu]

On 2/18/2020 at 8:17 AM, Jagzeplin said:

so with the pre-release has anyone else had issues with many of the prebuilt planes/ships not loading? for example the Mallard, the Dove, many others... they show up in the list but i cant get them to load up in the SPH/VAB

I have the same problem. I cannot load many of those prebuilt ships. The load button is not gray, but the load button just does not work.

[dlrk]

Could someone explain what "Air Req Met" refers to? It doesn't seem to correlate with jet engine power

[Husky777]

Hello everyone Can someone explain to me how to disable the FAR button, which allows you to configure the mod on !KSC screen? I do not like the settings buttons and settings that destroy immersion, allowing you to cheat in the game and always disable them.

I apologize for my bad English. This is not my native language

[kcs123]

16 hours ago, dlrk said:

Could someone explain what "Air Req Met" refers to? It doesn't seem to correlate with jet engine power

Jet engines need Liquid fuel and air with oxygen for combustion. "Air Req Met" tells how much air is provided trough air intakes for jet engines to operate properly. It depends on altitude and mach numbers. Some inlets are more efficient than others and some jet engines operate better in subsonic than supersonic and oposite. That info comes handy when you try to optimize your craft to use least amount of inlets and those that weight less than others for certain craft purposes.

[dlrk]

What does the percentage refer to though? My jets seem to run five with a low percentage.

[kcs123]

7 hours ago, dlrk said:

What does the percentage refer to though? My jets seem to run five with a low percentage.

100% means that engine have enough air for operation. Lower than that, engine will start to loose thrust. IIRC, somwhere around 10%, engine will flame out, or shut off. Above 100% means that your craft have more than enough oxygen from air intakes for normal operation.

[Olorin]

I ended up needing to delete this mod. I kept finding that no matter how I designed my rockets, the use of fairings made the aerodynamics worse.

The simplest example of that being the case was that when designing a rocket, having a low COL is what you aim for. By placing fairings on, it kept raising the COL instead of lowering it. I found no way to explain this happening, and the issue disappeared after I removed the mod. Just a heads up - feel free to let me know if I'm missing something crucial.

[Garrygirthoak]

Hi! First of all I really like this mod, i was getting a bit triggered over nose cones in Vanilla not being recognized as an aerodynamic object affecting the position of COL.

I really like how the COL reacts to fairings, you make a big ole fairing at the top of your rocket,  just like in RockSim, your COL will shift upwards.

I was wondering if there's anyway to scale back the ingame GUI for the mod? I normally scale my navball at 80%, same as Altimeter ect. How do i get the Mod GUI window smaller.

Kind Regards!

 

[dlrk]

5 hours ago, Olorin said:

I ended up needing to delete this mod. I kept finding that no matter how I designed my rockets, the use of fairings made the aerodynamics worse.

The simplest example of that being the case was that when designing a rocket, having a low COL is what you aim for. By placing fairings on, it kept raising the COL instead of lowering it. I found no way to explain this happening, and the issue disappeared after I removed the mod. Just a heads up - feel free to let me know if I'm missing something crucial.

That definitely shouldn't be happening. Can you post a picture of a rocket you've had that issue with? My guess is that your fairings are too large relative to the rocket body and are acting as a lifting body.

[Olorin]

Ignore the COL indicator, as this is after I turned the mod off. But this rocket is the one I was attempting to launch. Just the fact that adding fairings made rockets flip out more than exposed parts started getting ridiculous.

[dkavolis]

So, I've been playing around with jobs system for voxelization and figured out how FAR voxelization works since it has no comments and questionable variable names.

For every triangle in the mesh:

1. Choose shell voxelization plane based on largest normal component
2. Transform triangle into voxel index space
3. Calculate triangle plane equation in index space
4. For every index pair bounded by the triangle in voxelization plane
   1. Solve for the last index from the plane equation
   2. Fill the voxel if
      • The 3d index is inside triangle (barycentric coordinates)
      • The 3d index is within tolerance to any triangle vertex (currently 0.5)
      • The 3d index is within tolerance to any triangle side (currently 0.5)

This voxelization algorithm is far cheaper (roughly  O(n²)) than most others that rely on triangle/AABB intersection tests, which are relatively expensive, with complexity of about O(n³). I have also found  https://github.com/ramakarl/voxelizer which has another O(n²) voxelization algorithm though I could not get it to properly voxelize a sphere as of now.

However the current implementation can leave gaps in the shell (sphere in 50x50x50 voxel volume).

Also, C# even only using value types is slow for maths heavy applications. This shell voxelization took about 60ms without Burst on my machine in Unity editor and only 2ms with Burst (single thread).

Edit: tried the same voxelization using C# arrays instead Unity NativeArray and it took about 60ms as well, maybe a few ms faster on average but not as easy to offload to another thread/synchronize/parallelize as a job.

Edited March 9, 2020 by dkavolis

[kretze]

FAR undermines ModuleManager Cache

With constant changes to the CustomFARAeroData.cfg file, the ModuleManager cache can no longer be used.
This is not particularly noticeable in small installations.

I currently use RP-1 + Kerbalism and various part mods. The ModuleManager must import over 86600 patches when KSP is starting.
Because the CustomFARAeroData.cfg is always changed and thus has a new SHA256 hash, the MM cache is no longer used.
Each start of the game currently takes 10-12 minutes because of patching. It is very annoying.

 

KSP LOG:

[LOG 21:42:24.994] Checking Cache
[LOG 21:42:26.559] SHA generated in 1.562s
[LOG 21:42:26.559]       SHA = E0-E4-3C-AD-9D-D3-84-CB-B9-37-BF-24-2A-27-25-E9-E9-39-01-2C-B4-25-3A-BF-EE-28-5E-82-07-F6-8E-A6
[LOG 21:42:27.312] Changes :
Changed : FerramAerospaceResearch/CustomFARAeroData.cfg.cfg

[LOG 21:42:27.312] Cache SHA = E4-69-DE-4A-51-48-6E-A8-5D-BD-C1-99-00-3A-31-DF-96-5D-4E-9D-00-C8-16-12-62-E6-0C-1B-09-AA-DB-4D
[LOG 21:42:27.312] useCache = False
[LOG 21:42:27.313] Pre patch init

 

 

[Autolyzed Yeast Extract]

-

Edited March 12, 2020 by Autolyzed Yeast Extract

[dkavolis]

17 hours ago, kretze said:

FAR undermines ModuleManager Cache

With constant changes to the CustomFARAeroData.cfg file, the ModuleManager cache can no longer be used.
This is not particularly noticeable in small installations.

I currently use RP-1 + Kerbalism and various part mods. The ModuleManager must import over 86600 patches when KSP is starting.
Because the CustomFARAeroData.cfg is always changed and thus has a new SHA256 hash, the MM cache is no longer used.
Each start of the game currently takes 10-12 minutes because of patching. It is very annoying.

 

KSP LOG:

[LOG 21:42:24.994] Checking Cache
[LOG 21:42:26.559] SHA generated in 1.562s
[LOG 21:42:26.559]       SHA = E0-E4-3C-AD-9D-D3-84-CB-B9-37-BF-24-2A-27-25-E9-E9-39-01-2C-B4-25-3A-BF-EE-28-5E-82-07-F6-8E-A6
[LOG 21:42:27.312] Changes :
Changed : FerramAerospaceResearch/CustomFARAeroData.cfg.cfg

[LOG 21:42:27.312] Cache SHA = E4-69-DE-4A-51-48-6E-A8-5D-BD-C1-99-00-3A-31-DF-96-5D-4E-9D-00-C8-16-12-62-E6-0C-1B-09-AA-DB-4D
[LOG 21:42:27.312] useCache = False
[LOG 21:42:27.313] Pre patch init

 

 

Thanks, I'll add a fix some time soon. In the mean time you can run KSP from a batch/bash script which deletes CustomFARAeroData.cfg before starting KSP. Use del (batch) or rm (bash) commands to remove the file.

 

[kretze]

I have an update on this topic

My first post related to KSP 1.7.3 and FAR 0.15.11.2 (since RP-1 only runs with KSP 1.7.3)

I tested it again today with KSP 1.8.1 and FAR 0.15.11.4 after seeing on github that there was a revised configuration management
installed in 0.15.11.3.

In a new KSP 1.8.1 installation + far 0.15.11.4, I cannot reproduce this configuration change. is it related to all the realism and some other mods with RP-1?

I will do more tests.

----

Info for identifying the problem

the changes i found in CustomAreoData.cfg (0.15.11.2)

    BodyAtmosphericData
    {
        index = 1
        viscosityAtReferenceTemp = 1.7893999999999998E-05
        referenceTemp = 288
    }
 

    BodyAtmosphericData
    {
        index = 1
        viscosityAtReferenceTemp = 2.0000000000000002E-05
        referenceTemp = 288
    }
 

i found 2 mods that change this value

- FAR & RSS

 

Edited March 12, 2020 by kretze

[dkavolis]

11 hours ago, kretze said:

I have an update on this topic

My first post related to KSP 1.7.3 and FAR 0.15.11.2 (since RP-1 only runs with KSP 1.7.3)

I tested it again today with KSP 1.8.1 and FAR 0.15.11.4 after seeing on github that there was a revised configuration management
installed in 0.15.11.3.

In a new KSP 1.8.1 installation + far 0.15.11.4, I cannot reproduce this configuration change. is it related to all the realism and some other mods with RP-1?

I will do more tests.

----

Info for identifying the problem

the changes i found in CustomAreoData.cfg (0.15.11.2)

    BodyAtmosphericData
    {
        index = 1
        viscosityAtReferenceTemp = 1.7893999999999998E-05
        referenceTemp = 288
    }
 

    BodyAtmosphericData
    {
        index = 1
        viscosityAtReferenceTemp = 2.0000000000000002E-05
        referenceTemp = 288
    }
 

i found 2 mods that change this value

- FAR & RSS

 

New config system should coming in the next release but in any case configs without changes should not be output. I can compare the config node string with the last saved/loaded string to determine if any values have changed in game. That should prevent MM from creating patches a second time.

[Poodmund]

On 2/18/2020 at 12:17 AM, Jagzeplin said:

so with the pre-release has anyone else had issues with many of the prebuilt planes/ships not loading? for example the Mallard, the Dove, many others... they show up in the list but i cant get them to load up in the SPH/VAB

On 2/29/2020 at 1:40 PM, Hsinyu said:

I have the same problem. I cannot load many of those prebuilt ships. The load button is not gray, but the load button just does not work.

@dkavolis, this issue seems to be persisting with FAR v0.15.11.4 and KSP 1.9.1.2788. The easiest way to reproduce the issue is to work with a clean vanilla build of KSP, install FAR v0.15.11.4, Module Manager 4.1.3 and MFI 1.2.7.0. Start a new Sandbox game and go to the Editor (VAB). Load the Kerbal X stock craft, then subsequently, try to load the Dynawing stock craft. Exceptions will be thrown when trying to click the 'Load' button when try to load the Dynawing.

It seems that there is an issue in the upgrade pipeline where FAR is trying to update saved craft files to 1.9.1 'standards'. I think it affects craft that have controllable lifting surface parts as the same thing happens with a lot of the stock aircraft when trying to load them in the SPH.

Log attached: https://www.dropbox.com/s/zo47m3ew88gsf68/KSP.log?dl=0

In the attached log, I followed the process I outlined above and then tried to load other vessels that triggered the same issue.

Would you like me to raise an issue on the Git tracker?

Edited March 26, 2020 by Poodmund

[dkavolis]

1 hour ago, Poodmund said:

@dkavolis, this issue seems to be persisting with FAR v0.15.11.4 and KSP 1.9.1.2788. The easiest way to reproduce the issue is to work with a clean vanilla build of KSP, install FAR v0.15.11.4, Module Manager 4.1.3 and MFI 1.2.7.0. Start a new Sandbox game and go to the Editor (VAB). Load the Kerbal X stock craft, then subsequently, try to load the Dynawing stock craft. Exceptions will be thrown when trying to click the 'Load' button when try to load the Dynawing.

It seems that there is an issue in the upgrade pipeline where FAR is trying to update saved craft files to 1.9.1 'standards'. I think it affects craft that have controllable lifting surface parts as the same thing happens with a lot of the stock aircraft when trying to load them in the SPH.

Log attached: https://www.dropbox.com/s/zo47m3ew88gsf68/KSP.log?dl=0

In the attached log, I followed the process I outlined above and then tried to load other vessels that triggered the same issue.

Would you like me to raise an issue on the Git tracker?

It's KSP updating their crafts as the traceback suggests. FAR replaces all ModuleControlSurface with its own PartModule, that's why you get NREs. It's a bug with KSP and not FAR, they should have really added a null check in their code since they allow modifications of part modules.

There are 2 workarounds I can think of:

• Load the craft in pre-1.8 KSP version with FAR and save it
• Replace all ModuleControlSurface with

MODULE
{
	name = FARControllableSurface
	isEnabled = True
	pitchaxis = 100
	yawaxis = 0
	rollaxis = 100
	pitchaxisDueToAoA = 0
	brakeRudder = 0
	maxdeflect = 6
	isFlap = False
	isSpoiler = False
	flapDeflectionLevel = 0
	maxdeflectFlap = 15
	massMultiplier = 0.5
	stagingEnabled = True
	pitchaxis_UIFlight
	{
		controlEnabled = True
		minValue = -100
		maxValue = 100
		stepIncrement = 5
	}
	yawaxis_UIFlight
	{
		controlEnabled = True
		minValue = -100
		maxValue = 100
		stepIncrement = 5
	}
	rollaxis_UIFlight
	{
		controlEnabled = True
		minValue = -100
		maxValue = 100
		stepIncrement = 5
	}
	pitchaxisDueToAoA_UIFlight
	{
		controlEnabled = True
		minValue = -200
		maxValue = 200
		stepIncrement = 5
	}
	brakeRudder_UIFlight
	{
		controlEnabled = True
		minValue = -100
		maxValue = 100
		stepIncrement = 5
	}
	maxdeflect_UIFlight
	{
		controlEnabled = True
		minValue = -40
		maxValue = 40
		stepIncrement = 0.5
	}
	isFlap_UIFlight
	{
		controlEnabled = True
	}
	isSpoiler_UIFlight
	{
		controlEnabled = True
	}
	maxdeflectFlap_UIFlight
	{
		controlEnabled = True
		minValue = -85
		maxValue = 85
		stepIncrement = 0.5
	}
	massMultiplier_UIEditor
	{
		controlEnabled = True
		minValue = 0.05
		maxValue = 2
		stepIncrement = 0.05
	}
	EVENTS
	{
		DeflectMore
		{
			active = False
			guiActive = True
			guiActiveUncommand = False
			guiIcon = Deflect more
			guiName = Deflect more
			category = Deflect more
			guiActiveUnfocused = False
			unfocusedRange = 2
			externalToEVAOnly = True
		}
		DeflectLess
		{
			active = False
			guiActive = True
			guiActiveUncommand = False
			guiIcon = Deflect less
			guiName = Deflect less
			category = Deflect less
			guiActiveUnfocused = False
			unfocusedRange = 2
			externalToEVAOnly = True
		}
		ToggleStaging
		{
			active = True
			guiActive = False
			guiActiveUncommand = False
			guiIcon = Disable Staging
			guiName = Disable Staging
			category = Disable Staging
			guiActiveUnfocused = False
			unfocusedRange = 2
			externalToEVAOnly = True
		}
	}
	ACTIONS
	{
		ActivateSpoiler
		{
			actionGroup = Brakes
		}
		IncreaseDeflect
		{
			actionGroup = None
		}
		DecreaseDeflect
		{
			actionGroup = None
		}
	}
}

There doesn't seem to be a way to modify the SaveUpgradePipeline used in KSPUpgradePipeline, at least no public API.

Edited March 26, 2020 by dkavolis

[dkavolis]

On 2/18/2020 at 12:17 AM, Jagzeplin said:

so with the pre-release has anyone else had issues with many of the prebuilt planes/ships not loading? for example the Mallard, the Dove, many others... they show up in the list but i cant get them to load up in the SPH/VAB

On 2/29/2020 at 1:40 PM, Hsinyu said:

I have the same problem. I cannot load many of those prebuilt ships. The load button is not gray, but the load button just does not work.

6 hours ago, Poodmund said:

@dkavolis, this issue seems to be persisting with FAR v0.15.11.4 and KSP 1.9.1.2788. The easiest way to reproduce the issue is to work with a clean vanilla build of KSP, install FAR v0.15.11.4, Module Manager 4.1.3 and MFI 1.2.7.0. Start a new Sandbox game and go to the Editor (VAB). Load the Kerbal X stock craft, then subsequently, try to load the Dynawing stock craft. Exceptions will be thrown when trying to click the 'Load' button when try to load the Dynawing.

It seems that there is an issue in the upgrade pipeline where FAR is trying to update saved craft files to 1.9.1 'standards'. I think it affects craft that have controllable lifting surface parts as the same thing happens with a lot of the stock aircraft when trying to load them in the SPH.

Log attached: https://www.dropbox.com/s/zo47m3ew88gsf68/KSP.log?dl=0

In the attached log, I followed the process I outlined above and then tried to load other vessels that triggered the same issue.

Would you like me to raise an issue on the Git tracker?

I've added a workaround for now in dev branch (0033445)

[Incarnation of Chaos]

Spoiler

On 3/8/2020 at 2:59 PM, dkavolis said:

So, I've been playing around with jobs system for voxelization and figured out how FAR voxelization works since it has no comments and questionable variable names.

For every triangle in the mesh:

1. Choose shell voxelization plane based on largest normal component
2. Transform triangle into voxel index space
3. Calculate triangle plane equation in index space
4. For every index pair bounded by the triangle in voxelization plane
   1. Solve for the last index from the plane equation
   2. Fill the voxel if
      • The 3d index is inside triangle (barycentric coordinates)
      • The 3d index is within tolerance to any triangle vertex (currently 0.5)
      • The 3d index is within tolerance to any triangle side (currently 0.5)

This voxelization algorithm is far cheaper (roughly  O(n²)) than most others that rely on triangle/AABB intersection tests, which are relatively expensive, with complexity of about O(n³). I have also found  https://github.com/ramakarl/voxelizer which has another O(n²) voxelization algorithm though I could not get it to properly voxelize a sphere as of now.

However the current implementation can leave gaps in the shell (sphere in 50x50x50 voxel volume).

Also, C# even only using value types is slow for maths heavy applications. This shell voxelization took about 60ms without Burst on my machine in Unity editor and only 2ms with Burst (single thread).

Edit: tried the same voxelization using C# arrays instead Unity NativeArray and it took about 60ms as well, maybe a few ms faster on average but not as easy to offload to another thread/synchronize/parallelize as a job.

 

Wow....you're actually going to tackle the voxel system aren't you? Already the speedup you're describing is pretty incredible, and on a sidenote iv'e noticed these gaps since i started using FAR for my games a while back. I never thought much of them honestly, but they do seem to enjoy areas around weird geometry.

Though the reason I'm posting is just really me wanting to ask a question; why not use matrices to hold the Triangle arrays and perform the needed mathematical operations between multiple matrices of arrays at once? Would the overhead just make it slower than just using the arrays even though you could do more work at once? Or are the calculations dependent on prior ones? Or should i just pull the source and answer my own questions like you have xD

I'm not a experienced programmer, so i could be missing something really silly.

[dkavolis]

2 hours ago, Incarnation of Chaos said:

  Reveal hidden contents

 

Wow....you're actually going to tackle the voxel system aren't you? Already the speedup you're describing is pretty incredible, and on a sidenote iv'e noticed these gaps since i started using FAR for my games a while back. I never thought much of them honestly, but they do seem to enjoy areas around weird geometry.

Though the reason I'm posting is just really me wanting to ask a question; why not use matrices to hold the Triangle arrays and perform the needed mathematical operations between multiple matrices of arrays at once? Would the overhead just make it slower than just using the arrays even though you could do more work at once? Or are the calculations dependent on prior ones? Or should i just pull the source and answer my own questions like you have xD

I'm not a experienced programmer, so i could be missing something really silly.

Triangles can be anywhere in space so every triangle would need to be checked, this quickly becomes too expensive. And FAR needs to know the filled/shielded volume which plain triangles can't give.

[VaNnadin]

aaaaah I'm having a problem with FAR configuration, can you tell me what "rootMidChordOffsetFromOrig" is?

[dkavolis]

1 hour ago, VaNnadin said:

aaaaah I'm having a problem with FAR configuration, can you tell me what "rootMidChordOffsetFromOrig" is?

It's not used currently.

[VaNnadin]

4 hours ago, dkavolis said:

It's not used currently.

I'm trying to make FAR patch for wing using b9partswitch. wing's direction is changed by this mod. how can I make FAR work with it?

[SilverlightPony]

On 9/30/2019 at 12:13 PM, infinite_monkey said:

I just realized FAR comes with RealChuteLite/RealChuteFAR - what is it, and how is it different from RealChute? I only noticed because chutes are clipping into each other. So I was looking for the "spread angle" slider and couldn't find it. Instead, I found the RealChute info window, which gives me some info, but doesn't let me configure anything  

 

On 9/30/2019 at 12:37 PM, kcs123 said:

Difference from RealChute is that "Lite" version use only stock parachute models. One of drawback of using those is, like you already noticed, spread angle/animation not working properly.
I can only advice you to use full RealChute mod and to use RealChute parts to avoid cliping bug. Don't know of any other possible workaround on this and I doubt that @dkavolis have any time or desire to solve this issue. That bug was around for a very long time, even when ferram was actively working on this mod.

 

On 9/30/2019 at 3:23 PM, dkavolis said:

FAR comes with bare minimum of RealChute for aerodynamics purposes only, if you want more I suggest installing the full RealChute mod. FAR is aerodynamics mods after all. Or you can go on https://github.com/StupidChris/RealChute        and try and port the relevant bits of code to FAR.

I've been busy lately but will try and find the time to fix up things before 1.8 release.

It seems there's been no change to this as of yet.  I'll give the full RealChute mod a try, but it looks more complex than I really want to deal with, which leaves me torn between adding RC, dropping FAR, and putting up with clipping chutes.  Even if it lacked the aerodynamic benefits that chute-spread has in vanilla KSP, a basic spread-angle function just to avoid clipping would be very much appreciated.