Jump to content

hab136

Members
  • Posts

    1,079
  • Joined

  • Last visited

Everything posted by hab136

  1. 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.
  2. SafeChute v2.1.20 for KSP 1.10 is now released.
  3. 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.
  4. 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.
  5. 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.
  6. Why is ZeroMiniAVC now a dependency of Toolbar Controller and ClickThroughBlocker? https://github.com/KSP-CKAN/NetKAN/commit/7deecbad489def6e23bf19e89d795902530d79b0#diff-ae9fe82cf6c88ccb776ce0cd5b3b5b64
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. Undockinator v1.0.3 for KSP 1.7.3 is released, which fixes a bug that caused the icon to not show up.
  13. 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
  14. 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'
  15. Odd; can you put the KSP.log file on Dropbox or Google Drive or something so I can look at it?
  16. It's not stopping time warp? Are you using stock parachutes or custom ones? Any other mods that might be relevant?
  17. GPOSpeedFuelPump v1.8.19 for KSP 1.7.3 is released
  18. SafeChute v2.1.17 for KSP 1.7.3 has been released.
  19. 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.
  20. @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.
  21. @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.
  22. 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.
  23. The speed is not configurable. I'll add that as a requested future enhancement. For SSTU: I took a quick look but don't understand what part switcher they're using. Look at Patches/ProceduralTanks.cfg, you could write a similar one for @PART[SSTU-TANK*] For US 1/2, looks like they use their own part switcher: // Universal Storage Part Switch Config // Used to set resources, cost and mass or different versions of the part MODULE { name = USFuelSwitch SwitchID = 0 resourceNames = MonoPropellant;MonoPropellant;MonoPropellant;MonoPropellant resourceAmounts = 30;60;90;120 initialResourceAmounts = 30;60;90;120 tankCost = 0;83;166;249 tankMass = 0;0.011;0.022;0.033 hasGUI = False availableInEditor = False displayCurrentTankCost = True ShowInfo = False Look at Patches/FuelSwitch.cfg and add a new entry for "HAS[@MODULE[USFuelSwitch]]"
×
×
  • Create New...