dkavolis

Only if you or someone else can find some simple models how blowing affects transition Reynolds number and stall. Simulation is out of the scope for real time computations, even CFD can struggle with boundary layers.

Ferram Aerospace Research v0.15.11.1 "Mach" Fix #72 (#73)

Ferram Aerospace Research v0.15.11.0 "Mach" Chute staging now works with stage lock (#68) Fix German localization formatting (#70, @HebaruSan) Greatly improve stable angle of attack solver in stability derivative calculation, now works for all cases where stable angle of attack exists and converges faster (#65) Fix aerodynamic torque simulation and expose total aerodynamic force and torque through API (#22, @BenChung) Shaders are now platform specific (#60) Now really fixed ocassional NRE when cleaning up debug voxels (#59) Fix unsubsribing correct method from GameEvents.onGUIEngineersReportDestroy in EditorGUI (#58) Fix assymetrical voxelization on some Mk2/Mk3 adapters #56 (#57) Cache some Unity properties for performance reasons (#53) Fix Runge Kutta method in transient simulation (#50) Fix part tinting not cleared after last tint option is disabled (#49)

Yeah but it seems like the shroud would not provide protection from the airstream. You should expect a constant cross section instead. Try voxelizing with colliders enabled. It might be that your mesh shell is so thin, it's ignored by FAR.

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; }