DoktorKrogg

Members
  • Content Count

    47
  • Joined

  • Last visited

Community Reputation

63 Excellent

2 Followers

About DoktorKrogg

  • Rank
    Rocketeer

Recent Profile Visitors

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

  1. DoktorKrogg

    [1.3] - Modular Kolonization System (MKS)

    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.)
  2. DoktorKrogg

    [1.3] - Modular Kolonization System (MKS)

    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.
  3. DoktorKrogg

    [1.3] - Modular Kolonization System (MKS)

    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.
  4. DoktorKrogg

    [1.3] - Modular Kolonization System (MKS)

    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. )
  5. DoktorKrogg

    [1.3] - Modular Kolonization System (MKS)

    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.
  6. DoktorKrogg

    [1.3] - Modular Kolonization System (MKS)

    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.
  7. DoktorKrogg

    [1.3] - Modular Kolonization System (MKS)

    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.
  8. DoktorKrogg

    [1.3] USI Life Support [0.5.0]

    @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
  9. DoktorKrogg

    [1.3] - Modular Kolonization System (MKS)

    @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.
  10. DoktorKrogg

    [1.3] USI Life Support [0.5.0]

    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.
  11. DoktorKrogg

    [1.3] - Modular Kolonization System (MKS)

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

    [1.3] - Modular Kolonization System (MKS)

    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.
  13. DoktorKrogg

    [1.3] - Modular Kolonization System (MKS)

    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.
  14. DoktorKrogg

    [1.3] USI Life Support [0.5.0]

    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.
  15. DoktorKrogg

    [1.3] - Modular Kolonization System (MKS)

    This is mostly for @Wyzard but to others following along as well: The converter changes made in the latest version of USITools (and thus all mods in the USI suite that rely on USITools, i.e. MKS, USI-LS, etc.) were necessary because the previous implementation of swappable converters could not support running the same recipe in multiple bays simultaneously on a part that has multiple bays. You could set all the bays to the same recipe but you would only get the output of a single converter. This ended up being a result of the way the system was designed, not a bug. So the only way to fix it was to overhaul the entire system. Unfortunately, the new system just isn't compatible with the old way of doing things. We could have left the old code in to ease the transition but what would have likely happened is that other mods would have never gotten around to updating their parts to use the new system and then a year from now, when we finally decided to remove the legacy code, a bunch of mods would have broken and no one would remember why. Better to tear that bandaid off now in my opinion. Breaking changes are as much a headache for us as they are for everyone else. We try to avoid them if we can. I play KSP with mods that integrate with USI-LS as well and will be impatiently waiting on them to update (or writing the PRs myself if I get too impatient ). In the meantime, I'll be enjoying Assembly Plants that can make Machinery in all 3 bays at the same time. The good news is that updating part configs is pretty easy and I'm sure the other modders would happily accept pull requests. I'll be glad to help anyone who wants to take a stab at helping the other modders get their mods updated to work with the new converter system.