dkavolis

Ferram Aerospace Research v0.15.10.1 "Lundgren" Hotfix for 0.15.10.0 Note for Kopernicus users: DO NOT overwrite MFI that comes with Kopernicus since it is locked to that particular version Fix config values reset on load in GeometryPartModule #47 Fix NRE spam on EVA #43 (#44)

Unless you work on a copy of data without any Unity Objects in it and apply it afterwards which is what this plugin can do. Unity Job System is similar. But this lets you choose specific time when to get back to the main thread. I'll try making at least the simulation part of FAR threadsafe for more useful plots.

Only voxelization is, physics are still done on the main thread

Here's a lightweight WIP modder's plugin that allows the use of multithreading for repeated tasks with synchronization to other tasks and Unity scripts. This could prove useful for physics heavy mods like FAR that at the moment run in a single thread to make use of multiple cores provided the physics code can be made threadsafe. To help with this, tasks have optional delegates executed on the main thread before and after the multithreaded task which can be used to transfer data between threads. In case of dependencies, start and end times are flexible. If you don't have any dependencies, you can start the task at the very start of Update event and apply the calculated forces at the very end of the same Update event, or even delay the end time until the start of LateUpdate! Execution times of a single frame (or 1 FixedUpdate loop) are possible. As ever, bugs are possible. Parallel Tasker Parallel Tasker is a plugin for Unity (see Test) and Kerbal Space Program that can execute supplied tasks in parallel between any possible combination of defined times (see Task Timing below). Parallel Tasker is expected to be used through ParallelTasker.ParallelTasker as a hard dependency for other plugins. Times are determined by script execution orders of PTSynchronizers and exported in Asset Bundle synchronizers.pt (yes, asset bundles also export script execution orders). This offers a very lightweight and consistent method to signalize timings of Update events. In addition, Parallel Tasker itself does not generate any garbage while executing tasks except for creating new ones (removed tasks are reused). If no tasks need to be started or ended at a specific time, then that task controller is unsubscribed from receiving the synchronizer events. All classes are defined in ParallelTasker namespace. Get the source code: GitHub License: GPL3 ParallelTasker The API can be found in a static ParallelTasker class. Properties bool ResetTasksOnSceneChange a property to disable/enable task clearing on scene changes to be used in case some tasks rely on GameObjects that may no longer be available in different scenes. Default: true Subscriptions bool SubscriptionStatus(PTTimePair taskGroup) synchronizer subscription status of task controller that runs at time taskGroup. bool SubscriptionStatus(PTUpdateEvent updateEvent, PTEventTime eventTime) overload of the above. void Subscribe(PTTimePair timePair, Action handler) subscribe handler to receive timePair update event, remove with Unsubscribe otherwise anything the handler encloses may not be garbage collected. void Subscribe(PTUpdateEvent updateEvent, PTEventTime eventTime, Action handler) overload of the above. void Unsubscribe(PTTimePair timePair, Action handler) unsubscribe handler from receiving update events at timePair time. void Unsubscribe(PTUpdateEvent updateEvent, PTEventTime eventTime, Action handler) overload of the above. Tasks Adding a task requires a start startTime and end endTime time defined by PTTimePair. Removing a specific task only requires its startTime since that is where it is registered internally. Note that (for now) the startTime is not referenced in PTTask. PTTask AddTask(PTTimePair startTime, PTTimePair endTime, PTTask task) add a task task to be executed. Returns the added task, in this case task PTTask AddTask(PTTimePair startTime, PTTimePair endTime, Func<object, object> task, uint period = 1) add a task with no initialize and finalize with execution period period to the current task list. Returns the added task. PTTask AddTask(PTTimePair startTime, PTTimePair endTime, Func<object> initializer, Func<object, object> task, uint period = 1) add a task with finalize with execution period period to the current task list. Returns the added task. PTTask AddTask(PTTimePair startTime, PTTimePair endTime, Func<object, object> task, Action<object> finalizer, uint period = 1) add a task with no initialize with execution period period to the current task list. Returns the added task. PTTask AddTask(PTTimePair startTime, PTTimePair endTime, Func<object> initializer, Func<object, object> task, Action<object> finalizer, uint period = 1) add a complete task with execution period period to the current task list. Returns the added task. bool RemoveTask(PTTimePair startTime, PTTask task) remove task from group task list. Returns success/failure of removal. bool RemoveTask(PTTimePair startTime, Func<object, object> task) remove the first task with PTTask.main == task from the group task list. Returns success/failure of removal. void ClearTasks() clear all current tasks. void ClearTasks(PTTimePair startTime) clear all tasks starting at startTime time. Logging The provided logging API is threadsafe so you won't get mangled log entries. Logs are flushed every frame at LateUpdate.Start. Logging API is similar to Unity's but does not contain overloads with UnityEngine.Object arguments since Unity API is not thread safe and thus should not be used in multi threading. Use sparingly since most tasks will be executed 10s of times per second. void Debug(object message) log a normal message, only if compiled with DEBUG. void DebugFormat(string format, params object[] args) log a formatted format message with arguments args, only if compiled with DEBUG. void Log(object message) log a normal message. void LogFormat(string format, params object[] args) log a formatted format message with arguments args. void LogError(object message) log an error message. void LogErrorFormat(string format, params object[] args) log a formatted error format message with arguments args. void LogWarning(object message) log a warning message. void LogWarningFormat(string format, params object[] args) log a formatted warning format message with arguments args. void LogException(Exception exception) log an exception exception. Task Timing Parallel Tasker consists of 3 Update events PTUpdateEvent and 9 possible timers PTEventTime. Any possible combination of those values is a valid start or end time for the task. Though mixing FixedUpdate with Update or LateUpdate may not make much sense since they run on different timers. Each combination of timing is guaranteed to finish the tasks ending at that time before starting new ones. If start and end times are equal, the task will be finished in the next Update event. Any task with an end time before start time will finish in the next Update event (i.e. start in LateUpdate and end in Update or end with a lower PTEventTime) Update Events They are standard Unity Update events: public enum PTUpdateEvent { Update, LateUpdate, FixedUpdate } Timers Current timers are based on KSP Script Execution Order: public enum PTEventTime { Start = -8008, Precalc = -101, Early = -99, Earlyish = -1, Normal = 0, FashionablyLate = 7, FlightIntegrator = 9, Late = 19, End = 8008 } Default Dequeue Order The default dequeue order depends on Enum.GetValues(Type) so it may change in the future. It currently is: Update.Normal Update.FashionablyLate Update.FlightIntegrator Update.Late Update.End Update.Start Update.Precalc Update.Early Update.Earlyish LateUpdate.Normal LateUpdate.FashionablyLate LateUpdate.FlightIntegrator LateUpdate.Late LateUpdate.End LateUpdate.Start LateUpdate.Precalc LateUpdate.Early LateUpdate.Earlyish FixedUpdate.Normal FixedUpdate.FashionablyLate FixedUpdate.FlightIntegrator FixedUpdate.Late FixedUpdate.End FixedUpdate.Start FixedUpdate.Precalc FixedUpdate.Early FixedUpdate.Earlyish Tasks that need to be ended are given priority. Parallel Tasker Tasks Each task PTTask can be queued for any of the start and end times and consists of 3 functions, unsigned integer and PTTimePair: Func<object> initialize (optional) a function that returns object, guaranteed to run before any other task function. This can be used to copy data from the main thread to be passed to main. It is always executed on the main thread. Func<object, object> main a function that takes a single object (from initialize) as an argument and returns object. This function is executed in a different thread and thus should be made thread safe. Guaranteed to run after initialize and before finalize of this task. Action<object> finalize (optional) a void function that takes a single object (from main) as an argument, guaranteed to be executed after initialize and main. Always executed on the main thread. This can be used to copy data from the thread back to the main thread. uint period how often this task is executed, i.e. period of 1 will execute this task on every Update event. Default: 1. PTTimePair EndTime read only (until dynamic subscription can be made to work consistently) end time of this task (one of PTUpdateEvent and PTEventTime combinations).

Works for KSP 1.4-1.7

Fixed

FAR is updated to the latest KSP version but still works with 1.4+. MM and MFI for 1.6 still work in 1.7 Ferram Aerospace Research v0.15.10.0 "Lundgren" Note for Kopernicus users: DO NOT overwrite MFI that comes with Kopernicus since it is locked to that particular version Recompiled for KSP 1.7 Fix principal axes in simulation and other bugfixes (#23, @Rodhern) Fix voxelization of most stock engines (#39) Voxelization correctly handles jettison transforms with part variants (#39) Fix voxelization of InflatableHeatShield (#39) Fixed voxelization of simple heat shields (#37) Added additional nodes to GeometryPartModule (#37, #39, see PRs for more details). The new nodes should allow parts to be voxelized much closer to what is visible and handle animations better: ignoreTransform (string) ignoreIfNoRenderer (bool) unignoreTransform (string) rebuildOnAnimation (bool) NRE fixes (#36): Trying to display debug voxels with no parts in the editor Occasional NRE when voxelizing vehicle (due to race conditions?) When force closing the game from the editor with debug voxels displayed Voxelization respects part variant changes in the editor (#35) Expose IAS and EAS used by FAR in FARAPI (#34) Enable/disable FAR speed display on the navball from FARAPI (#33)

Fixed in #37. The same fix also works for stock heat shields. Expect a release next week when KSP 1.7 ships or use GameData folder from the repo for now.

Issues with FAR compatibility should be resolved by the new release.

New release is here. Fixed long-standing bug with how skinned meshes were voxelized which was exposed by ReStock. Also, debug voxels no longer cripple your game, although there might be some issues with shader compatibility since I can only test it on my one Win10 machine. Ferram Aerospace Research Continued v0.15.9.7 "Lumley" Note for Kopernicus users: DO NOT overwrite MFI that comes with Kopernicus since it is locked to that particular version Update to MM 4.0.2 Fix skinned meshes having scale applied twice in voxelization (#30) Fix new stock parts (#24, thanks @HSJasperism) Greatly improved debug visual voxels framerate (#18, #29) Enlarged debug voxel texture for higher fidelity (#18)

Just had a quick look at the log, you forgot to include that the NREs come from MechJeb calls into FAR but the bug seems to be the same one as with Trajectories.

If you want help with bugs, short excerpts from the log are not enough. I'm sorry but I don't have enough time to go bug hunting by guessing what sets it off. A proper bug report needs: Steps to reproduce said bug Possible mod conflicts Full log file However, in your case, it looks like the bug is caused by Trajectories calling FARAPI before the voxelization is complete. This bug is fixed in my fork. If you need a backport, the fastest way would be to recompile it yourself. You would only need to change to KSP version in CompatibilityChecker.cs.

I think FAR simply ignores those parts that haven't got any FAR modules attached, so the part will generate stock lift and drag which will be different to FAR values. Such parts will not affect FAR calculations but also won't be taken into account so you will get something in between stock and FAR. I don't think FAR even bothers will calculating parts overlapping but it does take into account the relative positioning of the parts with respect to each other. I'm not sure how much the values are affected by parts overlapping or even if they are vaguely accurate. Tweakscale is supported in FAR. Voxelization is redone but that takes a few frames usually, depending on the size of the craft. This also triggers an update on the active FAR modules in the craft. That's a known issue with MM in KSP 1.6, there's nothing I can do.

Or you can just search for ModuleLiftingSurface in MM cache.

Yeah, voxels will only setup cross-sectional properties, I think only colliders are needed to place the voxels which most parts have. You will still need FARWingAerodynamicModel modules to provide lift and drag which will be affected by the cross-section.

The debug voxel display performance has been fixed, you can get the latest version of FAR from master branch of https://github.com/dkavolis/Ferram-Aerospace-Research

FYI, I have fixed it on https://github.com/dkavolis/Ferram-Aerospace-Research, there is no more (or minimal) performance loss when using debug voxels although they look slightly different due to issues with rendering.

Check https://github.com/ferram4/Ferram-Aerospace-Research/wiki/Deriving-FAR-values-for-a-wing-using-Blender-2.7

There's a way to calculate ground effect approximately by using method of images and the ground as a mirror but that would require finding the reflection in the ground and recomputing wing interactions for each part each frame and that is very likely to kill frame rate near the ground. Screening interactions between physical and reflected parts may alleviate it a bit. I agree with ferram and won't add a highly inaccurate feature that very few people will use anyway. Unless anyone can find a CPU cheap implementation that will be at least approximate, ground effect is not planned. In other news: Ferram Aerospace Research v0.15.9.6 "Lin" Note for Kopernicus users: DO NOT overwrite MFI that comes with Kopernicus since it is locked to that particular version FAR is out for KSP 1.4-1.6 this time (one DLL to rule them all!) since RO is pushing for KSP 1.4.5 release. Update for KSP 1.6 Update to MM 3.1.2 Update to MFI 1.2.6 Mainly a release for RO Trying out enabling FAR for KSP 1.4-1.6 Much nicer looking anti-aliased line plots Fix NRE when Trajectories tried to access simulation before the vessel was initialized Changed icon to "FARc" to avoid confusion with the original FAR Fix MM pass in a config that is only used on first start of FAR Fix NRE when trying to save stability augmentation settings on closing KSP Get it from Github or CKAN.

It seems that those parts are missing configs for FAR. FAR replaces ModuleLiftingSurface with FARWingAerodynamicModel (you can see it in FerramAerospaceResearch.cfg). In addition, kerbalEVA and a couple new parts are also missing configs. Just find all the parts that have ModuleLiftingSurface or ModuleControlSurface in your MM cache.

Sorry, I have never tried Airplane Plus. I've created an issue #16 to keep track of it. The issue with cockpits and fuselages should be with MM configs, they are probably not patched currently. Other configs for FAR should come with the mod and not FAR itself. See https://github.com/ferram4/Ferram-Aerospace-Research/wiki/Deriving-FAR-values-for-a-wing-using-Blender-2.7 for more information.

Just replace FAR DLLs with the ones from #12 and it will work, MM and MFI for KSP 1.5 work on KSP 1.6. I'm also trying out a more relaxed compatibility checker since Squad has done a great job at preserving mod compatibility between minor KSP versions so those DLLs will work on KSP 1.4-1.6. I'll do a release when a few of the open PRs are merged in.

FAR seems to work on KSP 1.6 with the latest versions of MFI and MM (updated for KSP 1.5). If anyone wants to test for bugs, you can find DLLs on Github PR.

The latter, heavy aerodynamic stress means large aerodynamic forces on your vehicle which for aircraft happens when the airstream hits it at a large angle. Max Q is only relevant for rockets. No idea, sorry. PF works as it should on my install. Next time please provide logs and any other information that might be relevant (screenshots, steps to reproduce, save files, craft files, mod list).

It is definitely in my scope of interest, IMO it should be built into FAR, however making FAR compatible with Kerbal Wind Tunnel should be easier and faster. I'll look into what can be done. Thanks.