dkavolis

Yeah

Re launching vessels from SPH/VAB compared to revert to launch, can you try FAR from dev branch? FAR was voxelizing parts too eagerly, before KSP was done with disabling unused models like engine fairings on scene changes so it was working fine on return to launch. FAR now waits for physics to kick in before voxelizing so it should no longer voxelize what you can't see. Launch clamps will be mostly ignored in editor in the next release, there's still a barely noticeable effect on stability derivative values left that I'm not sure where it comes from. For now, you can use the dev branch version. For all the other issues, please provide KSP.log, ModuleManager.ConfigCache, the affected craft file and mod list in addition to description of the problem. Ideally, open an issue on github with all of the above.

It's not used currently.

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.

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

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.

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.

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.

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: Choose shell voxelization plane based on largest normal component Transform triangle into voxel index space Calculate triangle plane equation in index space For every index pair bounded by the triangle in voxelization plane Solve for the last index from the plane equation 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(n2)) than most others that rely on triangle/AABB intersection tests, which are relatively expensive, with complexity of about O(n3). I have also found https://github.com/ramakarl/voxelizer which has another O(n2) 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.

My guess is that YmaxStress is the yield stress and XZmaxStress is the tensile strength, though the comments are wrong and should say MPa instead (same as in C# source). So all the values fall in aluminium alloy/carbon steel ranges which are really wide.

You will probably want to change the values in https://github.com/dkavolis/Ferram-Aerospace-Research/blob/master/GameData/FerramAerospaceResearch/FARAeroStress.cfg with an MM patch or edit them from the settings GUI in the space centre scene.

Not in the near future

Ferram Aerospace Research v0.15.11.4 "Mach" Update to MM 4.1.3 Update to KSP 1.9 Removed CompatibilityChecker Debug voxel mesh is now built as a single mesh, with possible submeshes. Choose between 16 (default) and 32 bit vertex indices from the Space Centre settings menu. (#86) The debug voxel mesh should now be faster to build and render, use less memory and much easier to customize in the future.

I've recompiled FAR for 1.9 and everything seems to work fine but for now it's only a pre-release https://github.com/dkavolis/Ferram-Aerospace-Research/releases/tag/v0.15.11.4_Mach I've also removed CompatibilityChecker so FAR is no longer locked to a specific KSP version range since modding API has been stable for the last few releases. I imagine most incompatibilities will only be due to different Unity versions.

Stock robotics modify mesh transforms to get the animations and the last time I tried (1.7) there was no simple way to check if parts were moving or not. Animations that use common field names are automatically handled by FAR unless disabled through MM. IR uses uses builtin Unity functionality to update voxelization. FAR has no support for any propellers, it only handles thin wings and body aerodynamics. foreach (PartModule m in part.Modules) { FindAnimStatesInModule(animations, m, "animationName"); FindAnimStatesInModule(animations, m, "animationStateName"); FindAnimStatesInModule(animations, m, "animName"); FindAnimStatesInModule(animations, m, "deployAnimationName"); } Regarding voxelization of animated parts, I think the current implementation can be vastly improved using job system which significantly simplifies writing multithreaded code with dependencies. FAR uses multiple threads to voxelize but writes to same memory locations from them and reference objects add unnecessary indirections in some places. I think voxelization can be redone with partial volume update support for animations and possibly lower memory usage.