Johould

I think the bay problem comes from only the drills and the Duna agriculture module having been changed to use the new ModuleSwapControllerNew/ModuleSwappableConverterNew system. Edit: Ah, that's not exactly it - the cause was the deletion of the ModuleSwapConverterUpdate code while adding the new system, without anything else replacing its role of setting a "SwapBay" bonus on the active conversions. Putting the bay counting into ModuleSwappableConverter seems to fix all the production issues I was seeing. (Before getting into this code I first tried switching parts to the *New system, but didn't see a way to have a converter bay that could also reconfigure as an efficiency part, which the MPUs need). Here's what I changed:

If you are interested in a Linux version, it didn't take much to get it running under the Lazarus IDE for Free Pascal (v1.6.2). It has a Delphi project converter, I let it comment out the AppEvnts dependency when the converter asked, then changing five more lines gets everything functioning. (The fonts are different so some text is a little cut off, but it still computes flybys just fine). Here's a patch: If you can't apply the patch file with "patch" or would rather make the changes manually, you have to start by change TApplicationEvents to TApplicationProperties in the form file with a text editor. Until you do you can't open the form in the graphical form viewer, because there is no type named TApplicationEvents in Free Pascal at all (A type TPaintBox exists but I guess it behaves differently than the Delphi version).

Huh, where do interpolation schemes come in? Is that just interpolation within a single time step? Sets of coefficients for polynomial interpretation is how NASA releases projected positions in the real solar system, I thought they were a bit more related.

That's the ephemeris occasionally mentioned in the changelog. I don't know the exact time range or storage, but the motion of celestials is precomputed.

@RoverDude About the inflated tank costs, I wonder if it was a problem that this commit https://github.com/UmbraSpaceIndustries/UmbraSpaceIndustries/commit/17ac57b6909d76bde6dbf2af38457004c09f2a0c#diff-65293d6df5b927b868a7f2800b7472d7L322 removed the method float IPartCostModifier.GetModuleCost(float defaultCost) { return inflatedCost; } added in "Add inflatable cost modifier when inflated"? Edit: @RoverDude after remembering how compile mods, I can confirm that was the problem. That method's signature has changed slightly, but adding this ModifierChangeWhen IPartCostModifier.GetModuleCostChangeWhen() { return ModifierChangeWhen.CONSTANTLY; } float IPartCostModifier.GetModuleCost(float defaultCost, ModifierStagingSituation sit) { return inflatedCost; } makes an inflated "Refine RefinedExotics" recover for the same cost as the uninflated part, rather than subtracting ~7M funds when recovered.

Has anyone else checked if an MPU with multiple bays set the same product works properly in KSP 1.4.3/1.4.4? It should run up to 200% load with two bays (plus Kolonization bonus), but I only get 100%. I'm pretty hesitant to design any bigger bases until I can correct this

To add a little more, with EasyVesselSwitch an EVA isn't enough (switching back to the tracking station a bit will recompute the connections).

The problem is the "Max Cooling" on the drill itself, 100kw on the MEU-500. This is more than enough radiators: (That's 15 Ranger TCS attached to the parent of the drill - one hidden under the battery stack) Exactly the same temperature is reached with 2 edge radiators (150kw core cooling each). Here are relevant bits of the MEU-500-A part file: According to this post: the "Temperature Modifier" means each active harvester would put out 5000/50 = 100kW at 500K, but MaxCoolant = 100 means the drill core can't be cooled by more than 100kW total (maybe plus a bit of conduction from core to the rest of the part?). It looks like it can eke out a bit more production with a second harvester active overheating slightly past 500K because the section of the curves just above 500K has the ThermalEfficiency curve cutting productivity slightly more slowly than the TemperatureModifier curve cuts heat output.

Are you thinking of making a gravity tractor?

No, it's impossible to get even 4000dV in a single stage with the GNR engines. Kontainers follow the stock 8 kg LF to 1 kg tank ratio. At that ratio the maximum possible deltaV with a NERV is 800*g0*log((8+1)/1) = 17238 m/s deltaV. To have the same limit for GNR engines you would need a LH2 tank with a wet:dry ratio of 9^(800/900) ~ 7. Instead, Kontainers have the same dry mass for any contents and same volume of LF and LH2, so they only carry 7% as much mass of LH2 as of LF, giving a wet:dry ratio of 1.56 and a deltaV limit of 3925 m/s.

Recovering an inflated Tundra ISM that is configured for refining RefinedExotics subtracts almost 7 million funds! It seems to have something to do with "inflatedCost" in the save, but I don't see how that field affects recovery cost.

I thought I had already seen a similar report, it must have been your fix for the Ranger ISM.

@RoverDude Does your reply mean that you have observed converters with multiple bays hitting 200% or 300% load on Kerbin in a 1.4.3/1.4.4 game? I noticed the Tundra ISM LFO configuration has the LF/Ox ratio reversed. Here's my patch: --- orig/Tundra_ISM.cfg 2017-04-28 21:23:16.000000000 -0500 +++ fixed/Tundra_ISM.cfg 2018-07-24 16:28:48.881960468 -0500 @@ -71,3 +71,3 @@ resourceNames = Silicates,Silicon;Substrate,Polymers;ExoticMinerals,RareMetals,Chemicals,RefinedExotics;Hydrates,Water;Karbonite,Water;Ore,Water;Minerals,Chemicals;Gypsum,Fertilizer;Minerals,Fertilizer;MetallicOre,Metals;Ore,LiquidFuel,Oxidizer;Ore,LiquidFuel;Ore,MonoPropellant;RefinedExotics,Silicon,SpecializedParts;Metals,Polymers,Chemicals,MaterialKits;Substrate,Water,Organics,Fertilizer;Dirt,Water,Organics,Fertilizer;Organics,SpecializedParts,MaterialKits,ColonySupplies;SpecializedParts,MaterialKits,Machinery;Recyclables,Metals,Polymers,Chemicals;Mulch,Fertilizer,Supplies;Substrate,Water,Fertilizer,Supplies;Dirt,Water,Fertilizer,Supplies - resourceAmounts = 55,11;55,11;11.5,11.5,34.5,11.5;46,23;55,11;55,11;55,11;46,23;55,11;55,11;55,6.05,4.95;55,11;55,11;4.38,43.75,21.88;14,14,7,35;30.6,30.6,8.6,1;32,32,5.8,1;21,7,7,35;7,28,35;35,7,7,7;31.5,3.5,35;78,78,1,7.8;34.2,34.2,1,1.4 + resourceAmounts = 55,11;55,11;11.5,11.5,34.5,11.5;46,23;55,11;55,11;55,11;46,23;55,11;55,11;55,4.95,6.05;55,11;55,11;4.38,43.75,21.88;14,14,7,35;30.6,30.6,8.6,1;32,32,5.8,1;21,7,7,35;7,28,35;35,7,7,7;31.5,3.5,35;78,78,1,7.8;34.2,34.2,1,1.4 initialResourceAmounts = 0,0;0,0;0,0,0,0;0,0;0,0;0,0;0,0;0,0;0,0;0,0;0,0,0;0,0;0,0;0,0,0;0,0,0,0;0,0,0,0;0,0,0,0;0,0,0,0;0,0,0;0,0,0,0;0,0,0;0,0,0,0;0,0,0,0

If you can convince CKAN to install it (I've never used CKAN), everything should work except trying to use ground construction parts, and maybe the trouble I have with multiple-bay manufacturing parts. If you are starting a new campaign it will be a while before you need either. Manually installing ground construction 2 seems to work ok, or you could wait for the next MKS release.

I forgot that in the new 1.4.3 install, but nothing changes after adding https://github.com/UmbraSpaceIndustries/UmbraSpaceIndustries/releases/download/0.12.0.0/USITools_0.12.0.0.zip (md5 18ee76355dcc1a72ea81b9530a0c72e1). I had already installed that manually in the modded 1.4.4 install where I first noticed this problem. Maybe you have been testing with a newer build?

I just completely uninstalled KSP 1.4.4 and reinstalled 1.4.3 from steam, and see the same problems. Has anyone seen multiple-bay converters working properly with MKS 0.55 on 1.4.3 or 1.4.4?

It only shows a single line in the 1.4.4 game: In the 1.3.1 save it shows the expected results (including a line "Bays: 2"). In the MKS Explainer thread TauPharim said the multiple-bay code has changed in MKS, but a fix might be included in the 0.9.2 Explainer that I'm using. Here a craft file showing the problem with just a pair of MPUs. It looks like it has an ModuleResourceConverter_USI module for each possible conversion, with at most two saying "isEnabled = True", and two "ModuleSwappableConverter" modules with a "currentLoadout" field saying which converters are active. That looks like exactly the way the parts are configured in the KSP 1.3.1 game - I there anywhere bits of an older MKS could survived deleting and redownloading the 1.4.1 GameData folder, installing into it only the latest MKS, and making a fresh save for this test?

Do you expect 0.9.2 to work in 1.4.4, and handle multiple bays? I'm trying to diagnose an issue where two bays (2xLFO in a 2.5m MPU) only run up to 100% load. It reproduces with only MKS installed, and I just tried adding MKS Explainer to the test game but the explanation pane for the MPU just only a single line: In my 1.3.1 game it agrees with the observed and expected 200% load. I always use this mod with MKS. Thanks for making it!

Production with multiple bays is not working, now in a clean KSP 1.4.4 with only MKS_0.55.0.0.zip installed. I'm getting the same load and production rate from parts with one bay or multiple bays configured for a product. This screenshot shows the test set up - an MPU with two bays set to LFO shows the same 100% LFO load and produces exactly as much LFO as an MPU with one bay set to LFO (and whether or not the second MPU's other bay is making Monoprop). The assembly plants are similarly set up so one has three bays configured for MaterialKits and the other just one, but they also show the same load and have the same production rate (the craft has 4 5-star engineers, two in each assembly plant, plus Bob in the hub).

Not present. Haven't checked unreleased code.

That's basically how it's supposed to work, though multiple bays seem to be broken in my 1.4.4 game. The base rate seen in the VAB is actually supposed to be the amount at 100% load, so it will be multiplied by the number of bays as you expect, but also will increase with Kolonization bonus, or is decreased if you lower the governor. (I also seem to see a bug where the listed power consumption in the VAB is wrong, but it scales that way and the power in the cfg file is correct).

That's what I expected to see. I tried my 1.3.1 copy of KSP and that's what I do see there. In 1.4.4 it only runs up to 100% no matter how many or few bays are configured the same. Looks like I need to try a minimal MKS-only install. Until I do, here's my mod list. Anything look suspicious?

I am now confused how multiple bays work.I thought a part with multiple available bays would be more productive if several bays were configured for the same conversion, but that doesn't seem to be true at all. I made a vessel for on-pad testing in a new sandbox game (ksp 1.4.4), which had 2 2.5m MPUs and 2 Tundra Assembly Plants, with one MPU configured both bays for LFO and the other one for LFO and one for Monoprop, and one assembly plant set up with three bays for MaterialKits and the other with one bay for MaterialKits and two others on other conversions. There was one 5-star engineer and plenty of input resources and space for outputs. Both MPUs had just one "Start LFO" button, and ran up to 100% load if activated. Checking production rate in inventory the Kolonization dashboard showed the same output rate whether I was running LFO production in the one-LFO-bay MPU or the two-LFO-bay MPU. Also, when running LFO production in the mixed MPU, starting the monopropellant converter did not change the production rate of LFO. I expected the two-LFO-bay MPU would produce LFO twice as fast, or if not then at least that multiple running converters would split productivity. The assembly plants similarly showed the same MaterialKit production whether I was running the converter in the assembly plant with three bays configured for MaterialKits, or the one with only one converter configured for it. The latest MKS Explainer also agreed with the output rates and didn't show any factor in the equations for number of running bays. Is this working as expected, or should I be looking for mod conflicts? There is one more stock thing to try - is crossfeed enabled on the docking port? I think ISRU production of LFO probably respects ordinary fuel flow limitations. The Klaw may not support crossfeed at all. The inflatable storage modules are probably the easiest way to add capacity to the rover. The Ranger ISM is much smaller when undeployed, the Tundra ISM has a bit more capacity for the same mass, but is much bulkier (it also has the LF to Ox ratio backwards, you'll need to edit the file).

Ok, so basically go with the dedicated ISRU part for LFO production at low kolonization bonus. I'm mostly surprised the larger stock ISRU turns 1kg ore into 1kg LFO when everything else needs 10kg ore per 1kg LFO. The USI wiki claims the MPU also converts 100% of the mass of Ore into LFO. About the drills, the "'Drill-O-Matic' Strip Miner" info in the VAB shows a pane for drilling Resource Harvester Surface Harvester (Planetary use - 800% base efficiency) Max Inputs: - Electric Charge: 960/sec Max Outputs: - Ore: 8.00/s But the actual EC consumption at 100% load, independent of the ore richness, is 120 EC/sec (which is also the number in the data file). 960=8*120. The stock Drill-O-Matic lists 150% base efficiency, 22.5 EC/s and max output 1.5 ore/s, but actually takes 15 EC/s at 100% load (22.5 = 1.5*15).

I'm designing an unmanned LFO factory and wondering if there is any point to using the MPU's LFO converter. (I know about including one to push to planetary logistics). All this sizes of MPU all have the same Ore->LFO conversion ratio ("economic efficiency" on the MKS wiki) as the Mini ISRU and take 10x more EC to do, while the full size stock ISRU produces 10x more LFO from a given amount of ore, and even unmanned at 5% load it can product LFO faster than the biggest MPU at 100% load. Is MKS be used with a patch nerfing the stock ISRU? Is the MPU mostly meant to be used for the other converters? Do the MPUs catch up with high Kolonization Bonus? I also noticed that drills all seem to show incorrect EC usage in the VAB - it looks like the actual amount it uses at 100% is further (and incorrectly) multiplied by the "efficiency factor", which seems to only actually affect how much ore is produced at 100% load and not actually change output. Is that actually a bug, or a stock bug?