DoktorKrogg

Something that may not be immediately apparent is that every SwapOption you add to a part config becomes available to every bay on that part. So when that part is loaded, USITools does a couple things: Creates an array containing each SwapOption. SwapOptions are just recipes that can be loaded into a converter. Creates an array containing each USI_Converter (or USI_Harvester). SwapOptions and Converters are added to their respective arrays in the order they appear in the part config. The moduleIndex field on the SwappableBay corresponds to the array index of the converter it's responsible for. There is another field on the SwappableBay called currentLoadout that corresponds to the array index of the recipe/SwapOption that it's currently setup to use. This always defaults to 0 (i.e. the first recipe/SwapOption) until the player manually selects another recipe via the PAW. That's why you're seeing 2 bays with the Hab module. This also usually isn't specified in the part config because the fact that it defaults to 0 is usually the desired behavior on multi-bay parts. I suspect what you're trying to accomplish is to "lock" the first converter into the Hab configuration and the second converter in the Recycler configuration. If that's the case, there is a way to do that: MODULE { name = USI_SwappableBay bayName = Bay 1 moduleIndex = 0 hasPermanentLoadout = true currentLoadout = 0 } MODULE { name = USI_SwappableBay bayName = Bay 2 moduleIndex = 1 hasPermanentLoadout = true currentLoadout = 1 } The hasPermanentLoadout field "locks" the recipe/SwapOption that's used on that bay and won't allow the player to change it in game. If you set hasPermanentLoadout to true, then you also need to specify which recipe/SwapOption to use with the currentLoadout field. The arrangement in the part config doesn't matter. We only group each of the module types together for the sake of organization. It's a lot easier to see at a glance how many bays and swap options there are when they are grouped together. It's also easier to make sure your bays have unique moduleIndex values when they're grouped together.

I just submitted PR#136 to hopefully address both of these issues. I added a new MM patch that looks for any part that holds MatKits and then adds the USI_ModuleRecycleBin if it doesn't already have it. I also noticed that the patch for USI_ModuleFieldRepair didn't have an @ in front of the RESOURCE filter. So hopefully adding that will fix that patch as well. If any of you who have been experiencing either of these issues would like to try out these fixes before we merge them into the next release, that would be helpful.

WOLF has its own resource chain that's similar to MKS and USI-LS but has some important differences. Basically what we've done is "bake in" all the MKS and USI-LS mechanics into the recipes for WOLF parts. For example, Machinery requirements have been folded into a new resource called Maintenance. Maintenance is produced with a Maintenance Module that takes as inputs MaterialKits, Power, EngineerCrewPoints, MechanicCrewPoints and KolonistCrewPoints. Likewise, all of the USI-LS requirements have been folded into two new resources called Habitation and LifeSupport. Habitation is produced from Power and MatKits; LifeSupport from Food, Oxygen, Water, Power and MatKits. TransportCredits are made from Fuel, Maintenance, MatKits, QuartermasterCrewPoints and PilotCrewPoints. We've tried to give each experience trait (i.e. Scientist, Mechanic, Farmer, Kolonist, etc.) an important and meaningful job in WOLF. Something I feel that I need to make clear is that when I say equipment and Kerbals are "absorbed" into WOLF, I mean that they no longer exist in the save. They just become numbers in a spreadsheet. We plan to have a way eventually to support colony growth and to essentially have a "Kerbal hopper" that allows you to spawn Kerbals back into the game from WOLF. For now though, if a Kerbal signs up to live in a WOLF colony, it's a one way trip. So if you have particular Kerbals that you're attached to, you probably shouldn't send them to live in a WOLF colony for now. I think we're going to need to wait to get feedback from the beta before we decide how we want to further enhance the experience of adding Kerbals to WOLF and pulling them back out later. It's been a while since I last looked at the code, so I can't remember off the top of my head if we allow CrewPoints to be transferred between depots or if they are one of the things we blacklisted. If they are allowed, then they will just work the same way as a regular resource transfer. When a Kerbal joins a WOLF colony, they can only do so if there's enough LifeSupport and Habitation to support them. We assume that Kerbals understand going in that joining a WOLF colony is a one-way trip and that WOLF colonies are fancy enough to keep their inhabitants happy and healthy. So hab and home timers are not a thing in WOLF. That means there is no need for crew rotations and thus transferring Kerbals between depots probably won't be something that you find yourself wanting to do on a regular basis. Again, we'll have to see what feedback comes back from the beta to get a better idea of what things players find themselves wanting to do but can't. For now we're just taking the easy route and using the final vessel mass at the destination as the route payload. There's a lot of variability in ship design that can affect the ratio of useful cargo space, so I think it's going to be tough to come up with a one-size-fits-all algorithm for determining a more realistic payload number. If this turns out to be something that everyone feels is important to model though, then we might do something like create a WOLF "cargo crate" that has an adjustable mass that we'll then use at the destination to determine the final payload number. There is a part in WOLF called a Depot Module that can be created via any means you can currently create parts in the game (e.g. VAB, SPH, GC, EL, whatever). There is an option in the PAW to 'Establish Depot' that will cause the part to disappear and will add the depot to the list of "activated" biomes in the WOLF UI (it looks and works a lot like the MKS UI). There will be an option then to spawn a pre-made base in that biome if you want a physical representation/reminder that you have a colony in that biome. Once a biome has been colonized, there is no benefit to deploying additional depots and thus isn't allowed. Since most WOLF recipes require WOLF resources, you get a free starter depot at the KSC with the basic resources required to expand out from there. So you'll actually have to colonize Kerbin to some extent before you can start sending resources to orbital stations, the Mun, Minmus, etc. And yep... you're already starting to see how strategy will play a big role in WOLF. Picking the first biome to colonize on a new planet will be important. Setting up your transport routes via rovers to adjacent biomes will essentially give you free transport. Setting up factories for new WOLF parts will be important. This is where I see MKS and something like GC still playing an important role in a WOLF save. An MKS + GC factory pulling it's resources out of WOLF via hoppers will be great. I think you'll want to use MKS for leveling up Kerbals too before sending them to live in your WOLF colonies. Filling your WOLF colonies with one-star and two-star Kerbals will be a baaaaaad idea. I think it will still make sense to still use USI-LS too just for that extra bit of challenge while you're leveling Kerbals up and having them work at your WOLF parts factories. Again, you'll be able to pull Supplies, Water, ColonySupplies, Power, etc. out of WOLf via hoppers to meet all of your USI-LS needs. In fact, that introduces another strategy component where you have to decide if you can afford to pull those resources out of WOLF or if it makes more sense to get some small MKS mining/refining operations set up instead.

@goldenpsp beat me to it but yes, WOLF is a completely separate system from MKS and USI-LS. It brings with it a new approach to colonization but it is not intended to be a replacement for MKS or USI-LS. MKS is and will remain very good for building temporary and semi-permanent settlements. It offers a lot of flexibility in terms of being able to adapt to changes in your goals and strategies. It starts to break down though once you try to go big, both from a performance perspective and from a time management perspective. That's where WOLF comes in. If your goal is to have Kerbals permanently settled on every habitable body in the solar system, WOLF will let you do that. If you want to have cities with thousands of Kerbals living in them, WOLF will let you do that too. Good luck trying to do with that with MKS. On the other hand, if the fun of colonization for you is in designing/launching/landing/assembling bases, handling resupply missions, handling crew rotations, figuring out what to do when you accidentally recycle your base's nuclear reactor and mounting rescue missions to retrieve a group of grumpy Kerbals that you left sitting in an orbital station that you forgot about, then WOLF probably doesn't have much to offer you. In other words, if you like micromanagement, MKS + USI-LS is the way to go. If you want to colonize every planet in the Kerbol system, then WOLF is gonna be your jam.

There will be equivalents in WOLF for basically everything that MKS and USI-LS currently do. You'll still need Power but the idea is that you're delivering the equipment and then leaving it in the hands of your Kerbals to figure out how to keep it running. So there's no waste heat to manage, no reactor refueling, etc. No more "I have 3000 radiators on my mining rig...why are the drills still overheating?" issues or reactors blowing up during time warp. No. We don't want to introduce any hard dependencies between MKS and WOLF. That said, we already have plans for WOLF v1.1 that will introduce new mechanics in the same spirit of MKS colonization bonuses. We still want there to be rewards for expanding a colony. We're just trying to get WOLF v1.0 out the door for now though. So more on this particular topic later. Yep. Everything you can make with MKS, you'll be able to make with WOLF and you'll be able to transport most of them within the WOLF network as well. Kerbals are also treated as "resources" in WOLF. Once they join a colony, they are "absorbed" just like equipment is. You receive a number of CrewPoints for each star the Kerbal had when they joined the colony. They all consume the same amount of life support resources though, so there's incentive to get your Kerbals leveled up before they become colonists! I'm really excited about the transport mechanic personally. You won't get it for free like you do with planetary logistics in MKS. In WOLF, you have to make the journey between depots yourself first. The amount of mass lost between point A and point B determines the cost in TransportCredits and the final mass of the vessel determines the payload. You don't automatically get the return trip for free either. You have to refuel and make the journey back to point A yourself if you want two-way transfers. Once the route is established though, you can transport whatever you want over it. So say you end up with a payload of 10 WOLF units, you could send 5 Water, 1 Food, 1 Oxygen and 3 MatKits to the destination over that route. You can change what's being transported at any time too, provided the destination depot is able to "give back" what was originally being transported (i.e. it's not required by other consumers). So say you get Water production setup at the destination depot for a total of 10 Water (5 coming in via transport and 5 from the refinery) and you're using 8 Water. You could cancel 2 Water coming in via transport and start sending 2 units of something else instead (e.g. more MatKits, more Food, a new resource, whatever). Nope, at least they shouldn't be. Detecting when parts go missing can be a bit tricky sometimes, so this is something we will probably need some help testing and troubleshooting once the beta goes out. Oh there will still be plenty of engineering required, it just shifts from "how do I attach my base pieces together and keep it from exploding" to "how can I make the trip from Minmus to Ike with the biggest payload while using the least fuel" and "is it more efficient to deliver equipment to the Mun from Kerbin or build it in situ".

Yes. It's not your system, it's KSP. MKS leans heavily on the stock resource system, so there isn't much we can do to optimize its performance any further. It all comes down to part count in the end. Every light, ladder, docking port, antenna, science experiment, strut, storage container, solar panel, etc. that you add to a base has physics calculations performed on it every frame, for every vessel that's currently in physics range. It's pretty easy for an MKS base to balloon in part count once you add in life support, power, comms, storage, support modules, etc. The reason that MKS brings so many logistics options to the table is to encourage a more distributed approach to colonization where you have small outposts dedicated to a single task and spread far enough apart that they are out of physics range from one another. The Atlas parts should have a pretty dramatic effect in terms of reducing part counts. In addition to having 2 - 3x more bays compared to Tundra parts (and in the case of the 20m dome, something like 8 - 10x the throughput per bay), the domes also perform the functions of the Pioneer and Workshop parts. So you shouldn't need nearly as many support parts to have a fully functioning MKS base. And... then there's W.O.L.F. This is the ultimate solution to the performance issues that colonization tends to introduce. It's a completely new resource system that has little to do with the stock resource system. We still use the stock system to determine resource abundance but that's about it. The way that W.O.L.F. works is easier to show than to try to explain but the basic flow is this: Scan a biome to see what resources are available and in what quantity. Setup a depot in the biome (you'll have the option to spawn a premade, single-part base in the biome if you want something pretty to look at) Bring in equipment to harvest and process the resources (land them with a rocket, truck them in with a rover, build them on site, whatever) The equipment will be "absorbed" into the biome/depot (i.e. it will be despawned from the game) Setup transport routes to transfer resources between depots... even depots on other planets There is no temporal component to the W.O.L.F. resource system, meaning we don't have to run any per-frame calculations to determine how much Ore a drill is bringing in or how much Ore a refinery is using and how much LiquidFuel it's producing. You'll do a resource survey, it will come back saying you have something like 200 Ore available in the biome, you land a drill in the biome that can extract 5 Ore and now you have 5 Ore available in your depot to do whatever with. Then you might bring in a refinery that needs 10 Ore and produces 5 LFO. The depot can only supply you with 5 Ore though currently, so you either need to bring in another drill or ship the other 5 Ore in from another depot. The important thing to understand that 1 W.O.L.F. unit is not the same as 1 stock unit. There is a part (we're calling it a "hopper") that will allow you pull resources out of W.O.L.F. into the stock resource system. That part will operate just like any other converter does currently (i.e. it will output some quantity per second). This is the only time we introduce any kind of temporal component to W.O.L.F. We still haven't ironed out the exact formula we'll use for that conversion but it will probably be something like 1 W.O.L.F. unit = 10 kg/day. That would put a hopper about on par with a single bay in the 20m dome. There will not be a way to input resources from the stock system into W.O.L.F. though. The whole idea behind W.O.L.F. is permanence. Once you have a drill setup in a biome to bring in 5 Ore, that 5 Ore is guaranteed for the rest of the game. Once that 5 Ore has been allocated to consumers, it can't be reallocated. So we don't want to introduce dependencies on incoming resources from parts that may explode, get recycled on accident, moved to another biome, etc. The permanence of W.O.L.F. is what makes it so much simpler than the stock resource system and thus so much more scalable.

A pull request for the Atlas parts has been submitted and the models are done. The converters and their recipes have all been setup. We just need to make a second pass over them to iron out all the other fiddly details like mass, cost, attach nodes, names, descriptions, etc. The converters in the 10m domes worked out to be roughly equivalent to the converters in the Tundra parts in terms of throughput. The big difference is that there are 6 bays instead instead of 2 or 3. The 20m domes also have 6 bays and thus have substantially more throughput per converter. I'm not going to make promises on @RoverDude's behalf but the goal is to put out a beta release for both the Atlas parts and WOLF for KSP 1.7. Could be days, might be weeks, probably not months. It really just comes down to his schedule. Some more notes on the Atlas parts: We added some "shortcut" recipes that will allow to do things like make MatKits directly from MetallicOre, Minerals and Substrate, bypassing the intermediate conversion to Metals, Chemicals and Polymers. For the first time, we will have swappable, multi-bay USI-LS parts. What this means is that you could have a starter dome that's setup to perform all life support functions (i.e. habitation, recycling, med bay, life support extender, etc.). Then later, when you're ready to grow your colony with additional domes, you could have one dome dedicated to each function. A 20m dome with all 6 bays set to Habitation will provide almost 2,000 kerbal months! Side note: This is the reason we had to change the way converters work. We wouldn't have been able to do this previously. The 10m domes will seat 12 kerbals and the 20m domes will seat a whopping 96! Anyone want to make an IVA for the 20m dome...? Anyone? This is all subject to change which is why we're waiting to include it in the beta release we put out for W.O.L.F. We may add bays, remove bays, add recipes, remove recipes, add crew capacity, remove crew capacity... who knows.

I mean... you basically just described modding in KSP. I feel it's worth pointing out that Squad hasn't exactly set a good example with their own documentation for KSP's API. This is their documentation for ModuleResourceHarvester (which USI_Harvester is based on): https://kerbalspaceprogram.com/api/class_module_resource_harvester.html If you scroll down thru there, you'll see that there are a ton of public attributes that can be configured for a harvester but the overwhelming majority of them have absolutely no description for what they actually do. So the only way to figure out what they do is to look at existing stock parts to see what options they have set, play around with different settings to see what effects they have and ask questions in the forums to see if any other modders have experience with the thing you're trying to do. To make matters worse, many options seem to have absolutely zero effect and there may be half a dozen options that all sound the same but only one of them actually does the thing you think it should. And this is something we paid for. Modders don't get paid. So I can't really fault them for not providing documentation when Squad can't even provide adequate documentation! I feel your pain. I was really frustrated when I first got into KSP modding. Things aren't well documented, a lot of information is tucked away deep inside monster forum threads that take hours to sift through and there's conflicting information at times. I agree that it would be great if there was a "modder's guide" wiki page for each of the USI mods that explained each PartModule and its config options. It would have been a huge help for me when I was first trying to wrap my head around the USI collection. It takes time a lot of time and effort to make that kind of high quality documentation though. The great thing about wikis is that anyone can update them. So if you'd like to start a new wiki page for this, I'd be happy to help fill in blanks. Here's the first challenge... the majority of the stuff you're looking at actually lives in USITools. In fact, most stuff lives in USITools. So that's really where this kind of documentation should go, which would be here: https://github.com/UmbraSpaceIndustries/UmbraSpaceIndustries/wiki MKS and USI-LS do have some PartModules of their own, so they would need their own modder's guide wiki pages as well, probably with lots of links back to the USITools modder's guide for all the things folks think are part of MKS or USI-LS but are actually part of USITools.

@PotatoAndBeanHarvester and others interested in the "perform maintenance" bug. The part module involved in this feature is USI_ModuleFieldRepair, as you correctly discovered. This module is supposed to be added to parts via a ModuleManager patch though so that it does not need to be manually added to the part config for each part. So it's possible that changes in ModuleManager broke the patch. I am nearly useless when it comes to MM unfortunately (read: I'm too lazy to learn the syntax and keep up with its development). The related MM code is: @PART[*]:HAS[!MODULE[USI_ModuleFieldRepair],RESOURCE[Machinery|EnrichedUranium|DepletedFuel|Recyclables]]:FOR[USITools] { MODULE { name = USI_ModuleFieldRepair } } If some MM guru spots any issues with that and can provide me with a fix, I'll be happy to update the code and submit a PR.

I've made quite a few posts about this in this thread (probably easier to just look at my posts via my profile rather than trying to find them in this monster thread). All of the MKS parts have been updated to use the new modules and I also submitted a pull request to Kerbal Planetary Base Systems to partially update its USI compatibility. (That link is to the diff for the PR which will show you what I changed in KBPS compared to what was there before). So these are places one could look for examples of how to update a part to use the new modules. If you can be more specific about what information you feel needs to be provided to complete the picture, that would help me help you.

This was fixed in PR 273 which has been merged but there has not been a new release yet that includes the fix.

RoverDude talked about it briefly in his last Twitch stream. We're working on a new system for larger scale colonization than what can currently be achieved with MKS. The new system won't rely on the stock resource system like MKS does and thus won't incur all of the CPU overhead that comes with it. This system will allow us to do some pretty awesome stuff like setting up continuous resource transfers between planets and having colonies with hundreds or thousands of Kerbals in them. We plan to add some new (huge) parts as well that will be unlike anything I've seen in KSP yet (I mean... someone else may have already done something similar, but if so, I haven't seen it ). We don't see this system as a replacement for MKS or USI-LS but we do expect it will change the way that many players choose to use MKS and USI-LS. For instance, I could see someone using MKS + GC in order to setup a factory for producing the parts you'll be using in the new system. There will be a way to pull resources out of the new system as well, so there's a really nice synergy there with something like a GC parts factory or even a GC shipyard that builds the ships you use to setup interplanetary resource transfers in the new system. So yeah, entirely new addition to the USI family and not intended to be a replacement for MKS or USI-LS. They're all designed to play nice together and compliment one another while still being able to stand on their own. The coding for the first iteration of the new system is done. We just have some odds and ends to clean up and then get the parts finalized. We're probably going to be using re-skinned Tundra parts for a lot of it but like I said, there will be some new parts as well. (If you caught RoverDude's last Twitch stream, he made one of the new parts in that stream.)

The models are done or nearly so afaik. I think they're primarily just waiting on part configs at this point. RoverDude has been super busy with his Squad responsibilities lately, so we haven't chatted about this recently unfortunately.

We'll likely start a new thread for this (if that gives you any hint as to how big the "big changes" are ). There aren't really any plans to make significant changes to MKS or USI-LS at the moment.

If you want a converter to have swappable recipes or if you want a converter to have side effects (e.g. reduced Supplies consumption, slower Habitation timers, etc.), then yeah, you need USI_SwapController, USI_SwappableBay, a USI_Converter and one or more SwapOptions. If your converter only needs one recipe and doesn't need to interact with any of the other systems in USI, then just use a stock ModuleResourceConverter or ModuleResourceHarvester instead. There is no need to create a dependency on USITools by setting up a part using a USI_Converter if all it's doing is converting Hydrogen and Oxygen into ElectricCharge and Water, for example. Take a look at the config for the Tundra Refinery for a good example of how a multi-bay part is setup. Habitation parts, recycler parts, efficiency parts, etc. are kinda funky because they consume resources (e.g. Water, ElectricCharge, ColonySupplies, etc.) like a normal converter does, they just don't output any resources like a normal converter does. Their 'output' is instead some kind of side effect in their respective systems. So we still implement these parts using a converter in order to consume the resources but we use a ConverterAddon (hidden away inside of a ConverterSwapOption) to create the side effect. So yeah, if you want to make a Habitation part, you have to use the full blown USI converter system with a USI_SwapController, a USI_SwappableBay, a USI_Converter and at least one USILS_HabitationSwapOption. Kinda seems like overkill, I know, but it's the most flexible way for us to deal with these kinds of quasi-converters in a way that makes them interchangeable (i.e. so that we have a single part that can be either a Hab part or a recycler). This depends on your part really. Is it some kind of all-in-one part that provides both Habitation and some kind of recycler at the same time? If so, then yes you'll need 2 bays and 2 converters. There currently aren't any parts in the USI catalog that do both things at the same time but you can take a look at the USI-LS config for the central hub part in the KPBS mod for an example of how to do that here. Note the currentLoadout and hasPermanentLoadout settings that have been added to the bay modules. The USI hab/recycler parts are all setup with a single bay that can be configured as either a recycler or a hab part but not both. Check out either of the Tundra Kerbitat parts in MKS for an example of that. (Personally, I think all-in-one parts are a bit OP unless they are just massive parts, like say a 10m or 20m dome, if there were such a thing. )

USI_SwapController Stock resource converters (ModuleResourceConverter and ModuleResourceHarvester) only support a single recipe that is hardcoded into the converter via the part config. USI_SwapController is part of a system that allows converters to have multiple recipes that can be swapped via the editor or in flight. Now one might say, "But wait a minute... the stock Convert-o-Trons have multiple recipes" and they would be right. But that is accomplished by having multiple converters configured on the part each with its own recipe. The USI recipe swapping system allows a single converter to support multiple recipes. There is no free lunch though and USI_SwapController imposes a cost (typically things like MaterialKits, SpecializedParts, ElectricCharge, etc.) to change recipes in flight. (BTW, when I say in flight I'm talking about what KSP considers to be the flight scene. Even if a vessel is landed on the surface and your Kerbals are out walking around, the scene is still the flight scene.) Swap costs should typically be configured on each part that uses the USI recipe swapping system since the player can now disable swap costs via the game settings if they don't like that particular mechanic. USI_SwappableBay Larger parts (like the Tundra parts) typically have multiple converters in them. In order to keep track of which converter is running which recipe, we assign each converter to a bay. When you change recipes, you're actually changing the recipe for the bay and it handles updating the recipe on the converter behind the scenes. For each bay, there also needs to be a converter setup on the part. The converters are discovered in the order they appear in the config file and the bays need to be assigned a moduleIndex that corresponds to the converter they are responsible for (starting at 0). Something that may not be intuitive about this is that even if a part is only meant to have one converter, you still need to setup a bay for it to live in if you want it to have swappable recipes or produce any side effects, which I'll explain later. USI_Converter | USI_Harvester These PartModules extend the stock ModuleResourceConverter and ModuleResourceHarvester PartModules. They mostly behave in exactly the same way as their stock counterparts except that they can inject additional logic in the recipe preparation and post-processing steps of the conversion process. This is what allows us to have converters that consume resources and output things like 'Reduced supplies consumption' instead of some kind of tangible resource. I refer to these behaviors as side effects. USI_ConverterSwapOption In the part config, these look a lot like the config for a converter and the reason for that is because this is how you setup each recipe that is allowed to be swapped. You'll need one for each recipe. If the recipe is just a simple conversion, then the base USI_ConverterSwapOption should be sufficient. There are some custom ConverterSwapOptions though, primarily in USI-LS. The reason you would have a custom swap option is for recipes that produce side effects. Note: There is currently not a way to restrict certain swap options to a particular bay. If you find yourself wishing this was possible, then you are probably trying to make your part do too many things. ConverterAddon Addons create side effects. These are not PartModules though and will not show up in the part config. They are hidden away, typically inside of a custom ConverterSwapOption. An example of this would be the USILS_LifeSupportRecyclerSwapOption. It applies a USILS_LifeSupportRecyclerConverterAddon to the converter that produces the reduced Supplies consumption side effect in USI-LS.

I have a document currently on my desktop titled 'MKS Part Config Discrepancy Notes'. So yeah, there are some discrepancies. I suspect that it's just due to the fact that the USI suite has been around for a quite a while now and has had many additions and changes along the way. There are a lot of parts spread across the various mods in the USI collection and keeping them all in sync with each other in terms of balance and design intent isn't easy. So if something seems like a discrepancy to you, you probably aren't crazy. This is my unofficial guide for how to add USI compatibility to another mod: MKS and USI-LS are meant to be complimentary but work independently from one another. To reiterate what @voicey99 already pointed out: Machinery consumption and Kolonization bonuses are MKS concepts, ColonySupplies, Habitation and Supplies are USI-LS concepts. So if you want a part to do both MKS things and USI-LS things, you should make separate Module Manager patches for them.1 Machinery is meant to simulate wear and tear on equipment. I think of Kolonization bonuses as simulating the idea that as a colony grows, your colonists become more specialized in their jobs and thus better at them vs. a small colony where everyone is a jack of all trades. Habitation is meant to simulate the effects of being cooped up in a small space for too long and also being away from home and friends for too long. Supplies are the consumables that a Kerbal needs to stay alive. ColonySupplies are the consumables that a Kerbal needs to distract them from being in cramped quarters and away from home. I would suggest using the Tundra parts in MKS as the 'gold standard' in terms of how a part is supposed to be configured. There is a spreadsheet floating around somewhere that is setup to be a balance calculator for USI-compatible parts (sorry I don't know the link off the top of my head... it might be linked in the wiki or on the forums somewhere though). If you run across a part in SSPXR that doesn't really have an analog in any of the USI mods and you aren't sure how it should be setup, just ask. It will be easier for us to offer guidance on a part-by-part basis than to try to write up a comprehensive design and balance guide for everything USI. --- 1. If we want to really get into the weeds, the consumption of Machinery and ColonySupplies are not due to any kind of built-in mechanism in either MKS or USI-LS. They are simply recipe ingredients for a converter just like Ore is an ingredient in the LFO recipe. These resources are part of the Community Resource Pack and any mod is free to use these resources in any way that it wants. So we follow a convention in MKS to add Machinery to any recipe that will be processed by a converter that we want to simulate wear and tear on. The wear and tear effect (decreased efficiency) is applied by the converter itself. Likewise with ColonySupplies, the convention in USI-LS is to use ColonySupplies as a recipe ingredient for converters that will affect Habitation timers. The Hab timer effect is applied by the converter in this case as well. Consequently, these converter side effects are the reason that most USI parts use the USI_Converter PartModule instead of the stock ModuleResourceConverter.

USI_Converter is the replacement for ModuleResourceConverter_USI. USI_SwapController, USI_SwappableBay and USI_ConverterSwapOption are only required on parts that need the ability to swap between multiple recipes. That said, if all you're doing is adding a generator, there is no need to make the part dependent on USITools. Just use the stock ModuleResourceConverter that's built into KSP.

@strigon If Sidny is a Scout, then he's immune to habitation effects. https://github.com/UmbraSpaceIndustries/MKS/wiki/Crew-Skills-Impact-on-Parts#scout

@RookFett The issue with orbital logistics transfers failing should be fixed with the PR I just submitted to MKS. This was caused by launching multiple vessels using the same .craft file. I feel like this wasn't an issue before so maybe something changed with the way vessels are spawned into the game in KSP 1.6...? Note that any of your existing vessels (both launched and saved in the SPH/VAB) will still have this issue unfortunately. To fix a saved vessel, just remove the OrbLog part from the ship, replace it with a new one and then re-save the vessel. Fixing vessels already in flight will be a bit trickier since you'll have to edit your game save file. Search for ModuleOrbitalLogistics and remove the value for ModuleId. The next time you initiate a transfer to or from that vessel then, it will generate a new, unique ModuleId for itself. Note though that this only affects vessels based on the same .craft file. So it may be a non-issue if most of your existing vessels are one-off designs (like mine usually tend to be no matter how hard I try to reuse my ship designs ). Side note: I also added a failure reason that shows up in the Review Transfer UI now for transfers listed as Failed or Partial.

I submitted a PR to KPBS back in November with the necessary changes to fix USI-LS compatibility for the parts I use in my own saves (I don't use the small modular container parts, so I didn't include fixes for those parts in my PR). I believe @Nils277 has been waiting for an official USI-LS release to merge those changes, so I imagine that will happen soon™ now that we have an official release.

@RookFett I found the problem and submitted a fix. I noted it on your GitHub issue as well.

I downloaded your save files from GitHub and was not able to reproduce the issue. I removed the microwave transceivers from the Kerbitats and they still showed 3 PDUs in range in the PAW. I launched new vessels on the runway with empty batteries and kontainers and they immediately started scavenged from the other vessels. So this sounds like an issue with your install. Might be another mod that's interfering.

The PDUs require a Kerbal with the ConverterSkill (so either an Engineer or Technician) in order to distribute power. Same goes for the Power Coupler. The Microwave Power Transceiver does not have this limitation.

What you've discovered is that we are really pushing the limits of what we're able to do by building on top of the stock resource system. It really isn't meant to do what we do with it.