[Ongoing Dev] [0.23.5] Modular Kolonization System v0.16 (RELEASE) [05-10-2014]

[RoverDude]

Wrapping up latest update. Big changes are rebalancing for power consumption, a few new parts, emissives, and a total folder reorganization (for better asset sharing to reduce memory footprint)

[RoverDude]

Regarding production rates: so the only thing affecting production rates on the MKS side of things is the overall % Efficiency value? EPL's production values appear to be influencing individual MKS module's production rates (that is: MKS modules with smart Kerbals in them are producing noticeably faster than modules with stupid kerbals inside of them while running MKS alongside EPL). Is this intended?

This is normal - the range between a smart Kerbal and a stupid one is a pretty wide range. Smart ones can be up to 2.5 times as efficient as a stupid one. And REALLY stupid ones will kill your productivity - that's all reflected in the % you see on efficiency, which is 25% - 250%.

The overall affect isn't a bad thing (it adds another dimension to individual kerbal assignments within the base), I'm just still trying to wrap my head around the way the two mods are interacting with each other. I've set up another test install running MKS without EPL to try and get a better feel for things, and will see what I can document -- I think it's safe to say that MKS+EPL will be popular together.

Let me know how that goes as I have not yet played with these two mods together.

I'm also seeing efficiency rates of up to 250% for modules that are actively staffed by kerbals, though 200% seems to be the cap for unmanned modules. Is this working as intended? It's happening both with and without EPL installed, so I know it's not related to that.

Range should be up to 250%, but that would likely require manning (unless you have a LOT of Kerbals). Placement inside of a module gains more than placement inside of the base in general.

I've also been wondering is what exactly the three numbers listed after the efficiency value refer to. (ie: "Efficiency 200% [1k/10s/1m")

1 Kerbal, 10 Workspaces, 1 active module.

RE consumption, I just did a pretty major change to power balancing (a module that required 400K of power per day now requires 120K). This should address some of the power concerns.

[RoverDude]

So I did another full run test, was able to do an entire colony at 50x consumption with a recycling based supply chain and a pair of greenhouses and kerbitats with four PDU's, also pretty much zero lag. So at this juncture, I spent the morning knocking out the specific items that I want to resolve prior to launch (you can see the entire outstanding enhancement/issues list on GitHub at https://github.com/BobPalmer/MKS/issues?milestone=&page=1&state=open)

Specifically:

Evaluate and finalize Kethane consumption rates. Basically, I am looking at making sure the volume of resources that show up in the default deposits makes sense. These look good, but I want to run some numbers. Will also up-tweak water a bit as right now it's pretty scarce. ORS integration will be done post-release.

Evaluate EL compatibility I'll be installing EL and making sure my consumption numbers are in line with EL (i.e. MKS Ore->Metal conversion should be comparable to EL's Ore->Metal conversion rates). Adding EL-specific modules is going to be something done post-release.

Reset IVA vide for Go-Live Custom IVA views are on the longer range list, but for the short term I need to make sure the current pieces have placeholder IVAs (the tough one is the colony hub as this has six seats).

Add UI Element for ProxyLogistics I'll be adding visibility RE proxy range as part of the UI for these components.

Implement Courage and Stupidity as part of ProxyLogistics Right now, ProxyLogistics is hard coded for a 200m range. This will be changed to a variable range based on the Kerbals in the logistics module, as well as their relative stupidity and bravery.

Add compatibility for Bahamut EL drills This is a pretty popular request, so these configs will be included as part of release.

Update documentation I will be going through documentation, tutorials, etc. and getting them up to date with the latest info.

So at this point, the current version out there (0.15) is pretty darn stable - i.e. none of the release notes above (other than a potential conversion rate change) are breaking. So any final bug reports, etc. will be greatly appreciated.

Thanks!

[RoverDude]

EL Support:

- Will use the same mass for Metal and Ore

- Will keep MKS conversion rates (which are slower), feel free to change these if you would like. Basically, it would entail changing too much of the MKS conversion rates.

- Will be using MKS values for the Kethane resource mapping - Red for ore, Orange for substrate, to be consistent with how Kethane does a saturation variance not a color spectrum variance.

- Will not, at this time, be pursuing any MKS modules for making RocketParts, etc. Players are free to use MM to add these capabilities to any of the MKS models as they are released under a CC license (with attribution).

- Will provide support for the Bahamut drills

[crimsonknight3]

Resources can transfer between ships on the ground within 100 meters - even if they are not connected!

I have a question about this? How is this possible? I mean in my testing at ksc NO resources are transferred between each module even if for example food has ran out, tried this having the modules connected with kas and with docking ports. The only way I have managed to set up this automatic transferring is using the tac fuel balancer mod, I tell it to move for example food OUT of a supply module, and "balance" between any module that needs foods and it ignores the rest. How do I set up this automatic transfer? I should also ask what is the benefits of connecting modules if resrouces can be transfered within 100m anyway? The Link on KAS is shorter than that, and docking is more of a pain, so is there even a benefit to linking your entire base up?

[edit] Or is the wiki out of date? lol

[RoverDude]

WIKI is out of date Still works, but only between ships that include one of the jumbo-sized storage huts.

[RoverDude]

RE benefit - new range is 200m (to be changed with release and become variable). Easier to set up lots of smaller bases, avoids docking/etc. (kinda a pain) and KAS only has a 50m range for pipes. Plus a bit more Kraken proof - lots of KAS pipes tend to eventually explode my bases.

What I am testing out is REALLY long ranges - like, several kilometers (i.e. out of load/physics range) to see how that works out. Just no guarantee on those yet till I run some tests.

[Izandral]

in the image on the first post , how do you get the modules to connect together sideways like that , i can only connect them from top or bottom.

[RoverDude]

in the image on the first post , how do you get the modules to connect together sideways like that , i can only connect them from top or bottom.

Those are some older pics - the newer way is to use a hub at the bottom, a tube to connect sideways to another hub, and a module on top of the second hub. Better images of this later in the thread.

[Fraz86]

I have a small request, if it isn't too much trouble.

I play with TACLS, with extensive personal customizations via ModuleManager config files. I've been integrating elements of your mod, which I greatly enjoy, into my customized crew support system.

In particular, your KolonyConverter module has been a great asset to my endeavors, due to it's very useful features (i.e., requiredResources, SurfaceOnly option, efficiency based on crew). However, in some situations, I'd like to be able to create a module with requiredResources or SurfaceOnly, but without efficiency based on crew. Thus, if this would be easy for you to implement, I would greatly appreciate an "EfficiencyBasedOnCrew" boolean as a variable of the KolonyConverter module.

Edited May 7, 2014 by Fraz86

[RoverDude]

I have a small request, if it isn't too much trouble.

I play with TACLS, with extensive personal customizations via ModuleManager config files. I've been integrating elements of your mod, which I greatly enjoy, into my customized crew support system.

In particular, your KolonyConverter module has been a great asset to my endeavors, due to it's very useful features (i.e., requiredResources, SurfaceOnly option, efficiency based on crew). However, in some situations, I'd like to be able to create a module with requiredResources or SurfaceOnly, but without efficiency based on crew. Thus, if this would be easy for you to implement, I would greatly appreciate an "EfficiencyBasedOnCrew" boolean as a variable of the KolonyConverter module.

Sure. Just added a new field called CalculateEfficiency as a boolean, defaults to true.

[RoverDude]

Just uploaded a pre-pre release of 0.16 to GitHub. This will be the final version before publish. Balancing is done, just going through some final testing.

[RoverDude]

Oh - and another side note Since I just loaded EL - please note that the EL productivity component has zero effect on MKS. This is an artefact of EL adding stuff to my modules.

[phoenix_ca]

I see you rejigged your numbers to be in-line with ExPL. Or at least that's what I gather from your cfg to change the BahaPL parts. If so, yay!

[Vim Razz]

Wow, 0.16 already? You're fast! I'm not even done digesting the changes that came with 0.15 yet, lol. It was a big update.

So... The thoughts and comments here are 0.15 related, as I haven't had time to look at 0.16 yet....

The radial docking adapter is a very welcome addition for more design flexibility. The only problem is that it's hard to tell which end is which. -.-;; Also, if the inner radially-attaching end had a domed or hemispheric face where in clips into the unit it's attached to, it appear more "built in" than it does currently. The current abrupt edges peek through the geometry details of some of your models, leaving the ports looking more "bolted on" than "built in".

On the topic of looking "built in" -- the new airlocks are another great addition that blend very well other design elements, whether radially or stack mounted.

The new lateral lines on the Kerbtrails help a lot in terms of visually breaking up the 'bandiness' when 2 or 3 of them are placed in a line. Thanks!

I must admit I'm a bit sad at what looks to be final demise of the 4-point hub part, but the cageless 6-point hub fills that void suitably in peripheral extensions where the caged hub looks too busy or overbuilt.

There's an odd and inconsistent bug with the displayed size of the Supply Hubs in 0.15 -- the hubs will sometimes appear smaller than they should, with parts mounted to them appearing to float in the air where the edges of the model should be. It doesn't seem to affect gameplay, disappears when the base is re-loaded, and has appeared both in my highly modded and lightly modded MKS test installs.

The Supply Hub looks smaller than it should, and parts mounted to it are "floating" in the air, fitting the proper size of the hub:

After reloading the base (to get rid of nubs lift over by ejected wheels and parachutes), the Supply Hub looks completely normal:

Regarding Energy balance -- The reduction is a big help, but it still seems pretty steep for anywhere but Kerbin with it's 3-hour nights.

For example, as of 0.15 the little base pictured in the spoilered comment above is a sustainable bootstrap start-up on Kerbin if the Construction Hub is run at 150% efficiency, but it falls 6 hours short (~150,000 EC) on batteries for Duna unless you exploit 10,000x or higher warp to keep it running.

I've been trying to develop a balanced mission package including follow-up stages, but it just keeps ballooning due to overnight power requirements. If you wouldn't mind sharing the setup you used for sustained testing (including efficiency rating and kerbal assignments), then that would be very helpful for developing a sense of how things are expected to work together and develop over time. Power consumption is turning out to be the single biggest factor in what mission planning I've done so far.

Oh - and another side note Since I just loaded EL - please note that the EL productivity component has zero effect on MKS. This is an artefact of EL adding stuff to my modules.

Good to know. Thanks! Trying to figure this out is part of the reason I've been harassing you with productivity questions. Edited May 8, 2014 by Vim Razz

[RoverDude]

I see you rejigged your numbers to be in-line with ExPL. Or at least that's what I gather from your cfg to change the BahaPL parts. If so, yay!

Oh - the MKS refinery is still a LOT slower than an EPL smelter, it would have been a pretty large change to too much stuff to change my generation rates at this point. But I will happily support other ore extraction parts

[RoverDude]

The radial docking adapter is a very welcome addition for more design flexibility. The only problem is that it's hard to tell which end is which. -.-;; Also, if the inner radially-attaching end had a domed or hemispheric face where in clips into the unit it's attached to, it appear more "built in" than it does currently. The current abrupt edges peek through the geometry details of some of your models, leaving the ports looking more "bolted on" than "built in".

Will take a gander - The radial port is actually symmetric, so you can use either end, both have nodes. So each end is right. Just need to make sure there's no confusion with the docking port itself which should not be radial (will have to check, I was doing testing at one point).

On the topic of looking "built in" -- the new airlocks are another great addition that blend very well other design elements, whether radially or stack mounted.

hmm.. didn't realize I had an airlock do you mean the Workspace part?

The new lateral lines on the Kerbtrails help a lot in terms of visually breaking up the 'bandiness' when 2 or 3 of them are placed in a line. Thanks!

I must admit I'm a bit sad at what looks to be final demise of the 4-point hub part, but the cageless 6-point hub fills that void suitably in peripheral extensions where the caged hub looks too busy or overbuilt.

Thanks, and yeah I gave it a good try but I now see why nobodly else makes one like this

There's an odd and inconsistent bug with the displayed size of the Supply Hubs in 0.15 -- the hubs will sometimes appear smaller than they should, with parts mounted to them appearing to float in the air where the edges of the model should be. It doesn't seem to affect gameplay, disappears when the base is re-loaded, and has appeared both in my highly modded and lightly modded MKS test installs.

This model did change - it was one of the few that was not sized correctly. Can you try it with a totally clean install of MKS?

Regarding Energy balance -- The reduction is a big help, but it still seems pretty steep for anywhere but Kerbin with it's 3-hour nights.

Interesting - because you should be able to operate on PDUs only. But you will need more than one. I'll post some details later.

[The Destroyer]

Quick question: With this, can I make fully self-sustainable bases with greenhouses? That's the one thing that made me uninstall TAC.

[RoverDude]

Quick question: With this, can I make fully self-sustainable bases with greenhouses? That's the one thing that made me uninstall TAC.

Correct, that is exactly what this will do. But it does make it hard, so MKS is really meant to fill a niche for folks wanting self-sufficient bases but also wanting an end-game activity.

You would generally do MKS in phases

First, drop in construction equipment and move towards replacing the need for ferrying in oxygen/water/food with the need for colony supplies (think wear and tear on equipment). This is about half the mass.

Second would be to build the additional modules (about 10) to fabricate all of your supplies in-situ. Once these are done, the refineries can be ditched because there's also a module to take your recyclables (scrap metal, plastic, etc.) and turn them back into the base materials.

So consider it more of a mod that extends TAC into a colonization system (with a self sufficient closed system as a nice side effect) than just the greenhouse part.

[Javster]

EEEEEERRRRRRRRRRRHHHHHHHHHMMMMMMMMMAAAAAAAHHHHHHHHHHHHHGGGGGGGGGGEEEEEEEEERRRRRRRRRRRDDDDDDDDDDD!!!!!!!

I cannot contain my amazement, as you jut saw.

[smunisto]

RoverDude - how does MKS threat TAC LS if we are using the TACLS units to liters/kg conversion? Will it still work as intended or will this stop me from using MKS?

[crimsonknight3]

Just uploaded a pre-pre release of 0.16 to GitHub. This will be the final version before publish. Balancing is done, just going through some final testing.

Just downloaded to test it out after testing a bug for another mod, just wondering, have you totally changed your file structure? I just downloaded the current dropbox version to compare to the github version and the structures are a LOT more organised on github!! haha, also probably a good idea to tell everyone to deleted their old umbra folder before installation if it has all changed

[Hattivat]

First of all, thank you for this mod, I'm really looking forward to trying it in practice.

Just one question though: I'm planning to kolonize Laythe, and if I calculate it correctly, given that there is an unlimited supply of water and oxygen on Laythe, the one resource that my colony would need to start producing a food surplus (my ultimate goal for this colony) is... carbon dioxide. However absurd that might sound, it seems that my colony is going to have a carbon dioxide deficit. Would you be willing to provide us with some way to either extract carbon dioxide from atmosphere or produce it locally (by burning coal I'd assume, perhaps a conventional power plant/heating center)?

[Vim Razz]

hmm.. didn't realize I had an airlock do you mean the Workspace part?

That'd be the one. I couldn't remember the proper name, though functionally it doesn't seem to have any utility beyond acting as a positionable ingress/egress point to the assembly... hence "airlock" was the best descriptor that came to mind.

Thanks, and yeah I gave it a good try but I now see why nobody else makes one like this

6-point hubs are unavoidably wonky, given the way the game handles connection nodes. You handled the problem as well as anyone could hope for with current game mechanics, imho.

This model did change - it was one of the few that was not sized correctly. Can you try it with a totally clean install of MKS?

If by "clean install", you mean fully delete 0.14 files and start a new save, then the game the screenshots came from already qualifies. I'd rebuilt the base package from scratch with 0.15 parts (rather than transfer the .craft from 0.14) because there were some core changes I wanted to make anyway, and was just doing a test run to make sure I hadn't forgotten any parts/stages/parachute settings/etc for Duna.

Interesting - because you should be able to operate on PDUs only. But you will need more than one. I'll post some details later.

The PDU takes ~50 days or so to come online with basic construction at 150% efficiency, and in the meantime I need 3-5 more PDUs worth of batteries to get through the night without cheating past via warp, so...

I guess what I hope to develop a sense of for the sake of my planing process is: How exactly are PDUs expected to fit within the energy ballance framework? Particularly within the boot-strap, multi-phase development philosophy that permeates the mod.

If PDUs are intended to act as primary energy supplies across the board rather than supplements to solar, then they're completely useless to me, really. With solar being ignored or marginalized, then the battery capacity has no reason to be there (since it's not intended to be used) and in terms of launch mass a NFP or KSPI nuclear reactor+10 years fuel is going to provide much better value than pre-loading a PDU with construction parts (and not penalize overall base efficiency in the process).

Anyway, I've been trying to develop a mission plan for incremental colony development on Duna around the "MKS resources only" (and no relying on warp exploits) concept for the time being, but energy management still just seems ugly from the very initial toe-hold phase onwards... The only two places I can think of where PDUs might possibly be desirable at present are maybe Minmus and Vall....

how does MKS threat TAC LS if we are using the TACLS units to liters/kg conversion? Will it still work as intended or will this stop me from using MKS?

A ModuleManager .cfg file will be needed to convert production outputs and bulk storage quantities of TAC resources to liters/kg -- essentially an expansion of the TAC litters/kg mod, just identifying the MKS parts. Until someone takes the time and interest to write and share one, then the numbers wont line up right.

[smunisto]

A ModuleManager .cfg file will be needed to convert production outputs and bulk storage quantities of TAC resources to liters/kg -- essentially an expansion of the TAC litters/kg mod, just identifying the MKS parts. Until someone takes the time and interest to write and share one, then the numbers wont line up right.

Ah, that's a shame.

I think it just identifies parts with crew capacities with its cfgs right now. I may try to do it by defining specific parts in a new cfg. Otherwise the TAC conversion itself is done via a separate resources cfg.