DoktorKrogg

Yes. It's a completely new system and doesn't affect any of the existing systems like MKS, USI-LS, etc.

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.

In addition to WOLF, there is also Orbital Logistics which is already part of MKS. https://github.com/UmbraSpaceIndustries/MKS/wiki/Functions-(Logistics)#orbital-logistics-within-a-sphere-of-influence 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.

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.

Here's a good primer on logistics: https://github.com/UmbraSpaceIndustries/MKS/wiki/Functions-(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.

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 (https://github.com/UmbraSpaceIndustries/UmbraSpaceIndustries/tree/master/USITools/USITools/Logistics) 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.

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.

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 } }

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.

I think I'm seeing the same behavior for all mods. Running version 1.8.0-1.4.0.3 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

Is this explained on the wiki somewhere and I'm just not seeing it?

Looking at the part configs, it seems that all of the MPU recipes are configured to make what what they claim to make.

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.

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.

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.

So the hang on "Verifying Breaking Ground..." is caused by Firespitter. Unfortunately this isn't a quick fix because some of the Firespitter code relies on the old Unity particle system which was deprecated in Unity 2017 and removed in Unity 2018 (KSP 1.8 includes a bump to Unity 2019). I have zero experience with the particle systems, so I'm not sure what all is involved in getting this fixed. Despite what CKAN and KSP-AVC say, the USI mods will require updates before they're fully compatible with KSP 1.8. I have made pull requests for USITools, MKS, USI-LS and WOLF with the required updates. Unfortunately, we can't put out official releases until we get Firespitter sorted out. RD is on vacation the rest of the week and I'm busy on getting WOLF ready for release, so it may be a while unless someone who knows their way around the particle systems wants to figure out how to fix Firespitter.

Hey @TheSuMa thanks for the suggestions re: WOLF and welcome to the forums. This is actually the right place to post about WOLF. It will be bundled with MKS once it releases. I think we will want to get WOLF released and then get more feedback from players before we make any changes to the way transport routes are currently implemented. One of the key design goals with WOLF was to keep it as simple as possible to make the code easy to maintain and to make the mod easier to explain to new players. We aren't really that worried about "cheating" since KSP is a single player game. If people want to exploit systems, the only person they're cheating is themselves. If we do decide at some point to impose additional restrictions on what counts toward the payload and cost calculations for transport routes, then we will probably add something like a "WOLF cargo crate" to the game with a fixed mass that is used to determine payload capacity and then maybe also hook into global construction to determine the complexity and "cost" (in MatKits) of the vessel itself. For now though, I feel good about the decision we came to during the stream and I want to see how it plays before we make more drastic changes.

https://github.com/UmbraSpaceIndustries/MKS/wiki/Functions-(Efficiency-and-Load)#planetary-bonuses Scouts (and Pilots) are immune to Habitation effects in USI-LS as long as they're in a vessel with at least 1 year of hab time: https://github.com/UmbraSpaceIndustries/USI-LS/wiki#habitation

Welcome to the forums! https://github.com/UmbraSpaceIndustries/MKS/wiki/Crew-Skills-Impact-on-Parts Short version: MKS introduces several additional skill traits to KSP that are required to operate various bits of MKS equipment. Pilots, Scientists and Engineers are a "jack of all trades" sort of Kerbal who possess several of the traits. Specialists can typically only do one thing. If you scroll to the bottom of that wiki page, it gives descriptions for what each one does. Miners, for instance, give an efficiency boost to drills (Engineers can also do this). Quartermasters specialize in logistics and are required by the logistics parts (Pilots can also do this). If those descriptions aren't clear enough, then you may have to ask more specific questions about which roles aren't clear. (Side note: There is a secondary background mechanic in MKS where Kerbals contribute to colony bonuses overall and those bonuses also feed back in to boost efficiency. So the more Kerbals you have on the ground, the more efficient the colony is as a whole. Colonies slowly accumulate Funds, Science and Reputation rewards based on colony bonuses as well.) PS We're getting ready to make specialists a lot more expensive in the next release. They'll still be cheaper than the original 3 but it will be more like 50% cheaper, not 50x cheaper.

Just a heads up RE: drills... since the overheating "bug" has been reported over and over and over again (it's not a bug), we are likely going to remove the multiple drill head concept in a future MKS release. With WOLF coming out of beta soon™, we expect the harvesters and hoppers in WOLF to be a more appealing way to do massive resource harvesting anyway vs. big, framerate-killing, kraken-enraging MKS bases with dozens of industrial strip miners.

We need some clarification on what 'functioning' means here. The workshops have multiple personalities. They can be used to manufacture things and they can be used to build vessels on location with Global Construction. You mentioned workforce which is a GC thing (I think), so you might want to head over to the thread for that mod to get more information on how it works. It's a little bit unintuitive so reading the instructions is a big help in this case.

Adding to what @goldenpsp said... The ground tethering function is provided by a PartModule in USITools called 'USI_InertialDampener'. There isn't actually a need to fork USITools because it's already provided as a standalone mod here. As pointed out already, it's fairly trivial to write ModuleManager patches to add a PartModule to a part from the stock game or even to parts from another mod. So say you wanted to add the ground tethering function to the stock Modular Girder Segment, just create a new .cfg file (they're plain old text files) anywhere in the GameData folder and put something like this in it: @PART[trussPiece1x]:NEEDS[USITools] { MODULE { name = USI_InertialDampener } } In a nutshell what that's telling MM is: if the mod called 'USITools' is installed, modify the part named 'trussPiece1x' to add the PartModule called 'USI_InertialDampener'.

The PartModule that allows a part to participate in Planetary Logistics is USI_ModuleResourceWarehouse and it shows up in the part info window in the VAB/SPH as 'USI Warehouse'.

For those following WOLF development news... I just submitted a PR with several balance changes that we'll likely be showing off on Twitch this Sunday. We will also probably provide another download link to the latest beta version at the end of the stream like we did in the last stream.

WOLF and MKS can both stand on their own. We think you'll ultimately have a better experience if you use both mods together but neither of them depends on the other. It will kind of be up to the player then to determine where they want to draw the line between what they use WOLF for and what they use MKS for. I like to think of WOLF as a way to offload the "busy work" of colony building and management onto your Kerbals. You tell them which biomes to colonize, you deliver the equipment and personnel and they do the rest. Once equipment and Kerbals are "deployed" in WOLF, they literally disappear from the game and become numbers in the WOLF UI. The WOLF production chain is very similar to the MKS production chain, you just don't see any of it happening. Where WOLF and MKS intersect is that you can pull resources out of WOLF (via a new part we're calling a Hopper) to use by any other mod that relies on the stock resource system (MKS, USI-LS, GroundConstruction, etc.) WOLF has lots of new parts. Most of them will be reskinned MKS parts though. You also won't get to see them very long because they'll disappear from the game once they're connected to WOLF. The domes and the new giant harvester are Atlas parts which will be included in a future MKS release. Something we have talked about adding to WOLF eventually is the ability to spawn huge, single-part vessels to serve as a visual representation that a biome has a WOLF colony in it. We've talked about hiding most of the model initially and revealing new bits as the WOLF colony hits certain milestones. Yes! Come watch us blow stuff up, see WOLF in action and listen to us ramble about it.