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

[RoverDude]

Just now, juanml82 said:

So a refueling base may have a mining vessel and a separate converter vessel, but the ships to be refueled must be docked/attached with klaw/connected with KAS pipes to the vessel with the ISRU converter, right? Or can this work without docking/otherwise connecting the converter vessel to the ship to be refueled?

You can transfer from your refueling base to the landed ship via local logistics on your Kolonization dashboard.

[juanml82]

Just now, RoverDude said:

You can transfer from your refueling base to the landed ship via local logistics on your Kolonization dashboard.

But the refueling base would need to have LFO tanks or else the ISRU converter won't work, right?

[RoverDude]

Just now, juanml82 said:

But the refueling base would need to have LFO tanks or else the ISRU converter won't work, right?

Yes.  A vessel with a converter must have local storage for all inputs and outputs.

[voicey99]

11 minutes ago, juanml82 said:

The miner has to have at least one ore tank to mine, even if there are ships with empty ore tanks within a 150m radius, right?

Yep, since you need some storage as a buffer. 60 hours worth of production storage is needed if you don't want to lose any (since LL can only transfer 10% per 6h chunk), and then you will also lose some to the initial catchup chunk.

11 minutes ago, juanml82 said:

Then, an ISRU part in a nearby ship will pull ore from the mine if I set it to convert as long as it has a small empty ore tank where ore can be transferred into.

Stock ISRUs won't, only an MKS Mobile Processing Unit (or other MKS converter for other resources) will. I can write you a small patch to add LL functionality to the stock ISRUs, but they don't trigger LL by default. Again, you will also need 60h worth of miner production on the processor for the same reasons.

11 minutes ago, juanml82 said:

However, a nearby landed ship (within 150m) won't be pulling LOX from the ISRU converter because, even if the converter is converting, the landed ship isn't demanding LOX at the moment (unless I fire one of its engines at a low enough power so the ship doesn't take off), right?

So a refueling base may have a mining vessel and a separate converter vessel, but the ships to be refueled must be docked/attached with klaw/connected with KAS pipes to the vessel with the ISRU converter, right? Or can this work without docking/otherwise connecting the converter vessel to the ship to be refueled?

The MPU will push LFO to the ship as it runs if the LFO output container is full enough and the ship has local-logistics-enabled tanks on it (so just any old MKS tank that can transfer out to normal fuel tanks as it fills). You can also use manual local logistics from the Kolonisation Dashboard to transfer within 150m, which can even transfer to non-MKS tanks.

Edited November 28, 2017 by voicey99
Ninja'd (kinda)

[OmniscientQ]

How feasible would it be to add governor sliders for each bay in a MKS converter? I can add a github issue, but I'd feel embarrassed to ask for it if there were some technical limitation in the way.

EDIT: I just remembered that I had another MKS-related question. Are catch-up conversions still done in 6-hour chunks, meaning any facility should have at least 6 hours of input/output storage in order to maintain full efficiency? I saw a page or so back that someone was recommending 60 hours of storage to allow for local logistics. And do those guidelines apply for electrical storage and distribution? Six hours of battery storage to run a workshop that's sucking down 100 EC/s is not trivial.

Edited November 29, 2017 by OmniscientQ

[voicey99]

8 minutes ago, OmniscientQ said:

EDIT: I just remembered that I had another MKS-related question. Are catch-up conversions still done in 6-hour chunks, meaning any facility should have at least 6 hours of input/output storage in order to maintain full efficiency? I saw a page or so back that someone was recommending 60 hours of storage to allow for local logistics. And do those guidelines apply for electrical storage and distribution? Six hours of battery storage to run a workshop that's sucking down 100 EC/s is not trivial.

Catchup is still done 6h at a time, and that means you actually need 12h of storage as PL only empties to/fills to half full (i.e. it only uses half the container capacity). I recommended 60h for LL, since LL can only transfer 10% of the container volume per catchup cycle. EC is not included in catchup.

[OmniscientQ]

3 hours ago, voicey99 said:

Catchup is still done 6h at a time, and that means you actually need 12h of storage as PL only empties to/fills to half full (i.e. it only uses half the container capacity). I recommended 60h for LL, since LL can only transfer 10% of the container volume per catchup cycle. EC is not included in catchup.

Hm. I guess I haven't honestly paid much attention to the trigger conditions for planetary and local logistics. For example, I usually have one vessel as a dedicated supply depot, with a Pioneer/Logistics module and enough storage units for at least every raw resource, then use local logistics to transfer to other factory vessels. (No need to put a logistics module on every single vessel in a colony.) Is the 10% capacity transferred per LL cycle determined by the source, the target, the larger vessel, or the smaller vessel?

[voicey99]

19 minutes ago, OmniscientQ said:

Is the 10% capacity transferred per LL cycle determined by the source, the target, the larger vessel, or the smaller vessel?

I believe it is determined by the vessel that is initiating the push/pull requests, i.e. the one with the processor on it. LL will only pull resources if it is under 50% capacity and has an MKS processor on the vessel that requires those resources, and will only push resources if it is over 85% capacity and has an MKS processor on the vessel that produces those resources. It doesn't need to be activated to do this, and I can write a patch to add this behaviour to the stock ISRU if needed.

I don't use LL since I have yet to build a decentralised base rather than a single, monolithic structure, so this is what I think is the case from some quick experiments and reading the logistics code.

[OmniscientQ]

7 hours ago, voicey99 said:

I don't use LL since I have yet to build a decentralised base rather than a single, monolithic structure, so this is what I think is the case from some quick experiments and reading the logistics code.

I tried building an all-inclusive monolith that I called the "Omnifactorium". The idea was to have one of everything on it that I could then expand by dropping a standardized colony pod nearby. Each colony pod had a Colonization module, and enough MPU, Agriculture, and Workshop space to boost the output of the Omnifactorium by enough to accomodate another six Kerbals. It... didn't go so well. Honestly, I should learn to use the konstruction ports more.

[Fergrim]

I have a request @RoverDude if you think it might be possible, regarding hiring new kerbal kolonists.

I just feel so cheap when I'm setting every stat number for number in MKS and I was wondering if it'd be possible, too much of a pain, to include the ability to randomize the stats but still choose the class of kolonist.

Choosing the class makes sense since there are too many and you need what you need, but I'd feel way better if the stats were random and I could cherish those times I happened across a bad@$$ Kerbal.

If it's too much trouble, no big

[RoverDude]

8 minutes ago, Fergrim said:

I have a request @RoverDude if you think it might be possible, regarding hiring new kerbal kolonists.

I just feel so cheap when I'm setting every stat number for number in MKS and I was wondering if it'd be possible, too much of a pain, to include the ability to randomize the stats but still choose the class of kolonist.

Choosing the class makes sense since there are too many and you need what you need, but I'd feel way better if the stats were random and I could cherish those times I happened across a bad@$$ Kerbal.

If it's too much trouble, no big

Should be able to do this - you can turn off customization in the config, at which point, everything goes back to randomized.

[Fergrim]

Well that's my issue and to be clear, I'd LOVE to be able to do this stuff on my own.  I'm pretty handy at editing work that's already done, but I sort of draw the line at C#.

I feel terrible asking, but the thing is, I LOVE being able to choose what profession they are and I think that feature is necessary.  It's only the stats of that profession I was hoping to randomize - like courage/stupidity and fearless or not, basically.

That way I both get what I absolutely -need- and get the thrill of gambling all at once

There's a certain beauty to unforeseen circumstances, you end up finding yourself in awesome situations that you'd never have chosen logically

 

Edited November 30, 2017 by Fergrim

[RoverDude]

19 minutes ago, Fergrim said:

Well that's my issue and to be clear, I'd LOVE to be able to do this stuff on my own.  I'm pretty handy at editing work that's already done, but I sort of draw the line at C#.

I feel terrible asking, but the thing is, I LOVE being able to choose what profession they are and I think that feature is necessary.  It's only the stats of that profession I was hoping to randomize - like courage/stupidity and fearless or not, basically.

That way I both get what I absolutely -need- and get the thrill of gambling all at once

There's a certain beauty to unforeseen circumstances, you end up finding yourself in awesome situations that you'd never have chosen logically

 

Please re-read my answer...  it already allows you to suppress stat randomization, you still pick the class.

[Fergrim]

I'm sorry bud, I'm an insomniac, and not the kind that gets a lot done, but the kind that just becomes zombie-like until "oh i think i hear birds. crap"  But I see now, yes, when you said everything I thought it meant what classes were offered too. Awesome I'm going to run and dig in to those files now then

Thank you very much :DD  I seriously can't tell you how much I appreciate your work, I know it takes serious time and your mods singlehandedly exponentially improve the fun factor of a game that was already great.

Edited November 30, 2017 by Fergrim

[aconfusedkerbal]

hey, whenever i try to deploy the hab ring or any inflatable module it does nothing, the option doesnt exist! yet in the VAB it works fine, ive got all the specialised parts, material kits and EC as well. Suggestions?

 

[voicey99]

46 minutes ago, aconfusedkerbal said:

hey, whenever i try to deploy the hab ring or any inflatable module it does nothing, the option doesn't exist! yet in the VAB it works fine, I've got all the specialised parts, material kits and EC as well. Suggestions?

Are you doing it from EVA (which you have to IIRC)?

[aconfusedkerbal]

17 minutes ago, voicey99 said:

Are you doing it from EVA (which you have to IIRC)?

no, thanks i really appreciate it

[voicey99]

1 hour ago, aconfusedkerbal said:

no, thanks i really appreciate it

Could you share a screenshot of what you're trying to do?

[RoverDude]

Discussion time

So was talking to @DoktorKrogg in USI chat about the wear mechanic.

Currently, machinery has a direct impact on efficiency, but is also consumed.  It is then later replenished by maintenance.  The downside is that this gives converters a long tail of diminishing performance that makes making simple base conversion calculations challenging.

The idea we're noodling is to remove machinery consumption so that machinery becomes a mass-offset tool.  This makes making things like hab modules a lot easer to balance between USI-LS (which has no machinery concept) and MKS.

To simulate wear, we'd switch to a part-failure mechanic, where the longer a module is in use, the greater the chance of it outright failing.  This can be reset through regular maintenance (and would consume a resource), or could be done automatically with a manned workshop (we'd assume the engineers in question would be running about fixing things).  Or, could be turned off completely (similar to how wear can be turned off today).  Naturally, if you let things go so far bad that the module actually fails, the repair cost would be steeper (i.e. it would remove a bunch of your machinery).

Thoughts?

[voicey99]

Would parts fail during catchup i.e. it would simulate a backlog of maintenance and apply a failure chance every catchup tick?

Also, I think a good idea would be that maintenance checks would consume a fixed amount of machinery, and you would be able to specify the time interval between them so you could keep them pristine for more resource cost and have a very low (but nonzero) failure rate, or be cheap and skimp on maintenance but run an exponentially (not to steep, though) increasing risk of failure the longer you leave them.

Edited December 1, 2017 by voicey99

[LameLefty]

6 minutes ago, RoverDude said:

Discussion time

So was talking to @DoktorKrogg in USI chat about the wear mechanic.

Currently, machinery has a direct impact on efficiency, but is also consumed.  It is then later replenished by maintenance.  The downside is that this gives converters a long tail of diminishing performance that makes making simple base conversion calculations challenging.

The idea we're noodling is to remove machinery consumption so that machinery becomes a mass-offset tool.  This makes making things like hab modules a lot easer to balance between USI-LS (which has no machinery concept) and MKS.

To simulate wear, we'd switch to a part-failure mechanic, where the longer a module is in use, the greater the chance of it outright failing.  This can be reset through regular maintenance (and would consume a resource), or could be done automatically with a manned workshop (we'd assume the engineers in question would be running about fixing things).  Or, could be turned off completely (similar to how wear can be turned off today).  Naturally, if you let things go so far bad that the module actually fails, the repair cost would be steeper (i.e. it would remove a bunch of your machinery).

Thoughts?

I think that's a fantastic gameplay mechanism and it's a simple concept that would make sense intuitively to most people right off hand.

[RoverDude]

35 minutes ago, voicey99 said:

Would parts fail during catchup i.e. it would simulate a backlog of maintenance and apply a failure chance every catchup tick?

Yep, there would be cumulative checks... so if you abandoned a vessel with operational converters and came back a hundred years later, it would have failed at some point in the intervening time.

[voicey99]

14 minutes ago, RoverDude said:

Yep, there would be cumulative checks... so if you abandoned a vessel with operational converters and came back a hundred years later, it would have failed at some point in the intervening time.

And as far as specifying maintenance interval goes (I edited that post), it would be great to see something like that as well, since small bases yet to establish themselves might need to scale back on the maintenance to save resources, but also while risking breakdowns as the tradeoff. Some converters might be able to go longer without intervention than others (MPUs should last decades to keep their unmanned advantage), meaning they might not all need to be serviced at one cosmically fixed interval (scheduling maintenance intervals for each processing part maybe, or is that too complex?).

[RoverDude]

Would be a bit of a bear to balance, and maybe a bit much for the first phase - I'd need to figure out how to balance the parts accordingly.

[Brigadier]

4 hours ago, RoverDude said:

Yep, there would be cumulative checks... so if you abandoned a vessel with operational converters and came back a hundred years later, it would have failed at some point in the intervening time.

Would this prevent the player from using long periods in timewarp to, say, get that probe to the far ends of the system, without suffering multiple failures over time in any stations/bases?  It sounds as if it's either the wear mechanic or timewarp.