voicey99

The EPL parts that still ship with MKS are going to be removed soonTM though.

As the max cooling stat is effectively infinity then I suppose a single TCS would be able to cool an unlimited amount of parts assuming none of them produces more than 3GW of heat.

You have to ship the DIYKkits in from Kerbin, but they are much smaller and lighter than the vessels they contain the 'blueprints' for contain since you can build them onsite with materialkits. You can't make the DIYKits boxes themselves onsite yet, but support for doing that is in the works. OSE lets you make stuff for attaching with KIS, but you can't use symmetry with KIS so prepare for infuriatingly misaligned parts. Your manned base's drills are not at full thermal efficiency yet. Also, the engineerless vessel's drills are the automated variants, which means they always operate at at a specialist multiplier of 1, while the manned drills operate on the formula of 0.05+0.2*highest skilled engineer/miner on vessel's level (0-star=lvl 1). This means automated drills are always slightly less efficient than if you had a 4-star engineer on the vessel, if Bill is 0-star then the unmanned drills will be operating at a 5x higher rate than the unmanned drills, possible explaining the discrepancy. This mod is useful for investigating things like this. It also goes without saying that unmanned bases should have auto drills in addition to the unmanned PDUs (the latter of which combine PL push function and optional resource processing). Not sure what you mean by mini-miners but yes, you can just throw them everywhere. They have to have a module capable of pushing the contents of their kontainers to PL though, which (expanding on @TauPhraim) atm is the two logistics modules or an MPU. Both types can push to PL without a pilot or quartermaster on board (contrary to popular opinion-try it, you don't need one), but the manned logmod requires a pilot to pull stuff out again (but for mining outposts, you don't need that. The PDUs also can't pull even when manned). You don't have to process resources onsite, I prefer to simply ship them to a central processing hub which cuts out the need for maintenance runs. If you do insist on resource processing in-situ, the MPUs and reactors will need servicing by an engineer every... /////////////// MPUs Reactors 0.625m ------------------ 772d (1.81y) 1.25m 9,259d (21.7y) 1,306d (3.07y) 1.25m (s) ------------------ 868d (2.04y) 2.5m 9,259d (21.7y) 1,188d (2.79d) 3.75m 9,259d (21.7y) 1,240d (2.91y) Tundra ------------------ 193d (0.45y) Duna ------------------ 154d (0.36y) Last time I calculated this, @RoverDude said he was going to buff the uranium capacity for the PDUs. Also worth of note would be that MPUs (like all machinery-using parts) slow down as they run out of machinery, meaning they use machinery slower. As such, MPUs will never quite run out of machinery but they will run exponentially slower until they are doing almost nothing with barely any machinery left. As for the TCS, completely ignore the max cooling stat-RD wrote some custom code for it whereby it deletes any heat it takes in. Don't worry about it. @Terwin I tested it, the TCS applies whole-vessel cooling. No need for spamming them.

It's under manufacturing. I also explained multipliers in the linked post for ratings, but the drills get the geology rating squared (so a 127% rating means you get a 1.272=1.6129 mult). The drills also have varying mults for how much cooling they need and how much they have, and I amended the descs some time back to explicitly state that all stats are per drill bit. The TCS provides 3MW of cooling, which I believe is vesselwide.

Reply Stack Time! See this post (5th paragraph after the pic) for ratings. It's only 2.2yrs to Jool, less if you put your foot down like I do. If you're going to send a ton of kerbs, you have five options: Make a massive ship, send a load of smaller ships, let them grump out and restock them when they arrive, use DeepFreeze to pause their stats or use a kolonisation module to maintain their hab stat with colonysupplies. Hab multiplier (when kerbitats are set to hab-common mode) is also calculated individually for each part so you get penalised more and more as your on-craft population increases (and so is more and more over its 'max crew' stat-the multiplier is divided by the number on board divided by the max crew stat if it's over capacity), which makes it exponentially more difficult to transport increasing numbers of kerbals. You don't make Ka/Ka+, you mine it, extract it from the ocean, filter it out of the atmosphere or collect it from the exosphere (very low orbit-see the cfgs for where it should be). The idea of a fuel Tundra module has been mooted before, with general consensus (and RD's opinion) being that it's surplus to requirements. The biggest Mobile Processing Unit is in the same form factor as the large Tundra modules, though. I typoed 'MiniSRU' it should read 'MiniISRU'. GC is Ground Construction, the mod brought in to replace EPL for offworld construction. The BUNDLED version is pretty well integrated with MKS already, but further cooperation is in the works. You select a vessel to put into a DIYKit in the VAB, ship the kit over and assemble it from the kit with materialkits and some time. MKS has a special part for this, the Ranger Thermal Control System. In terms of general radiator stats, 'core heat transfer' is the max amount of heat it can pull from a single part, 'max cooling' is self-explanatory (for the TCS, ignore its suspiciously low stat), I don't know what 'transfer rate' is and 'cools up to #x part temp' means it can cool parts that are down to 1/# it's own temp. MKS drills are also notorious cooling-hogs (this is necessary to accommodate the sometimes absurd production bonuses and multipliers), so if you use them be sure to have a TCS on your craft. MKS has its own MKS 'Tundra' Nuclear Fuel Plant for enriching uraninite and re-enriching spent fuel. Like the other processors, it can be found under the Manufacturing tab. A note on refuelling reactors: To refuel them, you will have to get an engineer out on EVA and go up to it and select 'perform maintenance' to pull uranium from containers on the same vessel or <150m away.

@Virulent In that case, add this to AddConsumers.cfg (correct if wrong):

None of the other colony parts have nicknames. That might just make it confusing, since they don't need them. All the Kolonisation parts use one universal template model for each line, so you would have to create a whole load of new, unique models for that. But by all means! The stock ISRU is not a logistics consumer, nor is the 5m tank. I'm not sure what the module is to add that, try adding the MKSModule to it? And by 5m tank do you mean the USI tank? If it's non-USI it won't interact with logistics properly. Never used EPL, sorry. I think machinery can be transferred by PL, though. EPL is also not officially supported, so don't expect any work to be done on this. Pilots/scouts only need one year of habtime to get perma hab. All other kerbals get perma hab when their timer is above 50yrs, or 1yr if that planet's Kolonisation rating is >500%.

I'm looking to write a USI-LS patch for VSR, which involves inflatable hab modules. How would I write a patch so that the hab functionality can only be activated when the part is inflated?

It's to save landing as far as I know. The only places that have exospheric Ka in my game are the guaranteed Kerbin and Jool, the latter of which's band is so deep inside its gravity well it wrecks any bonus you get from not having to land.

It does NOT like atmospheres. I've found it to be next to useless anyway, considering how rare exospheric Ka/Ka+ is.

I believe so. I don't see why it wouldn't.

USI_InertialDampener. It comes with the USITools DLL (not the MKS DLL, KolonyTools).

MKS also has patches for the RO mods CLS, DRE, FiltexExt, RemTech, TAC-LS and KAS already. Right now, patches are low-priority.

I'm sure it will-pity it'll only be for the 1.3 version. Most people need to be told how to make GH PRs, so you're doing well. If you're going to be editing multiple files at once, I might suggest using the 'GitHub Desktop' program, which allows you to edit local copies of the files on your computer (use MS Virtual Studio to edit the source files, there should be a .csproj file in the directory that allows you to edit all the source files from one location), and include multiple file changes in one commit rather than spam them like one of mine before I started using GH DP.

The pull request is up, RD will eventually get round to merging it in if it works (I can't tell, I don't know C#). As an FYI, RD prefers for PRs to be submitted to the dev branch rather than master, but it's not a huge deal.

You should probably ask in the AD thread, lest we open that particular can of worms again here.

Yes, I did mean for you to do it at the time, but you've done it now. I might suggest putting a little more description into the ticket, but don't be so worried about doing stuff on GH. Ask me if you don't know how to do something.

If that's the case, I'm inclined to agree with him in that calculating the multiplier on a per part basis penalises you too much for having large numbers of crew. Ideally, I would have kerbals be assigned to the best hab facility and when that's full be assigned to the next best facility and when all facilities are full then the penalties would start to kick in so each kerbal would have their own time calculated individually in a more sophisticated way as opposed to unfairly applying the same penalties to the entire crew. This would be more coding work though, and would probably result in noobs who can't be arsed to check the wiki turning up and asking why their kerbals have different habtimes.

This is gibberish. I can't tell what you are trying to say.

What do you mean by 'cal'? Nothing's wrong, but it's probably designed so you can't do what you're trying to do i.e. spam cheap, low-capacity modules. As your crew complement increases, you have to use bigger and higher-capacity ones.

Hm. I did some testing and it seems that the habtime calculations are done individually for each multiplier part, so they are indeed reduced to 1/10 of their multiplier for each (assuming each has an crew affected stat of 1). This makes the total hab multiplier a lot more complex to calculate (e.g. if you have 8 kerbs on a vessel with a 3x part rated for 5 kerbs and a 1x part rated for 1 kerb you would get a total mult of (3*5/8)+(1*1/8) = 2x overall). It's not like in USI-LS where you can have one high-efficiency recycler and spam small ones to up the crewcap. I checked and indeed it does. Still, MKS and USI-LS add so much to each other they playing with only one of them only seems to give you half the mod.

Strictly speaking, no, but USI-LS only offers 2 parts to extend habtime (the stock PPD12, cupola and USI-LS cupola) and offers no method of sustainable supplies production. MKS adds more habitation-related parts and a way to produce supplies/fertiliser in-situ. SXT also has a few parts for habtime.

That's not a USI cupola. When you hover over it and rightclick it should display a lit of 'modules' that part has (from the config)-look for the one titled 'Habitation' and its 'crew affected' stat.

I think we're having some communication issues here. It should say the crew capacity in the infobox when you hover over it.

What is the stated crew capacity in those observation modules?