• Content Count

  • Joined

  • Last visited

Community Reputation

101 Excellent


About DoktorKrogg

Recent Profile Visitors

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

  1. Yes. It's a completely new system and doesn't affect any of the existing systems like MKS, USI-LS, etc.
  2. Your original question was about transferring resources to orbit. Orbital Logistics does that. It's a completely separate system from Planetary Logistics with its own user interface. Unlike Planetary Logistics, Orbital Logistics doesn't require special containers.
  3. In addition to WOLF, there is also Orbital Logistics which is already part of MKS. Orbital Logistics only works within the same sphere of influence though. WOLF will allow you to setup transfers basically anywhere (e.g. Mun surface -> Mun orbit, Mun orbit -> Duna surface, Mun surface -> Duna surface, Mun east crater -> Mun canyons, etc.). Any biome connected to WOLF is eligible as the start or end point of a transport route. It's pretty awesome.
  4. Are you asking if I have anything to include in the PR? If so, then no, not yet. My game development computer is in pieces while I wait on some new cables, so I haven't had time to test any of my ideas yet unfortunately. Cables should arrive later this week.
  5. Here's a good primer on logistics: Also, once WOLF is finally released, I think I'm going to try to either start doing some Twitch streams and/or put together a YouTube series that demonstrates everything USI from start to finish in a fresh career-mode save, including WOLF. So that might be a good way to see logistics in action without really having to experiment with it yourself. Hmm... probably not, at least not in its current form. I'll have to think about that some more. If nothing else, the code for ModuleLogisticsConsumer might be a good starting point for you to implement a similar feature in GC. Since @RoverDude has decided to make GC a supported mod within the USI sphere, it's also possible that this could work the other way where USI logistics can "push" resources into GC if you provided some sort of hook for us to be able to do that.
  6. That would be awesome! It's actually not that big a deal to just have 2 buttons in the PAW, it would just be helpful if they were labeled something like 'Ground Workshop' and 'Orbital Workshop'. Take a look at ModuleLogisticsConsumer in USITools ( as a starting point. Feel free to PM me and/or @RoverDude if you have specific questions or have suggestions for architectural changes to expose more hooks into that system.
  7. It has admittedly been a while since I last looked at this but I did have these ModuleManager patches working with both GroundWorkshop and SingleVesselConstructionWorkshop modules on the same part at one point. It just resulted in 2 Workshop buttons in the PAW, one that launched the UI for the GroundWorkshop module and one that launched the UI for the SingleVesselConstructionWorkshop module.
  8. Regarding GC, @goldenpsp is correct that orbital construction is relatively new and there are no MKS parts specifically made for it. Because of the way it's implemented, having the ability to do both ground and orbital construction from the same part results in duplicate buttons in the PAW with no indication as to which is which. It's difficult to tell even from the UI if you've open the ground workshop or orbital workshop. The only way to tell the difference is to try to queue up a task. I have written a ModuleManager patch that will update the Tundra Assembly Plant and 2.5M Workshop to also allow orbital construction but again, due to the confusing duplication of buttons in the PAW, I have not yet created a PR for it. If anyone is interested in testing out the patch and can live with the duplicated buttons, here are the relevant patches: // For ground construction @PART[Tundra_AssemblyPlant]:HAS[!MODULE[GroundWorkshop]]:NEEDS[GroundConstruction] { MODULE { name = GroundWorkshop workshopType = GROUND Efficiency = 3 } } // For orbital construction @PART[Tundra_AssemblyPlant]:HAS[!MODULE[SingleVesselConstructionWorkshop]]:NEEDS[GroundConstruction] { MODULE { name = SingleVesselConstructionWorkshop workshopType = ORBITAL } }
  9. It doesn't just show up in the PAW twice, the buttons actually open different instances of the workshop UI which can be confusing since one of them will work and the other won't, depending on the vessel's situation. There isn't really a visual cue either as to which workshop window is the "right" one. This isn't really an MKS issue. More of a GC issue. @allista might have some thoughts though on how to allow a single part to serve both roles.
  10. I think I'm seeing the same behavior for all mods. Running version 1.8.0- of KSP-AVC. I get messages that mods are out of date but no notification that updates are available. I figured it was just taking modders a while to get updates out but I manually checked today and most of the mods that KSP-AVC said were out of date actually had been updated 2 or 3 weeks ago. There was no notification in KSP-AVC that updates were available though. Here is a before and after log from manually updating a mod (Kerbal Planetary Base Systems): Before After
  11. Looking at the part configs, it seems that all of the MPU recipes are configured to make what what they claim to make.
  12. There are no hard dependencies between MKS and GC. It has been removed from the 'official' MKS bundle for now (i.e. on GitHub). CKAN may be a different story.
  13. WOLF and the Atlas series parts (aka the domes) will be bundled with MKS when they're released. As for the timing, I don't have any info on that presently. I can say that the part configs are 95% done for the Atlas parts and I think the models are also done. So we just need to get the model-specific info added to the part configs and they should be ready for release. As for WOLF, I'm still working on the hopper models and there are still a few minor bugs/tweaks that need sorting out. We're also doing a reskin of the Tundra models for the WOLF parts.
  14. This message is displayed when the part with ModuleOrbitalLogistics is no longer attached to the vessel it was attached to when the transfer was created. There are 2 things going on here that OrbLog was not really built for: Having multiple ModuleOrbitalLogistics on the same vessel Movable/Dockable OrbLog vessels The assumption with OrbLog is that you'll be transferring resources between permanent bases/stations. Using OrbLog any more "creatively" than that is a "do it at your own risk" sort of thing. OrbLog looks at both the vessel ID and the module ID for the origin and destination vessels. Vessel IDs have a tendency to get changed every time vessels are docked/undocked from one another though, so any docking/undocking operations that occur while an OrbLog transfer is in progress is likely going to result in a failed transfer. As to how you ended up with 2 OrbLog modules with the same module ID is a bit of a mystery (since they're GUIDs which are supposed to be unique) except that again, OrbLog doesn't expect to find 2 OrbLog modules on the same vessel. So that may have something to do with it. More specifically, it uses KSP's Vessel.FindPartModuleImplementing method to locate the OrbLog module when setting up a transfer. When there are multiple modules, I expect that KSP probably just returns the first one it finds, which may not always be the same one. TL;DR ... Yeah, kinda. Keep a look out for WOLF which is coming soon™. We expect WOLF to be a more attractive way to do the sorts of things that players currently use Planetary Logistics and Orbital Logistics for.