Crzyrndm

Make forwarding functions that call a single worker?

I couldn't tell you, I was only searching in the MM cache included in the uploaded log. UrlConfig { name = KWFin type = PART parentUrl = KWRocketry/Parts/Aero/KWFin/KWFin url = KWRocketry/Parts/Aero/KWFin/KWFin/KWFin PART { name = KWFin //... MODULE { name = ModuleControlSurface dragCoeff = 0.8 deflectionLiftCoeff = 1.5 ctrlSurfaceRange = 15 ctrlSurfaceArea = 1.0 } //... MODULE { name = FARControllableSurface nonSideAttach = 0 MAC = 1.311 MidChordSweep = 29.375 maxdeflect = 15 b_2 = 1.2 TaperRatio = 0.5 ctrlSurfFrac = 0.3 } //... } } UrlConfig { name = KWFinGC type = PART parentUrl = KWRocketry/Parts/Aero/KWFinGC/KWFinGC url = KWRocketry/Parts/Aero/KWFinGC/KWFinGC/KWFinGC PART { name = KWFinGC //... MODULE { name = ModuleControlSurface dragCoeff = 0.8 deflectionLiftCoeff = 1.5 ctrlSurfaceRange = 15 ctrlSurfaceArea = 1.0 } //... MODULE { name = FARControllableSurface nonSideAttach = 0 MAC = 1.311 MidChordSweep = 23.84 maxdeflect = 20 b_2 = 1.2 TaperRatio = 0.6 ctrlSurfFrac = 0.3 } //... } }

Known issue caused by the way these wings have to be setup for symmetry to work in every other case. I have not found a way around it

That was a list of all the parts in the MM cache that still had the stock control surface module present (FAR installed). The majority of those had FAR nodes as well, so everything still worked. The only issue would be that the patch adding the FAR node, didn't remove the stock one (and I'm not even sure it's a problem. At worst it's the inefficiency of having both stock and FAR modules trying to do the same job). The "fix" (optimisation?) is just to remove the stock node when FAR is present @Gordon Dry Defaults update -> restore loads something other than what was just saved: Unable to replicate. If I change the setting, hit update, change again, hit restore, it gives me back what I set at the update Output stuck at 25%: Sounds like a configuration issue, 25% is the default minimum deflection for Q in excess of 160. Since I see no errors in the log, the only assumption I can make is that the configured change from 25% to a much larger value was extremely abrupt. Need to see configuration to be of assistance, but that is a huge change from the default... Exceptions: Probably to do with the "Remove" buttons. They've always been a little funky And to reply to your post in the Pilot Assistant thread about the mods cooperating, they do, just not quite in the way you imagine. DD was originally designed as a component of Pilot Assistant (it worked for a broader range of applications so got to be standalone). The reason Pilot Assistant knowing what DD is doing won't do anything, is that PA knows absolutely nothing about the vessel it is in control of to start with. It flies purely on current Heading / Altitude / Velocity / Pitch / etc. (Hence why it requires manual tuning for best performance). With control authority at 1/3 of what the default DD config gives, yes PA will struggle unless you retune it to match (the shipping defaults for DD are designed for PA after all)

The issue is rather simple. You have FAR installed, DD expects control surfaces to be using the FAR module ("FARControllableSurface"). However, there are a number of control surface parts that have not been patched and still have the stock part module instead Note: Most of the below list just haven't removed the stock module (they should be). The AirplanePlus parts however do not have any FAR replacement and this is what's causing DD to flip its lid AirplanePlus/Parts/Aero/elevonhalf/part/hlfSrf AirplanePlus/Parts/Aero/roundfin/part/roundwinglet AirplanePlus/Parts/Aero/smallwings/elevon2b/elevon2b Bluedog_DB/Parts/EarlyRockets/bluedog_redstoneCS/bluedog_redstoneCS KWRocketry/Parts/Aero/KWFin/KWFin/KWFin KWRocketry/Parts/Aero/KWFinGC/KWFinGC/KWFinGC LonesomeRobots/DynaSoar/ElevonL/DynaElevonL LonesomeRobots/DynaSoar/ElevonR/DynaElevonR LonesomeRobots/DynaSoar/WingLeft/DynaWingL LonesomeRobots/DynaSoar/WingRight/DynaWingR SSTU/Parts/ShipCore/Series-E/SC-E-EL/SSTU-SC-E-EL SSTU/Parts/ShipCore/Series-E/SC-E-ER/SSTU-SC-E-ER SSTU/Parts/ShipCore/Series-E/SC-E-WT/SSTU-SC-E-WT UmbraSpaceIndustries/SoundingRockets/Parts/SR_GridFin_01/SR_Gridfin_01 UmbraSpaceIndustries/SoundingRockets/Parts/SR_GridFin_02/SR_Gridfin_02 UmbraSpaceIndustries/SoundingRockets/Parts/SR_GridFin_03/SR_Gridfin_03 UmbraSpaceIndustries/SubPack/Otter/Parts/DivePlane/MiniSub_DivePlane UmbraSpaceIndustries/SubPack/Otter/Parts/SubRudder/MiniSub_Rudder WarpPlugin/Parts/Microwave/Hybridwings/heatfin/heatfin

I need the full log. I'm guessing the module has been incorrectly added to a part without a control surface EDIT Vessel also as this is likely to be a specific part

The fix is still in place this time Test without it to be sure that it is DD (most likely. Not much else fiddles in the same manner...), and a vessel for testing that can reliably reproduce this would be very helpful

Main categories are still ordered by loading order (hence the file numbering and other such tricks). Something I forgot to fix with 3.0... That config isn't going to find any parts because it's asking for the parts to be on that path (relative to GameData) AND under one of those folders. Use a single path node (comma separators like normal) for all three and you won't need the outer check node either. (The other option is to put the path and folder nodes into an inverted check node and invert both checks. this will give !(!A AND !B) which is equivalent to (A OR B) PartModuleFilter doesn't require any CHECK node. However it may require the subcategory to be valid without those parts (ie. make sure it has at least one part through its own filters otherwise it might get discarded as having no suitable parts). I can't check right now whether this is actually the case (it shouldn't be, but it may be)

If you can't change settings in flight, that's a bug As @Starwaster mentions, the reason for the choice of field was in order to work side by side with the user control (as this is the only stock control for deflection angles, I don't want to remove that option) Modifying the settings in flight is the same as in the editor (Place mouse over the control surface and press 'K'). In the flight window, there is also a readout showing the current control percentage, Dynamic Pressure (Q), and a simple graph plotting the input points and the current output (dropdown at the bottom of window) As far as observing that it's working, my favourite used to be an Aeris 3A (with a whiplash for ease of use)going full throttle and just watching stock SAS shake itself to pieces above ~200m/s. Happy to say that is no longer an issue (well, until you hit ~1000m/s at sea level...) but with that gone and stock still being rather difficult to disintergrate by pulling up too hard, it does make the effect of DD much less compelling. It's main use now is for FAR (preventing those "oops I pulled up too hard" moments for keyboard players), and making life easier for flight control mods (I basically expect anyone using Pilot Assistant to also use this. It was originally a sub component of PA, I pulled it out as a standalone because it had many uses)

Version 3.0.2 released to fix more icon issues The filters in the categories are intended to allow a particular subset of parts to be shown in the subcategories that come under it (ie. parts have to satisfy category AND subcategory filters). Particularly useful for the Mod categories where it can reuse the generic subcategories defined primarily for "Filter by Function" but only showing the parts from a particular path/folder. The issue with allowing the category to be standalone is that then changes the behaviour of the "All parts.." subcategory from "all parts visible in the subcategories" (intended), to "all parts that satisfy the category filter" (not intended).

The issue is that you're doing something I never thought of . On consideration, I do not believe I will be changing the plugin to retain backwards compatibility as this effect was unintentional and does change the behaviour slightly (helps that the fix is very simple as well). The correct way to do this is to use a separate SUBCATEGORY node and reference that from the category (rather than (slightly) abusing the template mechanism) which is only a very minor modification. I've modified the fuel one appropriately below CATEGORY { name = Fuel icon = stockIcon_fueltank colour = #FF90F090 // Modifications begin SUBCATEGORIES { name = Fuel } } SUBCATEGORY { name = Fuel icon = stockIcon_fueltank // modifications end FILTER { CHECK { type = category value = FuelTank } CHECK { type = title value = adapter invert = true } CHECK { type = moduleName value = ModuleLiftingSurface, ModuleCommand invert = true } } }

What causes them? Normal culprits are File IO (eg. logging) and/or heavy use of reflection, but anything can do it if you do it too much. In this case, throw debug statements at the function and check the timestamps in the log would be the simplest IMO Treatment depends on the culprit. 90% of the time, you'll find that you're just doing something more often than is actually required. The other 10% you have to play smarter (coroutine to divide work across several frames, separate thread for the really heavy stuff, caching results, preloading, ...)

I've updated the shipping icons/cfg with 3.0.1 and it appears to work as expected with the current github parts

I'm going to have to look into that a little further, I don't see any reason why that shouldn't be working as expected (the filter showing up at all obviously indicates that the patch is being applied which was my first thought)

B9 and original Pwings rebuilt for KSP 1.3

New release is available for KSP 1.3 (v1.13.2)

@argentrolf I would not describe it as realistic ever. This is a far too simplistic model for that. But essentially yes, if you make those two changes you can only regain RW power by either unwinding, or discharging resources All plugins have now been rebuilt for KSP 1.3

Filter Extensions v3.0 is now available KSP 1.3 compatible All possible functionality "loaded and compiled" at first main menu entry. This does create a noticeable hitch but is preferable once at menu than multiple slowdowns in editor scene Fix for crash caused by invalid module name (reported by @Gordon Dry) Fixes to bulkhead profiles by @Kerbas_ad_astra NOTE: The major version increment reflects just how much of the plugin has been changed. I am expecting a few issues and oversights to pop up and will be trying to squash them quickly NOTE 2: pre 3.0, each time a subcategory was selected all checks involved were run against every part available (which parts satisfy these conditions). Post 3.0, the result is being stored at the main menu, and opening the subcategory only involves a lookup (which parts are in this category). The end result is that Filter complexity can now be essentially unbounded without having subcategories that take time to "open"

It's the folder/path check types that aren't aware of the locations of MM copies (so if you dont use those, they should show up without issue), and when I said a MM change, I meant the MM plugin would have to start setting the path not some changes to patches

Fuel support also works for stock, but it does appear another special case would be beneficial for Configurable Containers

Don't adjust part mass directly (since 1.0 if memory serves). You need to implement the IPartMassModifier interface (alternatively just use a resource?). Example implementation: https://github.com/Crzyrndm/B9-PWings-Fork/blob/master/B9 PWings Fork/WingProcedural.cs https://github.com/Crzyrndm/B9-PWings-Fork/blob/master/B9 PWings Fork/WingProcedural.cs#L3312-L3322

Easy for FE to defend against, and the mod author of the part module which is causing this should be sorting out. I will have a new version in the next few days, my KSP 1.2 copy is not currently operational...

One of the parts has a part module with an invalid module name. That really shouldn't happen, but is easy enough to defend against...

And after you found and fixed the issue too -.-. Not my best moment ever (I'm wondering if I did the refactor with out doing a git pull...) It would probably work. I can't say that I've tested it, but the theory is sound

I may have accidentally done "bad things" () to that fix while refactoring the aero module interface prior to 1.2.2.2 I'll get a new version up shortly