dkavolis

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.

You can also try replacing the FAR DLLs in your GameData with Debug versions from github, they have additional logging enabled and will log which mesh/collider transforms were used to voxelize each part.

No, the problem is FAR cannot currently detect when robotic parts start/stop moving.

Try patching GeometryPartModule on those parts with %forceUseMeshes = true %ignoreIfNoRenderer = true FAR is probably trying to voxelize based on colliders (less triangles so quicker). Try patching GeometryPartModule the same way as above.

Sure, I'm rebuilding the UI at the moment but it's going to be a while. I'll be able to add a lot more stuff to the UI once it's done.

That's just a mod trying to simulate a vessel without a FARVesselAero component, currently it's only log spam. The API method should return a status indicator so that the mod could clean itself up but changing API signature is not as straightforward as internal methods.

I could probably register callbacks to KSPFields and KSPActions and intercept start/end that way but it is not the cleanest solution.

Yeah, FAR doesn't handle animated parts well. What makes it even harder, robotic parts do not actually use animations but move mesh transforms and do not have any API hooks to detect the events (at least I have not found any yet). So just assume that robotic parts are unsupported in FAR and no ETA when they will be, if ever.

I haven't found anything that would let modders hook into robotics events. Also, it looks like robotic parts do not use animations and instead modify mesh transforms in a loop so FAR is oblivious to start/stop of those parts.

FAR voxelization code is a bit of a mess so I can't help much at the moment. Need to clean it up first and then understand the entire logic flow. FAR only tracks animations with specific field names unless they are ignore by FARAnimOverrides: FindAnimStatesInModule(animations, m, "animationName"); FindAnimStatesInModule(animations, m, "animationStateName"); FindAnimStatesInModule(animations, m, "animName"); FindAnimStatesInModule(animations, m, "deployAnimationName"); It's a bit dodgy way of tracking animations and by default if it detects any running/ended animations it calls UpdateShapeWithAnims which may not work for all parts. This is done every 30 physics ticks to reduce performance impact. I've also added rebuildOnAnimation config value that will call RebuildAllMeshData on animation since default behaviour didn't work for inflatable heat shield when I changed its voxelization to mesh. So you would call part.SendMessage("GeometryPartModuleRebuildMeshData") if FAR doesn't know about your animations how often you need to but with performance in mind. If your animations are tracked, try modifying GeometryPartModule on your part to have rebuildOnAnimation = true. No idea, haven't had time to check, either it works as with animations and has to do many voxelizations every second or it doesn't. Either way, calculated cross section should be wrong since the animations are continuous and looping.

Presumably nothing much happens when you call UpdateShapeWithAnims as it only modifies the mesh transforms based on root transform Matrix4x4 transformMatrix = HighLogic.LoadedSceneIsFlight ? vessel.vesselTransform.worldToLocalMatrix : EditorLogic.RootPart.partTransform.worldToLocalMatrix; You probably want to call RebuildAllMeshData which will correctly redo any part, such as the inflatable heat shield that does not change mesh transforms for its animation. In the editor, you could fire GameEvents.onEditorPartEvent(ConstructionEventType, Part) which FAR subscribes to with private void UpdateGeometryEvent(ConstructionEventType type, Part pEvent) { if (type != ConstructionEventType.PartRotated && type != ConstructionEventType.PartOffset && type != ConstructionEventType.PartAttached && type != ConstructionEventType.PartDetached && type != ConstructionEventType.PartRootSelected && type != ConstructionEventType.Unknown) return; if (EditorLogic.SortedShipList.Count > 0) UpdateGeometryModule(type, pEvent); RequestUpdateVoxel(); if (type != ConstructionEventType.Unknown) partMovement = true; }

Until KSP updates to Unity 2018.3+ and we get ECS, jobs system and Burst compiler which should be faster than my implementation.

Yes, it should work down to KSP 1.4 as the topic title or CKAN shows.

So far there have been almost exclusively bug fixes, quite a few of them are related to voxelization. You can see all the changes in the changelog.

Wings without configs will produce no lift.

I've created a pinned issue FAR#55 to keep track of what should be done. If anyone has any suggestions, leave a comment there and I'll add it to the list if it's worth pursuing.

Soon™ I'm not a fan of Unity IMGUI so it will be after I replace it (there's some progress there)

Not yet

That's because that part has an invisible plane mesh which gets voxelized. If you're using my fork, add @PART[<part name>]:AFTER[FerramAerospaceResearch] { @MODULE[GeometryPartModule] { %forceUseMeshes = True // just in case %ignoreIfNoRenderer = true // skips voxelizing invisible meshes } } Currently voxelization works as in the original FAR with a few extra options, haven't made skipping invisible meshes default yet.

I don't know about that, my guess is that some values required for computations are not updated in some cases. Circular references are often simply bad code design. In managed languages such as C# this prevents the objects from being GCed, i.e. memory leaks, and makes maintaining the code harder.

It's probably done to get the developers attention in case there were any errors during loading, otherwise you might not even notice and assume everything works as it should. And later you get an error in another place due to some types not loaded and wonder what went wrong. I'm sure Microsoft had good reasons to do it this way.

https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly.gettypes?view=netframework-3.5 You could just catch ReflectionTypeLoadException and loop trough its Types property ignoring null values to get all loaded Types.

I'm fairly sure the wing lift is calculated using lifting line theory with additions for interactions (coded with a ton of circular references) between aerodynamic surfaces so it can't really handle thick airfoils. Though it's still good enough for a game that needs to run in real time. There's no way any CFD can run in real time, certainly not one that would work with arbitrarily shaped vehicles in KSP. Specifying some parameters in the configs greatly reduces the amount of calculations that would need to be done. The supersonic/hypersonic behaviour is pretty approximate, there are a lot of simplifications in the code. Haven't gone into voxelization that deeply since it's one huge monolithic (not the only one) class that handles it... If I'm not mistaken, the voxelized shape is only used for cross sectional data - mainly body lift and drag. FAR could really use some refactoring, i.e. moving all aerodynamics/voxelization code into a separate library (and making everything thread safe preferably) that does not depend on KSP assemblies so that tests could run in Unity editor. It could be split into multiple libraries such as GUI/Unity, Maths/Aerodynamics/Voxelization and KSP plugin that binds everything together. It's a lot of work though but that would make FAR much easier to maintain, scale and understand. The part modules should really not do any maths. If you want to look at the source code more closely, I recommend installing an IDE such as Visual Studio (often overkill) or VSCode which will let you navigate the code much easier, lookup references and usage. If you're a student (or can afford it) and want to do some coding I recommend Rider or ReSharper for Visual Studio with Heap Allocations Viewer and Unity plugins which will greatly help getting started. VSCode has a unity plugin that lets you directly search unity docs on the internet. C# is not hard to pickup unlike FAR.

It's fixed in 0.15.10.1

Have you tried the hotfix version yet? It might be the bug I've introduced in OnLoad method when I didn't realize that on switching scenes it wouldn't be called with config values.