voicey99

The three ratings give bonuses to bases on the body-Geology rating gives a drill speed bonus (normal efficiency+[geology rating-100%]) as well as generating Funds as it increases. Biology rating I believe increases agricultural output (in the same formula as geology) as well as generating Science as it increases. Kolonisation grants bonuses to MKS converters (refinery, assembly plant, ASM etc. in the same formula as geology) and generates Rep as it increases. It also has the bonus effect of making all kerbals on that body (if USI-LS is installed) have infinite habitation time (if base hab time is 1yr or more) when ≥500%. Note that each rating is generated by different "groups" of specialisations (see the wiki). Note that FundsBoost=Geology rating, ScienceBoost = Botany and RepBoost = Kolonisation. The new kolonists are simply meant as cheap residents for you to pack off to your bases to perform the same functions as the more expensive vanilla specialisations, but each specialisation only having one skill makes them unsuitable for main missions. For example, if you wanted to be able to pull from Planetary Logistics (requires LogisticsSkill), you would need either a Pilot or a Quartermaster (who have the skill)-and a QM is much cheaper than a Pilot, the presence of which is unnecessary if only one of their skills is needed. The advantage of being able to bulk-ship the cheap MKS professions is that the ratings increase faster based on how many kerbs you have of the relevant specialisations, meaning a 10K kerbal increases their rating just as fast as their 250K multi-spec counterpart.

Does adjusting the flow priority (higher priorities will be drained before lower priorities) change the storage patterns?

@Fury1SOG Like this: You can just add ModuleLogisticsConsumer straight to whatever file modifies the fuelcell, no separate patch files needed.

I could be wrong (I don't use karbonite, but this what I think based on what I can tell from the cfgs and a bit of logic)-drive it around a bit and see if it works elsewhere in the biome. Apparently the Karborundum concentration on Eve varies from 0.01%-0.001% from biome to biome (but every biome is guaranteed to have some) and has a "variance" of "50"-whatever that means. That variance might have reduced the concentration to where it was simply too low for even those drills in that particular spot.

Actually, with the new MPUs (which have inbuilt automated PL push capacity) and automated drills, you can make reasonable unmanned outposts now (I made a PR for MPUs to get heat mechanics and an LF-OX mode next patch as well as a 900% ore processing productivity buff).

Seems like the pricing still has a few gremlins in it, the 2.5m and 3.75m MPUs both cost negative funds dry and hiring an MKS-spec kerbal from the AC with 0 courage and 100 stupidity costs you -14K (-28K and -42K when 1 and 2-star). Logged as issue #1188.

Like the first time this was mentioned, are you using USI-LS? Some of the modules you're trying to switch to might be dependent on USI-LS. Try running it with LS installed and see if it persists.

As of now you have to import them from Kerbin but DIYK production is coming relatively soon-ish(honest guv!).

The scanner says 0.0040% avg. That *might* be the average for the biome, not accounting for local variations.

If you insist on getting it looked at, then log an issue on the Karbonite git. Is it the same all over the biome, or does Karborundum concentration drop to zero in just that one spot (as it will vary over the biome)?

Can I ask why the OX-HEX is breakable in atmo? it doesn't make a lot of sense considering it's a fixed panel and it makes it somewhat difficult to use if it breaks on ascent every time unless its in an unwieldy fairing.

Having an ore separator on the MKS drills would be very helpful since it would mean you don't have to bring along one drill for ore and one for everything else, and can switch from ore to something else on the fly. Maybe give them an ore separator, but nerf the production on it to balance it vs the dedicated ore drills. For example, if the MEU-500 had an ore separator with a base efficiency of 30%, having all 3 bays set to Ore would produce a grand total of 1.8 ore/sec (assuming 100% conc) as compared to the DOM's 2.25/sec-i.e. it can do the job, but lower efficiency, higher heat production, higher weight and significantly higher energy consumption are a price to pay for its versatility. RD created the vanilla drills, so I guess it's up to him as to whether he considers that balanced or not. And @jd284 Could you not just add this to Biologist's section of Kolonists.cfg (unless SS specifically demands a scientist)?

[scrub that, I'm wrong]

As has been said many, many times-no.

Also been looking through some more parts, and I noticed the ME-100 doesn't have a configuration for ore (but its automated counterpart does). Unless this is intentional, I'll add it to the list in PR #1176.

Tagged heat and LFO changes to the MPU onto PR #1176.

It only applies if said pilot or scout has at least 1yr of hab. If they don't then they'll go just as nuts as the next kerbal.

And now the heat key curve on the 2.5m is behaving pretty strangely. If I have a curve of: then it heats up as expected, but as it climbs it instead suddenly grinds to a halt and stops rising altogether at 564.24K-not even putting it into extremely low orbit around Kerbol makes the temperature go above that. However, if the second key is set to 10000 instead of 25000: then it's much slower to start up but does not jam at that critical temperature and heats as normal until cooling kicks in at 1kK. If the 2.5m heating up slowly is fine by you, then its done.

...I just realised. I forgot to put GeneratesHeat = true in. Derp. ...And ModuleOverheatDisplay. I really need to proofread my syntax more. It's also why I test stuff before PRing it.

The MPU additions are nearly done as well, but there's one issue with the 3.75m I can't seem to work out-it's loading ModuleCoreHeat properly, but doesn't seem to be loading the TemperatureModifer/ThermalEfficiency sections. This is puzzling, since they're just raised versions of the numbers for the functional 2.5m, the heating part on which works just fine. This makes me wish the output_log still worked, since I can't find anything in the main log to explain why it wouldn't be working.

I believe resource abundance is tied to your save's resource seed, and I think the only way to change abundance is to change the resource seed (which will change all resources). If you want to go ahead, it's the GameSeed parameter under RESOURCE_SETTINGS. From the lack of a relevant parameter in the cfg, I don't think you can change the min abundance the drills can mine-but even if you could, when there isn't any, there isn't any.

There's some numbers under KolonizationScenario in the persistence, not sure what they mean (they might be how much each vessel has contributed to the ratings) but try tinkering with them. You might need to visit the planet first.

Just put a big, red notice at the top of the OP that's unmissable to anyone looking at it: MKS IS NOT CURRENTLY ON CKAN. You will always get people who don't bother to find out the answer to an FAQ, so it's best to just stick in in their faces where they can't miss it. It's taking a lot of willpower not to just say RTFM to all of them.

Last thing before I start on this tomorrow-what is the significance of the TemperatureModifier key values?

Maybe, since LF/OX doesn't really have a use within USI. I tend to judge a suitable conversion rate as something that is able to supply enough fuel cells to power it. A justification for using the super-slow MPUs over the stock ISRUs would be if MKS could modify the stock ISRU so that it doesn't work at all without the presence of crew (though this will likely form a pretty major noob bridge for those who don't RTFM)