Terwin

Do you have USI-LS installed? Habitation is a Life Support function, so without USI-LS you will not be able to access any of the life support modes of multi-mode parts.

Especially in the early game, landing on engines is common due to part-count limitations(if a controlled landing is done at all). *some* engines were offset, but not necessarily enough to overcome the ability to auto-correct if you have SAS turned on. I thought it was just the largest fairing that was the wrong size, something I may not have ever actually used. Truth be told, some of my earliest career games could have been played past the end of the tech tree before I even noticed these bugs(if I ever did). Personally, if I can play the 'entire game' without noticing a given bug, I consider it to be a reasonably easy to miss bug, and do not consider it unreasonable for it to have been missed by QA.

The first orbital class rocket first stage to even *have* landing legs was the Falcon 9.(and they were considered a joke by pretty much every non-SpaceX rocket scientist when they first appeared) The Falcon 9 does not start sitting on it's landing lets, it only uses them for landing. Aside form the Falcon 9, the only landing struts were on the Apollo landers. As such, the entire history of space flight could be simulated as part of the test cycle and never use landing legs if they: a) Skip or land on the engines for the Apollo landers(I often land on the engines for Munar landings, so not a stretch in my mind) b) Skip, do not bother to land, or already land hard enough to explode shuttle landing wheels c) Stop before, Skip, or do not bother to land Falcon 9 boosters. As of yet, no real-world orbital class rocket sits on its own landing legs prior to take-off, and I rather suspect that the landing legs of everything ever launched would have major problems supporting the fully loaded weight of the entire rocket in 1g. As such, I find it entirely realistic that something that has never happened in real-life(and would cause catastrophic failures were it ever tried), would not be part of the limited pre-release testing done for a rocket simulation game. But that is just me.

RoverDude added piecemeal inflation, so if you attempted to inflate and only had part of what you needed, it will consume what is available, and reduce the total needed by that amount. This works great with Planetary logistics and can also help when you just do not have a large enough MK storage container for the full inflation cost. Try checking what is still needed, it should be less than the original total.

We have Kerbol, 7 planets, 9 moons, and an unlimited number of asteroids and destroids, where each and every non-asteroid body is different from any of the others, many(all?) of them containing one or more Easter eggs. Also, Squad has apparently added 'wandering' green monolith(s) that appear in different locations for each game, giving yet another Easter egg that is always fresh for each game. That is actually quite a large area to explore and play with. Furthermore, Squad has mentioned that only a small percentage of players(10%? 5%? 1%?) ever actually get outside the Kerbin SOI. That is quite a lot of exclusive content for a small number of players and I would be surprised if SQUAD were to add anything else outside the Kerbin SOI. On the other hand, there are all sorts of planet and solar system mods/packs that you could consider if you are one of those few who have explored every part of every planet multiple times and want to find somewhere new to explore. It seems to me that Mods are probably the correct avenue to explore for concerns that only affect a fraction of a percent of the players.(sure lots of us would appreciate having new places to explore, but the number of players who have been everywhere and done everything and now have difficulty enjoying the game because there is nowhere new to go, seems like a very small portion of the player base, even if that turns out to be because such players wander off to different games).

For any given vessel(including a connected base) it will only ever be in a single biome. Wherever your center of mass is located is the biome for your entire vessel. This is part of KSP and not something specific to the mod, so not much chance of it changing. MKS supports disconnected bases, so that is one possible option, another option, is using the planetary warehouse. This works by putting 'harvester' with a MPU or other logistic enable part and logistics enabled storage in a biome with resources you need(and a the drills to harvest it), and every time your storage gets above 50%, half of the resource in that container get moved to the 'planetary warehouse'. You can withdraw from the planetary warehouse by having a Logistics module and a pilot on the same vessel as the logistics enabled storage you intend to fill from the PW. Any time the storage container gets low, it should pull in from the planetary warehouse if any of that resource is available. No crew is needed on the harvester, so those are usually a good opportunity to use the automated drills. Just remember to jump to that vessel every now and again so that catch-up processing can add the harvested resources to the planetary warehouse. Note: catch-up is done if 6 hour chunks, so if you have less than 12 hours of storage, you will not get as much of that material from catch-up as you would from watching it in time-warp.

You need a logistics enable module on your vessel to access the planetary warehouse. Logistics modules provide both push and pull(with pilot) capability MPUs also provide logistics(Push only) capability. The only pioneer module that provides logistics is the tundra 2.5m pioneer/logistics module.

Do you have USI-LS installed? I think that habitation, as a life support related function, may be part of USI-LS. That is usually the reason that habitats can do nothing other than whatever efficiency-boost mode they may have. For MKS reactors, you should have a 'Perform Maintenance' action that will top off both nuclear fuel and machinery as applicable. For NF reactors, you may need a module manager patch to allow this action. (I also find NF reactors to be much hotter, hungrier and more fragile than MKS reactors, so I remove the NF MKS reactor patch and stick with MKS reactors myself) Also, a nuclear fuel refinery will automatically deposit any refined fuel in any attached storage(including a reactor), so explicit refueling may not be needed if you have a refinery on your base.(not 100% sure as I always have a manned workshop by the time I am producing nuclear fuel, and a workshop with an engineer in it will automatically perform maintenance every day)

Have you ever had a real Heisen-bug? one that changes when you turn on logging? My first one was in school when we were writing a OS as a team project. No one realized the memory location we were writing our log messages to was actually over-writing part of the code... Sure but manufacturing processes always run on exactly the same environment(aka the real world where Iron is always harder and heavier than aluminum, but aluminum cools faster because it is a better conductor), for software that can only happen when you provide the hardware as well(and keep it in a locked box that the users are not allowed to tinker with). How well would those 'consistent' manufacturing processes work if you had to ship the same manufacturing line to all factories, even though in some of those factories Aluminum is heavier than lead and harder than diamonds, but high-carbon steel has the consistency of tapioca pudding? Could you still guarantee that all of those product lines would ship the same, high-quality products? Tell me, how many CNC systems have you seen that sell for less than $100 and will run on any custom computer you build for it, with no requirements more stringent than 'CPU at least as powerful as computers made at the start of this decade'? Industrial tools will often have embedded computers of one sort or another, but he creator of those tools will also specify the exact specifications of those computers, including every program that should be run on them when working. I am sure that if SQUAD could specify the entirety of your computer(including operating system version, CPU, bios version, Graphics card, ram, all input devices, power supply, all installed software, including driv3er versions, and even the brand and version of the memory cards used) they could perform deeper tests with the specified hardware and prevent such 'obvious' bugs, but they do not have that much control, so they test what they can based on the reported system specifications of their installed base, needing to make a much broader set of tests on lots of different hardware configurations. Also, a $40 game does not necessarily have the testing resources of a $10K-$100K piece of CNC equipment, so the total amount of testing being spread over many more system configurations is probably also much smaller, leaving you with relatively shallow testing for many configurations, and probably none at all for anything uncommon. And don't pretend that the latest thousand dollar GeForce card using a beta release of the next version of the latest driver will behave exactly the same as integrated graphics on a dell economy box from 2005 which has never had its drivers updated. Sure the game may always run exactly the same on the same hardware with the same software running in the background(Deterministic), but I can guarantee that we are not running identical systems and code that works perfectly for me, may well fail to finish the start-up process on your machine(not so deterministic).

Kerbalism replaces the RoverDude designed stock background processing system(no processing when outside of the 2km simulation range, and then catch-up in 6 hour batches when back under simulation) with a flavor of continuous simulation of all vessels in game(presumably with lots of short-cuts to improve performance). It is well known that Kerbalism does not fully simulate all vessels outside of the current focus, and this breaks many parts of the MKS harvesting and manufacturing processes which depend on either active simulation or the stock background process.

The MKS install includes a version of GC, but I do not think that it includes the updated version that Allista has packaged for 1.4. Is it possible that you allowed MKS to over-write your GC install?

That is why 106 is the expected value, but Allista was saying, 64.4+64.4=128.8 which is larger than the expected value of 106.

@-MadMan- the version of your USI-LS install would be helpful. It is also polite to other members of the forums to put sizable chunks of copied text into spoiler tags.

I think I see your problem: Kit cost is the cost in funds for the DIY kit in the VAB. 700K fund for the kit vs 800K funds for the entire base. Kit Res is the number of material kits (64.4K in your image) It looks like Kit weight and required mass of material kits are both about 70% of the dry mass of the vessel in your example. Not terribly unreasonable as one would expect some waste in packaging and assembly in a hostile environment, especially if you are including some resources in the DIYKit.

I'm not sure about the 8:1 ratio you mentioned, but the biggest advantage of GC is allowing the use of locally sourced materials for building parts/bases. And if you use KIS/KAS you can ship several smaller kits, with the first barely able to produce material kits and provide short-term habitation while you build more kits with parts that can provide more capability and longer habitation. (or you could add OSE Workshop and use GC to build the initial 'starter' base and use OSE to add parts one at a time as wanted/needed) While I believe that there is a plan to allow on-site construction of DIY kits eventually, I find that OSE Workshop is a good stand-in until that is available.

I use a combination of Ground Construction(for the initial base) and OSE Workshop(to build modules that expand that initial base). After finding a good base location(and deploying any automated miners needed to cover missing resources), I land 3 ships: DIY container, Material Kit container, Construction ship(the only one with crew/habitation) The starter base in the DIY kit can make material kits and only needs a nuclear refinery, a dditional nuclear power(I usually launch with a 10% fueled 1.25m plant in the kit), and a second industrial refinery to be able to make specialized parts and machinery. After that is is just a balancing act as power, production, and habitation are increased.(I usually drop off at least a dozen Kolonists once there is habitation to support them, using their shuttle as the emergency escape vehicle for the entire station crew as all three of the original ships get dismantled or integrated as part of building the base) Note: you need the largest KIS container(5m?) to be able to make 3.75m MKS parts. The first posting in this thread has a link to the github repository where Roverdude deploys his releases. You can get any released version of USITools, MKS, or any other USI product from there.

Have you installed USI-LS? USI-LS and USI-MKS are thoroughly integrated, but they are still distinct mods and unless you install the entire USI collection(I forget the name for this), you will need to install both MKS and LS if you want MKS bases to have life support and habitation functionalities.

USI-LS needs a way to make fertilizer if MKS is not installed and the 1.25m ISRU is not really useful for ISRU at bases sizes where you have habitation, so it makes a reasonable 'add this for this one function' piece. The rate is also pretty awful(both raw speed and fertilizer per unit of ore), so it is not unbalanced to leave it as-is. (A convert-o-tron 125 weighs 1.25 tons while a crush-o-matic weighs 0.08 tons and has an output that is not less than 1/15 of the small ISRU but does take a lot less raw resources)

While I imagine it must be even worse with the control limitations of a console, asparagus staging on a PC has the same headache, and if you don't go back and double-check each stage, it is easy to make a mistake that will doom your launch. The fairly new fuel flow priority functionality does give an alternative approach to asparagus staging, but even then, if you do not double-check the staging of your decouplers it is easy to doom your launch, and you no longer have engine cut-outs to alert you to the need for staging.

@Darinth it is important to remember that the life support panel is not live data, it is only an estimate based on the storage at the time of your last visit and the life support demands of any kerbals on board. If you have energy generation on your vessel, and EC is not draining when it is inside simulation range, then you should be pretty safe to ignore the EC part of the panel. The actual calculations will not take place until the base undergoes catch-up processing the next time you visit it(just like the stock ISRU does). The supplies and habitation numbers are generally of much more concern, but so long as you are producing fertilizer on-site and your supplies stay full when inside the simulation range, you can probably ignore the supplies portion as well. The only times it is safe to ignore the habitation numbers are A) when you have both enough active colonization modules to cover your occupancy count and a surplus production of colony supplies over and above the consumption of your colonization modules and B) when you have sufficient hab time for 'indefinite' habitation on all kerbals(50+ years or 1+ years for pilots and when habitation is 500%+).

Just be careful when updating to newer versions, as you do not want random files from previous versions causing odd behavior.

If you build your base in a vehicle editor(VAB/SPH) and start adding kerbals the life support calculations should indicate the habitation duration for the current kerbal count, so just keep adding kerbals until it gets under 50 years. While Nom-o-matics have a steady production rate, all other parts that produce supplies are affected by both colonization bonuses and the highest level scientist(or equivalent) on board, so not only is it highly situationally dependent, but it will also increase over time. Kerbal demand is also highly dependent on your base, as a purifier can help extend your resources a long way if you have enough general recycling capability to make full use of it. Also, if you are producing the fertilizer locally, your fertilizer production will also increase over time due to similar factors(although the small ISRU is not affected by the kolonization bonuses if that is what you are using). So, no accurate prediction is infeasible, although you could calculate the minimum production using the Wiki.

That sounds like your USI folder is being cleared when you install life support instead of just having new folders added to it. I would suggest reinstalling and make sure you select merge, and if that is not an option, you may need to copy the contents of each of the USI sub-directories manually so that your OS does not step on the old stuff when adding new stuff.

CKAN is waiting for Allista to update Ground Construction before marking MKS and other mods that rely on GC as being available. There may be other dependencies as well. Until all required modules are marked as available, I just install manually.

As I primarily get my kerbonauts from rescues(where I have specialists disabled), I only use the Kolonist specialist, and that is because they improve all 3 bonuses while only taking one kerbonaut worth of supplies and habitation. Also, by the time I am hitting Duna, I generally no longer need to worry about funds, so hiring non-kolonist specialists is no longer a concern.