[[1.12.x] - Modular Kolonization System (MKS)]

1 hour ago, jd284 said:

Is there a description of this? But anyway my problem isn't that the separators don't produce what they should (they do), but that they overheat doing so.

You seem to confuse MEU-500 (the drill) and TCS (the ranger heat pump). But yes you're right, when I tried it again additional cooling systems (ranger TCS or radiators) didn't help actually. So the problem is that the drill can't move its heat fast enough to the cooling systems.

But still that doesn't make sense, why would the drill have three separator bits when you can only use one of them at full efficiency without it overheating?  That actually makes the bigger drills less efficient and more expensive than many smaller drills adding up to the same production capability, which the TCS can cool with no problems. I doubt that's the intended behavior.

This seems to be this issue: https://github.com/UmbraSpaceIndustries/MKS/issues/1458. There's already a pull request with a fix pending. If you are in a hurry, you can change the numbers in the module-configs yourself. It worked for me.

Of course, I do not know if there is an intentional design decision behind, but I could not find a way to use more than one bay on the drills otherwise.

[[1.12.x] - Modular Kolonization System (MKS)]

1 hour ago, Nicky21 said:

What is this Wolf and Atlas I keep reading about ? Where can i get more info ?

Take a look at this wiki page: https://github.com/UmbraSpaceIndustries/MKS/wiki/Future-Plans

[[1.12.x] - Modular Kolonization System (MKS)]

Hi everybody,

first of all, a big thank you to @RoverDude for his awesome constellation of mods. I am currently experiencing the issue, that efficiency parts in MKS do not seem to be taken into account during catchup (also refererenced here: https://github.com/UmbraSpaceIndustries/MKS/issues/1441).

I did some investigation in the code base and have a quick fix which currently works for me, but would love some pointers to get this into a more permanent solution which I could provide as a Pull Request. Sorry if this thread is not the right place for such a discussion, if so, let me know and I will move it somewhere else.

Anyway, here it goes (sorry for the long explanation, but I did not want to leave out any facts):

Simple test setup is a Tundra Industrial Refinery combined with a 250 MPU. Industrial Refinery is set to Metals. MPU's bays to [Smelter]. When running this setup for 10 Minutes in the Refinery Scene, I get the correct amount of metals produced. When running it from the Tracking Station and returning to the ship (thus triggering catchup), I get an amount of metals as if the efficiency impact from the MPU was missing. I can provide a simple save file on request.

Debugging the code, I narrowed it down to a line in MKSModule.GetActiveBoosters:

totalEfficiencyBoost += (float)(booster.EfficiencyMultiplier * booster.Multiplier);

The EfficiencyMultiplier is calculated in USI_EfficiencyBoosterAddon during PostProcess. Unfortunatly, this has not been called when the catchup-mechanic (and thus GetActiveBoosters) runs, so it returns "0".

My current quick fix is to simply set the EfficiencyMultiplier to "1" if we are in catchup.

if (InCatchupMode())
	totalEfficiencyBoost += (float)booster.Multiplier;
else
	totalEfficiencyBoost += (float)(booster.EfficiencyMultiplier * booster.Multiplier);

This of course results in the expected booster effect when testing it in the game, but is a cludge.

The actual efficiency multiplier (when not in catchup) is calculated as follows (in USI_EfficiencyBoosterAddon from USITools):

public override void PostProcess(ConverterResults result, double deltaTime)
{
  base.PostProcess(result, deltaTime);
  EfficiencyMultiplier = result.TimeFactor / deltaTime;
}

During my test case TimeFactor and deltaTime where always pretty close, so the EfficiencyMultiplier resulted in a number close to one, but I currently do not understand the involved variables (TimeFactor) and deltaTime (which seem to come from Stock KSP where I can not investigate the code).

Can someone give some insight here?

I currently see two solutions, for which I would like to get some input:

1. Make sure PostProcess is called in catchup before the booster calculations. I am currently not sure, where to go for this and how large of a change this would be.

2. Understand the efficiencyMultiplier-Logic and handle it during the booster-calculation (I tested changing the governor setting but could not see any change).