-
Notifications
You must be signed in to change notification settings - Fork 154
Mod Support
Status as of MKS v1.1.0.0
MKS contains many systems within in, some of which depend on other mods, or change based on which mods are installed. This site lists all dependencies and connections.
While MKS should be compatible with most other addons, there are a few exceptions.
Quoting RoverDude: "I make it a point not to be actively incompatible with anything"
MKS uses resources as defined in the CRP, and so is required and bundled with MKS.
The contents of MKS containers can be switched via FS, and will not work without.
This is the thing that makes most mods possible, and allows you to dynamically modify parts upon loading.
Umbra Space Industries Catalog
All other USI mods are explicitly supported and encouraged as they extend the MKS design space considerably and are built from the ground up to work with each other. Specifically:
- USI-LS is heavily used by MKS players for their life support, and MKS parts are designed with USI-LS in mind
- Karibou and Malemute rovers provide Resource Distribution Logistics
- Karbonite and Karbonite+ have supported Kontainer options
- Asteroid Recycling Technologies provide tools for asteroidal bases
- All USI parts have a unified design philosophy and aesthetic
MKS provides CLS-configs for its parts, so Kerbals can move about according to those rules.
MKS has replaced its use of Extraplanetary Launchpads with Ground Construction, and some parts directly support GC operations.
All the parts in the USI catalog have .cfg's for placement in advanced nodes on the CTT. Community Tech Tree expands the stock tech tree to provide more of a challenge in career games, making it take thousands more science points to "max out". This mod is recommended for more dedicated players as it'll put a lot of the parts a little further out of reach in the early stages of a new career.
Kerbal Attachment System (KAS), Kerbal Inventory System (KIS), & OSE Workshop
These are three mods that build off of each other in order. All MKS parts are encouraged to be used with KAS to assemble a base on-site, and you can't use Kerbitrail FlexOTube without it. KIS allows you to pack those parts into shipping Kontainers provided with MKS, and even move MKS modules around! Finally, OSE Workshop allows you to build parts on-site with MKS workshops and resource chains. All three are highly recommended for a full base-building experience!
Revamping the resource scanning mechanic, SCANsat allows you to get detailed maps of MKS resources and using MKS parts in a way more realistic than stock KSP.
Near Future Electrical (NFE)
Adding large batteries in underused form factors, nuclear reactors to fuel your Kolonies, and capacitors for those high-density storage needs, NFE has its own config bundled with MKS to allow compatibility.
SXT comes with a patch that converts several of its parts into additional habitation-capable modules to provide large, heavy-duty alternatives to kerbitats and stock parts for keeping kerbals on extended missions.
A way to use IVA for more data, RPM is compatible, but may cause lag with the Karibou Rover. Additionally, not all parts have properly working IVA's, so won't work with RPM.
MKS formerly had parts contained within it, in its own style, which provide EPL functionality. These parts required EPL be installed to function in this way. However, all EPL parts other than the survey stake and mallet are nonessential to MKS, and can be deleted if the player does not wish to use them. There is a separate group maintaining compatability between EL and MKS
"This mod introduces robotics parts to the game, letting you create moving or spinning contraptions that just aren't possible under stock KSP." This can make off-world Kolony building easier, not to mention opening up design space previously not possible, like walking Kolonies.
Not supported anymore with EZ-Snack Oven, but it is compatible with MKS.
If installed, you can produce Snacks by converting Ore into Snacks.
MKS comes with a MM-config file that adjusts all converters to the TAC-LS cycle.
However you will need to bring your own storage containers.
In order to store TAC-LS resources in MKS modules, you have to change them with MM-configs.
Created by forum user Paul23 The patch is still quite barebones: many USI parts become quite useless together with TAC (kerbitat etc). I have chosen to not do a 1-on-1 conversion of supplies -> (food/water/oxygen) with the agroponics. Rather the agroponics provides food and a small amount of oxygen. Actually the food/(co2 -> o2) distribution depends on the way you create the food (cultivate etc). I've done this to keep a bit in the spirit of both USI and TAC: different resources and a tree to produce those.
I've also updated all containers, the non liquid containers contain food & waste. The liquid containers contain water/wastewater/oxygen/carbondioxide. To keep the same number of days/container for resources I had to "nerf" the amount of water by a huge amount. (Otherwise MKS would outshine any of the TAC water containers by a magnitude of 100) - however i might change this back if it interferes too much with USI itself.
Please contact forum user Paul23 with any feedback or issues.
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.
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.
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.
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. 😉
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.
Q. USI_SwapController and USI_SwappableBay are necessary, even if there is only one converter module. The swap options call on USI_Converter or USI_Harvester, and therefore USI_Converter or USI_Harvester are necessary with a swap option. Is that correct?
A. 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.
Q. And If I'd like to have more than one bay, how does that work?
A. Take a look at the config for the Tundra Refinery for a good example of how a multi-bay part is setup.
Q. if I DON'T want to use a converter, but just change the part's BaseKerbalMonths and/or BaseHabMultiplier? Do I still configure that in USILS_HabitationSwapOption and do I still need USI_SwappableBay and USI_Converter for that?
A. 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).
Q. what if I want a recycler as well - do I then need 2 bays?
A. 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. ^_^)