dkavolis

Members
  • Content Count

    85
  • Joined

Everything posted by dkavolis

  1. 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.
  2. 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.
  3. The concept of a point center of lift is wrong. In reality there are infinite number of those points all on a line that lift acts through. The choice of center of lift is arbitrary which in FAR is most likely chosen to lie on a principal axis hence why you don't see it going up or down. The entire CoL calculation is done in https://github.com/dkavolis/Ferram-Aerospace-Research/blob/2cf406c93ac84899a2da9e667f96be05c3ea5e40/FerramAerospaceResearch/FARGUI/FAREditorGUI/EditorAeroCenter.cs#L77-L153
  4. WindTunnel does not work with FAR since its simulation methods are not exposed in the API. In the current implementation, simulation is not thread safe so even exposing it would not make much difference as it would take too long to simulate all the points.
  5. No way to specify currently but I want to rewrite FAR to work with the job system (and burst if KSP ever uses it) so maybe in the future
  6. Partly, some animations cause voxelization to be recomputed which is then used to update shape parameters. Voxelization takes multiple frames to compute so it can't be used in real time in its current state, there may be improvements with jobs (and Burst when KSP includes its binaries). For this reason continuously moving parts should not trigger voxelization. FAR does not compute airflow, it's not a CFD, and the effects computed are only approximations, you might have different mileage with deep stall. You can't just set every part to wing and expect it to work out of the box. Wings use lifting line theory approximation which assumes wings are thin and requires shape parameters to be set. In VAB/SPH you can visualize voxels, in flight you can display force arrows and tint parts by lift, drag and stall.
  7. It should use colliders as default but you can change the behaviour with `forceUseColliders` or `forceUseMeshes`. You will have to enable debug voxels in game to see if it works or not. You might need to set `rebuildOnAnimation` to `true` in case the voxels don't update on animations.
  8. Lifting body comes from accounting for the shape of the vehicle Yeah, FAR not only has to calculate lift of each wing part but also account for interactions between each wing. The code is a bit of a spaghetti mess in this area.
  9. https://github.com/PorktoberRevolution/ReStocked/issues/751 It will be fixed on ReStock end. If you want faster support, you need to provide better information.
  10. If you want support you will need to provide logs, MM cache and steps to reproduce.
  11. Actually there's something else going on with AssemblyLoader, Scale_Redist is loaded fine but it still throws errors. AssemblyLoader might be trying to load it multiple times.
  12. Seems like FAR works fine on 1.8 so here it is: Ferram Aerospace Research v0.15.11.3 "Mach" Update to MM 4.1.0 Update to MFI 1.2.7.0 Update to KSP 1.8 (thanks @lukecologne) Update shaders to Unity 2019.2 Update .NET to 4.8 InstallChecker now runs instantly instead of waiting for main menu This release won't work with KSP <1.8 due to shaders
  13. All currently available releases are for KSP 1.4-1.7, you can try 1.8 version from https://github.com/lukecologne/Ferram-Aerospace-Research
  14. My crafts seem to be working fine. Try enabling aero visualization in FAR menu, arrows will show if any of the parts are not producing lift. The NREs come from KSP side of code so FAR is not the issue. I noticed that the exceptions are only thrown when KSP tries to upgrade existing controllable surfaces in the craftsave to custom ones, if the craftsave already contains those custom modules, the craft loads fine. It seems that the KSP API has not changed with the update, though I cannot be sure whether the functionality has stayed the same. The update consists of: Updated .NET version Added new Unity references Changed compatibility checker for KSP 1.8 Recompiled shaders with Unity 2019.2 Also, need to wait for TweakScale udpate to 1.8 since the Scale_Redist has been compiled with .NET 3.5 and addon binder can no longer load it. Parachutes are working fine on my KSP with MFI, MM, Debug Stuff, KSP AVC and KSPDev LogConsole installed. May be bad mod interaction. RealChute has been updated to KSP 1.8 without any changes to non-checker code compared to 1.7 release. In the meantime, new stock parts have been patched 2465f92, .
  15. Can someone test that there are no issues in KSP 1.8 with FAR from #80? Only binaries and shader assets need to be replaced (both are in the PR).
  16. Submit an issue on github with specifications what it should do and I'll get on it when I find the time. I'd also like to have some kind of history dumping/visualization in FAR. Writing CSV files shouldn't be too hard but I'm not familiar with extending the UI in its current state and would rather transition to what upgraded Unity offers. I experimented with UI line plotter in Unity 2018 some time ago as a replacement for ferramGraph and it mostly worked in the editor so it's mostly assembling the UI that's left. Ok, a quick bugfix for 1.7 Ferram Aerospace Research v0.15.11.2 "Mach" Update to MM 4.0.3 Revert NaN stability derivatives if no stable AoA is found #75 (#81) Fix #74 (#76, @parachutingturtle)
  17. 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.
  18. Unlike original FAR, my shaders and art assets are licensed under GPL v3 so anyone can continue its development.
  19. 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.
  20. 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)
  21. 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.