hab136

Members
  • Content Count

    1,070
  • Joined

  • Last visited

Community Reputation

524 Excellent

About hab136

  • Rank
    Master of Asparagus

Contact Methods

  • Website URL Array

Profile Information

  • Location Array
  • Interests Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. Undockinator v1.0.3 for KSP 1.7.3 is released, which fixes a bug that caused the icon to not show up.
  5. 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
  6. It's not loading because it can't find "UnityEngine.CoreModule". It works on my machine, and I see your other mods are loading correctly. Can you try this updated DLL and see if it works for you? Just overwrite the existing DLL in GameData with this new one. https://github.com/henrybauer/AutoAsparagus/releases/tag/UnityEngine.CoreModule [ERR 19:35:33.940] AssemblyLoader: Exception loading 'AutoAsparagus': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.TypeLoadException: Could not load type 'AutoAsparagus.PopupMenuDrawable' from assembly 'AutoAsparagus, Version=2.2.17.0, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type 'AutoAsparagus.Button' from assembly 'AutoAsparagus, Version=2.2.17.0, Culture=neutral, PublicKeyToken=null'. System.IO.FileNotFoundException: Could not load file or assembly 'UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' System.IO.FileNotFoundException: Could not load file or assembly 'UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' System.IO.FileNotFoundException: Could not load file or assembly 'UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' System.IO.FileNotFoundException: Could not load file or assembly 'UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' System.IO.FileNotFoundException: Could not load file or assembly 'UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
  7. Odd; can you put the KSP.log file on Dropbox or Google Drive or something so I can look at it?
  8. It's not stopping time warp? Are you using stock parachutes or custom ones? Any other mods that might be relevant?
  9. GPOSpeedFuelPump v1.8.19 for KSP 1.7.3 is released
  10. Undockinator v1.0.2 for KSP 1.7.3 is released.
  11. SafeChute v2.1.17 for KSP 1.7.3 has been released.
  12. AutoAsparagus v2.2.17 is released for KSP 1.7.3. @aat I haven't had time to look at the icon issue; this is just a recompile.
  13. @Gordon Dry thanks, will add it to next release @Tinkman that's a good idea, I'll see about it. I probably won't have time to work on my mods till the end of the month.
  14. @danshu15 glad you got it sorted. To answer your question I haven't updated for 1.7 but plan to. I probably won't get any programming time until the end of the month though. No. It only stops time warp.
  15. CKAN entries have an identifier, and then the name that shows up in the list. If you look in the bottom right under "Metadata", you'll see "Identifier: Goodspeed" or "Identifier: GPOSpeedFuelPump". Originally there was "Goodspeed", which pointed to Goodspeed's version, then GeordiePigeonOwner's version. It stopped updating when GeordiePigeonOwner stopped updating it. https://github.com/KSP-CKAN/CKAN-meta/tree/master/Goodspeed When I took over, I made a separate entry "GPOSpeedFuelPump". https://github.com/KSP-CKAN/CKAN-meta/tree/master/GPOSpeedFuelPump Then one of the CKAN admins said it would make more sense to use the original entry, so he changed "Goodspeed" to point to my Github, but didn't update the author. So yes, "Identifier: Goodspeed" is the correct one. I can ask to update the author if that will cause less confusion. Maybe they can hide the other one too.