hab136

I've edited the first post and will ask a mod to lock. Thanks @zer0Kerbal for taking this over!

I wish I had better news. I've tried to figure out what the issue is, but haven't been able to fix it in my dev environment. I also haven't been able to dedicate a lot of time to this mod. I haven't even played KSP (other than testing) in over a year. I've updated my other mods because they just needed a quick recompile, but this one apparently needs more. I had even wanted to do a re-write, using a central controller instead of each part firing every tick and doing its own pumping (woefully inefficient), but that work never even started. Geordiepigeonowner wrote this mod (which is why it's "GPO"), Gaius maintained it after GPO left, and I picked it up after Gaius. I'd be more than happy to hand it off to the next person.

SafeChute v2.1.20 for KSP 1.10 is now released.

I finally updated AutoAsparagus for 1.9, see main page for links. Note that it has new dependencies, Toolbar Controller and Click-Through Blocker, where are also linked. I submitted a change to CKAN for the the new dependencies.

Loused up output naming? Do you mean the KSP.log output or the binaries? I've been working on updating my mods to 1.9.x; I normally do the easy ones first then the harder ones, because it's a lot easier to sort out version-specific issues on the simpler mods. SafeChute and Undockinator are already done; I still have to do AutoAsparagus and GPOSpeedFuelPump. This mod has had problems lately and some of that has been because of my testing environment, so I'll probably do it last, but hopefully soon.

Undockinator 1.1 for KSP 1.9 is out. I switched to using ToolbarController; this should eliminate any of the double icons or other weirdness with the app icon. This does introduce two new dependencies, listed below and on the main page. I've submitted a request to CKAN to add the dependencies, so they should auto-install.

Why is ZeroMiniAVC now a dependency of Toolbar Controller and ClickThroughBlocker? https://github.com/KSP-CKAN/NetKAN/commit/7deecbad489def6e23bf19e89d795902530d79b0#diff-ae9fe82cf6c88ccb776ce0cd5b3b5b64

It's not. GPOSpeedPump.dll is the correct DLL, but it should have been named GPOSpeedFuelPump.dll like previous versions. You should be able to just delete GPOSpeedFuelPump.dll and then rename GPOSpeedPump.dll to GPOSpeedFuelPump.dll. I'll do some testing and hope to put out a fixed version this week, along with a 1.8.1 version. The above issue is probably the reason. Deleting one of the DLL's may make it work. Or not? Anyways I hope to put out new versions this week.

Now that's a unique idea

It's been suggested, but not implemented. TAC Fuel Balancer can dump resources, as can Smart Parts if you attach their fuel valve before launch.

I've been away a while, and am picking up MKS again (KSP 1.7.3, MKS version 1.2.0 - 2019.08.04). My drills are overheating, even on a test ship in a new save with ridiculous amounts of cooling and no other heat sources. No other mods installed, and two 5-star engineers on board. If I use one bay on an Industrial Strip Miner, it levels off at 500 K and Thermal Efficiency is 100%. If I turn on a second bay, it levels off at 618 K and 64 % efficiency. All 5 bays on levels off at 703 K and 24% efficiency. Doesn't seem to matter how much cooling I add - dozens of large stock Thermal Control System plus dozens of MKS Ranger Thermal Control Systems have no effect. If I use multiple Industrial Strip Miners, each using one bay, they all stay at 500 K. I've even tried ten drills each using one bay and that's perfectly fine; they all stay at 500 K. But one drill using two bays, and it overheats. Is this working as intended? I can design around it if need be (just add MOAR DRILLS), but I don't remember it working this way.

There was an issue with my dev environment which has now been fixed with v2.1.18. Please update when you can and it should fix the issue.

Thanks, merged. I'm still having weird issues, so there must be another bug but I don't see it. Yep, NFC uses B9 part switch which is already supported via Patches/FuelSwitch.cfg, but GPO specifically looks for "moduleID = fuelSwitch". NFC seems to only change the mesh (moduleID = meshSwitch): MODULE { name = ModuleB9PartSwitch isEnabled = True stagingEnabled = True moduleID = meshSwitch currentSubtype = LFO EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } GPO used to simply apply to all B9 part switch parts, but that was changed back in January to be less annoying: https://github.com/henrybauer/GPOSpeedPump/commit/7bd4c933464b7a53299144b56c058e6f9d274849#diff-cc999a1c941fa29030bf9659351837e8 If you want to revert to the old way, just remove ":HAS[#moduleID[fuelSwitch]]" from Patches/FuelSwitch.cfg. Testing on subtype (HAS[#currentSubType[LFO]) doesn't seem to work, probably because it's a variable that switches, not something that exists always. Explicitly naming the NFC parts seems like the best option, so I'll see about getting that in the next release. I really need to fix whatever the remaining balancing bug is, which means adding lots of logging/instrumentation and then running a bunch of testing to find it. As I get free time I'll work on it. At least it's easily reproducible on my test ship.

Undockinator v1.0.3 for KSP 1.7.3 is released, which fixes a bug that caused the icon to not show up.

I was unable to reproduce this problem until I finally just created a Windows VM and installed KSP on it. Then it was obvious - the DLLs are totally different between OS X and Windows. On OS X, there's like a bazillion UnityEngine DLLs whereas on Windows there's only UnityEngine and UnityEngine.UI. So when I linked UnityEngine.CoreModule on macOS, it just doesn't exist on Windows. Or rather, it's rolled into UnityEngine.dll on Windows so you don't have to link it separately. I vaguely remember this problem.. I've moved my development environment around over the years, from Linux to Mac to Windows and just now back to Mac, and I guess I forgot about it. It of course worked on my own Mac because UnityEngine.CoreModule.dll exists on macOS. Compiling against the Windows DLLs produces a DLL that works on Windows and macOS versions of KSP. I didn't test Linux but I'm fairly certain it will work. v2.2.18 is out now to fix this issue: https://github.com/henrybauer/AutoAsparagus/releases/tag/v2.2.18