TauPhraim

I just rebuilt it for KSP 1.4.3 Known to be broken: multi-bay calculations (the code has been reworked in MKS and would need to be re-studied). At a (very superficial) first glance, the rest seemed to work. [Edit]: Actually it was broken for drills, but after studying the new bays code I could fix all this in version 0.9.2 (multiple bays now appear as separate converters, even if configured the same)

I also experienced similar problems recently. Would you be running on linux too by chance ?

The effect will just scale (up or down) if the number of kerbals on board is not the exact "supported" number. But they act on the Kerbals in their vessel only, indeed.

Trying to reproduce, the explainer showed 20.79% indeed, but the stock game kept showing me 15.23% for some reason I cannot understand (and 15.12% with just one smelter bay, and strange things like 16.6% when warping etc). Anyway, I just released a new version of the explainer that shows 26.57 in this case. If your game behaves better than mine, that should match now !

Could you detail a simple example ? I'm not sure what slots this is about. I can think of a part having several MKSModule, but that would be due to patches, and probably not intended.

It depends on the part, but a lot of the MKS parts provide converters for life support. For these you won't have anything configurable.

MKSModule is for things related to bonuses and research. You need ModuleLogisticsConsumer for that. It's automatically added in a patch to all USI converters, so you don't see it directly in the part file (it's also automatically added to parts having MksModule, but that would bring additional things).

RO/RP0 is so big, I'm not sure it would be a matter of "just a patch". On the other hand, maybe it just works already without patches, have you noted problems ? But it's also so much harder than stock that I wonder what kolonization you could achieve. Even the Moon seems out of reach to me.

Probably the highest share, since the vessel's hab value itself depends on the number of kerbals, so the "if one kerbal were alone" amount does not actually exist. But anyway, I don't think what is described is implemented: I'd say timers are pushed back with no limit.

Yes, if running at 100% load, and acting on just 1 kerbal, it will push back timers 2x as fast as time passes.

The inflation should not happen automatically. If you partially inflate, you will have to re-perform some manual action for further inflation to happen. If you only have 3/4 of the materialkits, it will consume them, along with 3/4 of the required EC. There could be bugs, but I don't think this mechanism would drain some materialkits upon docking. I suggest retrying. Maybe the 2nd kontainer was accidentally sent empty ?

Yes 100% is the starting value for each body. They increase based on the number of kerbals on board and the converters you have (see MksModule descriptions in VAB to distinguish the 3 kind of converters). These bonuses in turn increase the productivity (load) of converters. EfficiencyMultiplier controls how fast the bonuses grow (actually the bigger the slower).

A known limitation is that it displays the "ideal" load, that you would get if the converter had room to store it's ouputs, and had enough available inputs. KSP can further reduce the load, for example if an input resource is not available, but is produced by another slower converter. It might be the case in your example, probably for Mulch: if you don't have any Mulch stored left, and your Kerbals on board cannot generate 448 per day by themselves, this will limit the Agroponics load. If by adding Kerbals, or stopping recyclers, or by storing some Mulch, you can increase the load, that's the explanation. I would love to fix this problem so that everything is self-explanatory, but it would require very complicated calculations across the whole vessel. Because this is explaining what the stock game does and I cannot see the stock game's source, I am not very comfortable attempting that.

If you accept inaccurate results regarding the external factors, just launch the vehicle and check the numbers on the launchpad. It sure would be more convenient to have that in-VAB, but currently I estimate the convenience/work ratio not big enough, sorry.

Also you have to get much closer to see the tube specific buttons appear, than for Disassemble.

I gave it some thoughts. But there are a number of missing things in-VAB compared to in-flight (planetary bonuses, surrounding vessels, ground resources concentrations ...) that would both make implementing this a bit bothersome, and render the results not so useful.

They do research as in, contributing to increasing MKS bonuses for planets they reside on. And collecting science via MKS parts that offer a "Check Kolony Rewards" button. But they don't work in stock science labs.

It should be, I just checked the code. Are you sure you had "Local Warehouse" enabled on the EU tanks ?

With this new version, (where I generate a random ID for each contract instance to keep vessel groups separate), I am now having issues with PartValidation: On contract generation/acceptation, the parameters are displayed correctly: "Vessel having part X" + "At least 1". But as soon as I focus on a vessel, even one without the part, the PartValidation parameters all complete. Also the "At least 1" line disappears, but I don't know if this is a consequence of the parameter completion, or the cause of the problem. Exceptionally, the "At least 1" line will remain, and the contract work as intended. But this is very rare, and seems random.

No, you have to make sure Fert(G) us displayed after the =>, AND click on the button. The converter name on top should then show "Fert(G)"

Let me rephrase it without confusing arrows "Fertilizer (M) => Fertilizer (G)" switches converter #1 from converting minerals into fertilizer, to converting gypsum into fertilizer. In the VAB: to get the one you want, click until the desired one is displayed on top. In situ, each change will cost you material kits etc, so you want to use the next/previous buttons, so that the change button directly does "whatever => desired_converter". Sorry if it's not clear. Please post a screenshot in this case, and I'll try to use real names/examples.

This bug will be fixed in the next release. It should only happen if you don't have USI-LS installed. In such case, greenhouse and habitat are useless anyway, so you can just not click on that. This means the part has 3 configurable converter "slots", and the buttons are for configuring them (Ex: "switch converter #1 from minerals->fertilizer to gypsum->fertilizer").

There is a bug (also with some of the classes). A fix is coming. Actually, currently the random button gives you a male, male gives you a female, and female gives you a random. That's for portraits though, but the first name of the kerbal is apparently always random (with or without the fix). If we pretend, after several thousand hours passed with them, to understand Kerbal culture enough to distinguish female and male first names, then indeed this randomness is problematic. Please log a github issue if you confirm that, as a fix would be slightly more complicated.

I tried a new version, abandonning the idea of fixing the last problem (assuming that when you accept the contract, the first vessel that you manage to get to the origin conditions is the one you implicitely choose for the contract). With that, I now have a problem when having several instances of the contract (with different vessels and origin/destination). It seems objectives complete for the wrong vessel (I can detail a case when a contract unexpectedly completes). I think this comes from the "define" identifier being the same, as it works across contracts according to the doc. Do I need to generate a random identifier for each accepted contract instance ? If so, can I use the Random() expression ? (it seems to generate integers).

After confirmation with RD: it's intentional that hab modules don't get the regular bonuses from MksModule (like geology*botany etc). hab is benefiting from a slightly different dedicated system: the kolonization bonus ("rep boost") is used, only once (not squared), and adds to the multiplier of the whole vessel. Ex (I think): if your kolonization is 120%, and you hab multiplier would be x3, you get x3.2 multiplier instead For #1 we'll probably do something so that the MksModule aspect does not show up in VAB, when it does not apply like here For #2 I could give a shot at including Hab in MksExplainer, but the calculations are extremely complicated, this might take some time