Merkov

That's what I mean, though. If you uninstall everything that you currently have through CKAN (or manually, I guess. I'm not sure if that would make a difference) then download the USI constellation (plus any of the fixes that have been posted in this thread) you should be able to just drop the USITools and UmbraSpaceIndustries folders into your GameData folder (along with any dependencies, but I suspect that you may have other mods installed through CKAN that already use the other dependencies, i.e. ModuleManager, CRP, CCK, etc.) without any issues. That way, you'll have a manually installed USI suite, while everything else is managed by CKAN. If you can't uninstall Karibou due to it not being listed on CKAN, then you should be able to safely delete that folder once you have uninstalled the rest of the USI suite, giving you a blank slate for the manual install of the USI suite. On second thought, I'm going to ping @politas to get his input here, just to make sure I'm not completely out to lunch.

Maybe a silly question, but rather than wipe out all of your mods, would simply uninstalling all of your USI mods through CKAN and installing them manually be a reasonable thing to do? Semi-related question: which USI mods are you using? Just MKS, or others?

I feel really odd following this thread. On the one hand, I am eagerly looking forward to seeing these threads revived. On the other hand, while some people are talking about the intricacies of restoring parts of databases from backups, I'm firmly in the "can turn on his computer 9 times out of 10 without something going wrong" camp. If the forums were in hospital, the IT guys would be doctors and nurses, and I would be a kid with a "get well soon" card. Thanks for all of the work being done to restore these threads, I'm cheering for you guys! (It's the least/most I can do )

As far as I know, that's a stock bug that is made more visible by having planet packs installed. From what I've read around here, it requires a stock fix on the Squad side.

This is a stock issue, really. KSP picks any part with crew capacity. This mod provides a fix: Edit: ninja'd!

For MKS users, is the plan then that when Ground Construction is installed along with MKS, the option to manufacture MaterialKits out of Ore will be disabled? (Or, perhaps this is something that RoverDude will handle on the MKS side?) Since MKS requires a somewhat involved resource chain to build MaterialKits, I can imagine that having a straight Ore -> MaterialKit "shortcut" would somewhat defeat the spirit of MKS.

"So guys, I'm working on a new release that might show up sometime this weekend" *Releases patch an hour later* RoverDude, you are awesome.

At last, my dream of reasonably supporting colonies around the Sarnus system will become possible.

I'm not sure if I'm understanding exactly what you are asking, but if you mean a part that let's you convert TAC-LS resources to USI-LS resources in the same save, then you are going to run into issues with the fact that you have two life support mods installed. Last time I checked, having both installed at once meant that you needed both sets of resources to keep your kerbals healthy. That is, if you run out of USI OR TAC resources, you lose kerbals.

I will confirm this. USI-LS has a config file that modifies a few stock parts. One of these modifications allows the small 1.25 m ISRU to create fertilizer from Ore. Note that this is a really slow, inefficient process, but if you have enough recyclers, you should be able to get your consumption down low enough that you are producing more fertilizer than you are using. It also helps that very little fertilizer is used in making supplies; most of it is mulch.

RNG stands for Random Number Generator. Think of it like a dice roll. If the correct "number" comes up, then you'll get the contract. Otherwise, you won't. This is done to make some contracts (like evacuation and medical emergency missions) appear more randomly (and less frequently) as opposed to other contracts which will always spawn if their requirements are met. Hopefully I explained that in a way that made sense. Does that clear it up at all for you?

I haven't played with this personally, but I think you would need to use the invertRequirement function, described on this page: https://github.com/jrossignol/ContractConfigurator/wiki/Requirements

@WuphonsReach Forgive me if I'm missing something obvious, but isn't that showing what you would expect? From the screenshot you posted, it looks like it is saying that you have not completed the contract 5 times yet (that is, it "met" the requirement of ContractType MaxCompletions being 5) and you do not have more than 3 offered/active Stock Antenna Balance contracts at a time (that is, it "met" the requirement of ContractGroup MaxSimultaneous being 3). That matches with what you said, namely, that you haven't run any contracts yet in that save. From your picture, it looks like if you perform an orbit of Kerbin and are able to research Basic Science, you will then meet all of the requirements, and the contract will be offered. Isn't that what's supposed to happen?

That sounds reasonable. After posting, I remembered that USI-LS actually includes some tiny radial cupolas. I'll probably just base them off that value (though your saddle tanks are bigger and heavier, so I'll probably scale the value up a bit so that they have the same mass:habitation rating. If I actually learn how to model, I would like to make dedicated long-term living parts for Mk3 and Mk2 vessels, but for now my computer skills are pretty much limited to config files.

I'be had an issue or two with the magnetic field contracts, always with existing vessels. I used to just cheat them to force them to complete, but the last few times I have found that just playing the game long enough would get then to work. Based on what you're saying, I'm guessing they probably started working at the first vessel change but I wasn't looking closely enough to notice. Since adopting my more patient approach, I have never had a contract that I have been completely unable to get to work.

Speaking of posts being reported and whatnot, I have a silly little question: when posts are removed by moderators, do rep points/likes associated with those posts not vanish as well? In the incident to which I think @mcortez is referring, I had a few posts that were eventually removed (not unreasonably) but had each received a couple of likes. I remember noticing at that time that my rep had just broken the 100 mark, and I expected it to drop below that again when the thread was cleaned up. Looking at it now, though, it seems like I still have those few extra points, which I found surprising. Not that rep/likes REALLY make any difference to anything, but I was just curious.

Hey, I'm just working on a USI-LS MM patch for M3X but I have a question or two... What's your vision for the inline cockpit? I know the description calls it a bridge rather than a cockpit. Do you imagine, then, that it would have any room for sleeper berths or the like in the underside of it? The reason I'm asking is because USI-LS adds the idea of habitation; that is, how long a person can stay sane inside a given part. Unlike the Mk2 size, Mk3 parts are quite large, so it would be reasonable to assume that they could have enough room to support crews on longer voyages (for comparison, base USI-LS uses the stock Hitchhiker as its go-to part for increasing habitation). This of course would be provided that they were laid out properly. The Mk3 passenger cabin is a huge part, but given its layout and the fact that it's meant to stuff 16 kerbals inside, it's still only as comfy as an airline. Since you mentioned you're targeting 3 crew members for the inline cockpit, I think it would be reasonable for that part to also have quarters for those three "below deck" as it were. My second question is the same thing, but for the crew saddle tank. Do you see it as a seating position, or more of a common space? I know it's small, but given that it has a table and pretty decent windows, I could possibly make it a habitation multiplier (base USI-LS does this for the stock cupola, and I'll be doing it for the M3X one. The idea is that having the great view/anything different than just a seat inside a cylinder gives the crew a space they can visit for a little something different, even if that just means a place to sit and try to spot Jool way in the distance).

As per our PMs, I've put together the first set of MM Patches for interoperability with USI stuff. First up is the M2X-to-MKS patch: //Adds MKS modules to M2X parts @PART[M2X_DropshipCockpit]:NEEDS[KolonyTools] //Makes the Dropship Cockpit a resource distributor like the karibou rover { MODULE { name = ModuleResourceDistributor } } @PART[M2X_Reactor]:NEEDS[KolonyTools|Karbonite|FTT&!NearFutureElectrical]:FOR[Mk2Expansion] //Removes M2X reactor modules and makes them MKS alike. Also edits flavor text { @entryCost = 5000 @cost = 50000 @mass = 1.1 @description = A compact nuclear reactor for interplanetary operations, spacecraft, stations, and surface bases. This reactor, in the Mk 2 formfactor, is completely compatible with USI models. @maxTemp = 3400 @TechRequired:NEEDS[CommunityTechTree] = largeNuclearPower !MODULE[ModuleResourceConverter]{} MODULE { name = ModuleResourceConverter ConverterName = Reactor StartActionName = Start Reactor StopActionName = Stop Reactor INPUT_RESOURCE { ResourceName = EnrichedUranium Ratio = 0.00000078 } OUTPUT_RESOURCE { ResourceName = DepletedFuel Ratio = 0.00000052 DumpExcess = true } OUTPUT_RESOURCE { ResourceName = XenonGas Ratio = 0.00000026 DumpExcess = true } OUTPUT_RESOURCE { ResourceName = ElectricCharge Ratio = 230 DumpExcess = false } AutoShutdown = true TemperatureModifier { key = 0 2000000 key = 750 200000 key = 1000 20000 key = 1250 10000 key = 2000 200 key = 4000 0 } GeneratesHeat = true DefaultShutoffTemp = .8 ThermalEfficiency { key = 0 0 0 0 key = 500 0.1 0 0 key = 1000 1.0 0 0 key = 1250 0.1 0 0 key = 3000 0 0 0 } } @RESOURCE[EnrichedUranium] { @amount = 22 @maxAmount = 22 } @RESOURCE[DepletedFuel] { @amount = 22 @maxAmount = 22 } !RESOURCE[ElectricCharge]{} MODULE { name = USI_ModuleFieldRepair } @MODULE[ModuleCoreHeat] { @CoreTempGoal = 1000 //Internal temp goal - we don't transfer till we hit this point @CoreToPartRatio = 0.1 //Scale back cooling if the part is this % of core temp @CoreTempGoalAdjustment = 0 //Dynamic goal adjustment @CoreEnergyMultiplier = 0.1 //What percentage of our core energy do we transfer to the part @HeatRadiantMultiplier = 0.05 //If the core is hotter, how much heat radiates? @CoolingRadiantMultiplier = 0 //If the core is colder, how much radiates? @HeatTransferMultiplier = 0 //If the part is hotter, how much heat transfers in? @CoolantTransferMultiplier = 0.01 //If the part is colder, how much of our energy can we transfer? @radiatorCoolingFactor = 1 //How much energy we pull from core with an active radiator? >= 1 @radiatorHeatingFactor = 0.01 //How much energy we push to the active radiator @MaxCalculationWarp = 1000 //Based on how dramatic the changes are, this is the max rate of change @CoreShutdownTemp = 4000 //At what core temperature do we shut down all generators on this part? @MaxCoolant = 400 //Maximum amount of radiator capacity we can consume - 50 = 1 small } } Not a whole lot here. The first part lets any vessel (under 10 tonnes, I believe) with the Dropship Cockpit ferry resources between two vessels/bases that are landed within 2 km of the dropship. The USI Karibou rover does the same thing. The second part rebalances/reconfigures the Mk2 reactor to behave like a USI one. Basically, it's stats are the same as the 1.25 m USI one (since the mk2 profile is basically a 1.25 m tube that tapers out on either end, I didn't think there would be any more useful space in there for more reactor) but it still keeps the radiator and lifting body. As a penalty, it is a little bit heavier and more expensive. The patch does not apply if NFE is installed for two reasons: one, you already have a NFE compatibility patch, and two, NFE modifies (or used to modify, anyway) USI reactors to behave like NFE ones. No point in overriding that. The USI-LS patch for M2X is even smaller: @PART[M2X_SmallLab]NEEDS:[USILifeSupport]FOR:[Mk2Expansion] //Adds a life support recycler to the Mk2 Science Lab. Supports fewer kerbals and less efficient than stock lab. { MODULE { name = ModuleLifeSupportRecycler CrewCapacity = 3 RecyclePercent = .4 ConverterName = Life Support tag = Life Support StartActionName = Start Life Support StopActionName = Stop Life Support INPUT_RESOURCE { ResourceName = ElectricCharge Ratio = 1 } } } The only thing I've done is added a life support recycler (which, in the USI-LS world reduces a kerbal's life support resource consumption rate) to the Mk2 science lab. USI-LS adds similar functionality to the stock lab, so this was pretty straightforward. When I do the M3X version, it will be significantly more efficient than this one, which is slightly less efficient than the stock one. Part of the problem with the Mk2 profile when it comes to USI-LS is the concept of habitation/living space. The idea is that a kerbal can't reasonably stay sane for months on end locked up in a Mk1 command pod for months on end, so the mod imposes a 7.5 day-per-seat limit, with a few parts being dedicated to habitation (the stock hitchhiker is one. It seats 4, but it's so large that it could conceivably have crew quarters dedicated to longer-term expeditions). Mk2 parts tend to be pretty cramped, though, so it's hard to make a case for which, if any, should allow kerbals to take longer voyages. The Mk2 crew cabin has airline seating; not the way you'd want to spend a month-long voyage. The best thing I can think of would probably be something the size of the stock Mk2 crew cabin, but with only capacity for 1 kerbal. I think anyone who is using USI-LS likely has to accept that the Mk2 fuselage is ill-suited for any trips outside of Kerbin's SOI. Like I said before, if you decide to ship these, make sure to ping me if anyone has any issues with them. No sense in sending you a couple of MM patches and then not at least trying to support them. Thanks!

The MKS ones will still exist. Going off memory and no sleep, I'm pretty sure that EL basically has one set of recipes which can be edited through MM configs (which is exactly what MKS' patch does). So, when you delete the whole file, both the MKS and EL parts should use the EL supply chain.

Well, you have a couple of options. Before we get into them, note that by default, MKS also changes the recipes/resource chain of EL. So, your options: First, you can just leave things the way they are and use the USI parts instead of the EL ones (MKS gives you an orbital shipyard, a ground-based launchpad, and a survey station. It leaves EL's Mallet and Survey Stakes) and the MKS resources. Second, you can go into GameData -> UmbraSpaceIndustries -> MKS -> EL_USI.cfg and delete all of the code below the line that starts with "// Removes all extraneous EL parts..." This will bring back all of the EL parts, but you will still be using the MKS resource chain. Finally, you can just delete the entire EL_USI.cfg file. This will bring back all of the EL parts and the EL parts will use EL resources, not the MKS ones. When running EL alongside MKS, I would suggest having a quick look at this page from the MKS wiki. If you are not familiar with the MKS supply chain, other pages in that wiki have details about it. Also, if you decide to go with either the first or second option, I would suggest you take any EL issues you have with regards to resources, recipes, or the MKS parts to the MKS forum thread. GUI and "how to use" EL questions are better off here. Sorry for the firehose of information. Does that all make sense?

Alright, I think I did this correctly. #1063.

Do you want me to log an issue? If so, where (MKS or Konstruction)? (I will use an issue this time, not a pull request!)

@dboi88 Thanks for the insight and update. The offending lines have been removed from the wiki. Also thanks for sharing that repo of images, fantastic work! Once we decide where the Salamander should go, I'll make up an entry for it. For what it's worth, I don't think the Ranger area would be inappropriate for them. It certainly doesn't belong with the Tundras, and I don't think it really belongs with the Duna class, either. It's a very preliminary sort of a vessel, like the Rangers. Sure, it isn't inflatable, but the Tundra page includes both inflatables and non-inflatables. Also, in the pre-0.50.0 days, the old Scout and Koala combo were both part of the MkV series along with the inflatables that are now the Ranger series.

Hey @RoverDude, I had a thought/question: with the Konstruction mod/parts being included in the MKS install, is there any reason that the four Akita rover parts are not included as well? It's certainly not a big issue, but it just seems like that one small folder would be a natural inclusion.

Alright, starting to feel like I am spamming the thread, but I have another observation. The "Functions: Med Bay and Colony Supplies" page mostly talks about ColonySupplies, the resource. It touches on how Med Bays and Colonization modules use ColonySupplies to affect hab and home timers. So far so good. In the Colonization section of this page, you will find the following two sentences: "Checking for Colony Rewards is not automatic, and is a function of the Pioneer Module. Rewards are accumulated with any MKS module, but can only be collected once a Pioneer Module is present." This isn't incorrect, but it seems to me like it's irrelevant to this page. The page is talking about ColonySupplies and hab/home times. If someone who didn't understand the Kolonization rewards stumbled upon this, I think it would just lead to confusion. Here we are talking about ColonySupplies, and suddenly there's talk of rewards and Pioneer Modules. I haven't stumbled upon a page detailing exactly how Kolonization rewards work yet (if we don't have one, we probably ought to make one) but I just don't think this page is the place. Thoughts?