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

[goldenpsp]

@Lancezh Yes the MKS mod is big and complex.  Keep in mind the documentation is 100% a community driven project.  Since the beginnings of this mod the only way "I" have figured it out, is by testing.  Every time I come back to KSP after an extended absence I setup the various parts on the KSC to test how everything works.  I use Hyperedit to fill tanks to simulate drilling (since resources are so small in kerbin) and between that testing, the documentation, and a little time I can wrap my head around the mechanics again.

[Lancezh]

3 minutes ago, goldenpsp said:

@Lancezh Yes the MKS mod is big and complex.  Keep in mind the documentation is 100% a community driven project.  Since the beginnings of this mod the only way "I" have figured it out, is by testing.  Every time I come back to KSP after an extended absence I setup the various parts on the KSC to test how everything works.  I use Hyperedit to fill tanks to simulate drilling (since resources are so small in kerbin) and between that testing, the documentation, and a little time I can wrap my head around the mechanics again.

Yeah maybe i'm stupid for not using hyperedit, i dont know.

[Gilph]

Have often considered to do a "MKS for Dummies" like section, but it's hard because the USI suite is very flexible and I've noticed that very few people approach it the same way. To restrict people's imagination by giving the impression there is a limited way to use it would not be very helpful. You have to ask yourself why you are interested in using MKS in the first place and go from there. Here are some things to consider:

1. MKS is designed to build colonies consisting of individual bases (vessels) and provides the capability to manufacture resources to keep Kerbals alive when life support is enabled.
2. Life support can be enabled by USI-LS. Don't try to use other LS systems in the beginning.
3. All aspects of life support can be turned on or off, made easier or harder, etc. Configure it the way you want.
4. MKS without any LS becomes a construction exercise, similar to other base building mods.  Other USI mods support advanced construction if that's your goal.
5. The best part of MKS is that, by following some rules listed in the wiki, you do not need to interconnect your bases to share/transfer resources (with very rare exceptions). This is to prevent the physics engine from getting too stressed out and causing large designs to shake, jump, and explode. Many people interconnect them anyway and take the risk.

Once all these things get sorted, then use the wiki for the more detailed kinds of things to know (like when is a greenhouse not a greenhouse).

[RoverDude]

A couple of thoughts as well.

The overall system is pretty darn stable - i.e. there are no major changes to existing systems planned, only additions of parts/mechanics as needed (the exception being planetary logistics but that will be part of a larger feature set).

So any assistance on wiki / documentation / vids / etc. is always appreciated.  And there are tons of helpful folks here to answer questions.

[voicey99]

...Could someone explain the balance sheet to me? I'm overhauling the SXT patch I wrote to be more in line with it, but all I see is a wall of numbers and abbreviations 

[DStaal]

3 minutes ago, voicey99 said:

...Could someone explain the balance sheet to me? I'm overhauling the SXT patch I wrote to be more in line with it, but all I see is a wall of numbers and abbreviations 

Best just to watch the video:

 

[damerell]

7 hours ago, RoverDude said:

Running anything in a tight loop (i.e. 50 times per second) stacks.  It is simply NOT performant.

There's a bit of a false dichotomy here between a 50Hz clock and catch-up processing.

[ShotgunNinja]

FYI: Kerbalism run at about 300 microseconds per simulation step on a single AMD Athlon X4 core, and this include all mechanics.

[joacobanfield]

Am I supposed to be able to "Disassemble" kerbals?

[RoverDude]

13 minutes ago, damerell said:

There's a bit of a false dichotomy here between a 50Hz clock and catch-up processing.

And I am not referring to a 50hz clock.  In KSP, FixedUpdate runs (by default) 50 times per second.  And a lot of stuff happens in that timeframe.  Putting a lot of stuff there kills performance.

 

2 minutes ago, ShotgunNinja said:

FYI: Kerbalism run at about 300 microseconds per simulation step on a single AMD Athlon X4 core, and this include all mechanics.

Last I checked, Kerbalism did not replicate all of the stock functions such as thermal (which affects thermal efficiency), depletion nodes, required resources, and probably a few others I brought up back in the day that MKS leverages.  This is what causes a fundamental lack of compatibility. 

 

[DStaal]

8 minutes ago, damerell said:

There's a bit of a false dichotomy here between a 50Hz clock and catch-up processing.

How so?  We were comparing background processing (which presumably would be every frame) and catch-up processing, which is currently when you switch to the ship.  Note that catch-up processing simplifies things by doing large batches - basically multiplying the per-second processing by some amount and doing that calculation instead.  Background couldn't really do that and be real background processing, as batching things up would negate it's advantages.  (Though you could probably get by with doing once a second or something, as semi-background processing, and keep most of them.)

Even a moderately-sized USI base coming into range for me can cause catch-up delays in the ~30 second range, if not more, so grouping them up isn't going to be a panecia, it just mitigates some.

3 minutes ago, ShotgunNinja said:

FYI: Kerbalism run at about 300 microseconds per simulation step on a single AMD Athlon X4 core, and this include all mechanics.

Obviously not *all* mechanics, or we wouldn't be having this discussion.    (If it simulated all the mechanics correctly, there shouldn't be any compatibility issues, I would think.)

4 minutes ago, joacobanfield said:

Am I supposed to be able to "Disassemble" kerbals?

No - but are you sure that's this mod?  I think Pathfinder was looking into something on those lines recently...

[RoverDude]

5 minutes ago, joacobanfield said:

Am I supposed to be able to "Disassemble" kerbals?

I am pretty sure that was sorted in a recent patch

 

If anything... one would think you could disassemble a Kerbal into supplies.

[voicey99]

28 minutes ago, DStaal said:

Best just to watch the video:

<schnip>

Hm. If me running the numbers is correct the PPD-12 is unbalanced for what it provides (it should apparently use 5.25ec/s and weigh 3.025t to get what it does). I based most of my configs on how the modules compare up to the PPD-12 so if this is the case then that's a problem-or am I doing this wrong?

 

7 minutes ago, joacobanfield said:

Am I supposed to be able to "Disassemble" kerbals?

You're behind on the versions, that 'bug' was fixed three months ago in v0.50.15.

Edited May 11, 2017 by voicey99

[RoverDude]

Just now, voicey99 said:

Hm. If me running the numbers is correct the PPD-12 is unbalanced for what it provides (it should apparently use 5.25ec/s and weigh 3.025t to get what it does). Or am I doing this wrong?

I can double check that (log an issue as a reminder).

EC was changed recently and EC cost for hab reduced.  I vaguely recall that the HH was a bit weird in that it's mass/volume was really out of whack

[voicey99]

Just now, RoverDude said:

I can double check that (log an issue as a reminder).

EC was changed recently and EC cost for hab reduced.  I vaguely recall that the HH was a bit weird in that it's mass/volume was really out of whack

Are you saying the balance sheet is out of date? Given it still had the notes from your tutorial video on it and was created in June last year, I think it might not have been touched for some time.

[RoverDude]

Just now, voicey99 said:

Are you saying the balance sheet is out of date? Given it still had the notes from your tutorial video on it and was created in June last year, I think it might not have been touched for some time.

It *should* be current, but I would need to double check it (or of someone beats it to me, run a Tundra hab through it as a test).  

[ShotgunNinja]

2 minutes ago, RoverDude said:

Last I checked, Kerbalism did not replicate all of the stock functions such as thermal (which affects thermal efficiency), depletion nodes, required resources, and probably a few others I brought up back in the day that MKS leverages.  This is what causes a fundamental lack of compatibility

The stock thermal system is still not emulated for unloaded vessels, and is unlikely it ever will. The relations between inputs and outpus is fully supported (eg: inputs depending on output capacity left, and outputs depending on input amount, at the same time) is fully supported. I never got the point of non-mandatory inputs, so I just assume all inputs to be required. Never eard of depletion nodes (I assume they are part of the internal stock machinery for resources).

I forgot to mention in the previous reply that the computation is agnostic on the number of vessels, O(1). One vessel is processed for each simulation step. Scaling number of vessels only result in a delay in updating the vessel data in my own caches, but the cost per-step stay the same. Inter-relations between vessels (eg: communication network) is also amortized so in the end it average to O(1).

 

7 minutes ago, DStaal said:

Obviously not *all* mechanics, or we wouldn't be having this discussion.    (If it simulated all the mechanics correctly, there shouldn't be any compatibility issues, I would think.)

I was referring to the mechanics introduced by the mod. The only stock mechanic that is emulated for unloaded vessels is resource consumption/production. Recently I had to replace stock panel output calculations for loaded vessels too, to fix the issues at extreme timewarp speed.

 

[RoverDude]

16 minutes ago, ShotgunNinja said:

The relations between inputs and outpus is fully supported (eg: inputs depending on output capacity left, and outputs depending on input amount, at the same time) is fully supported

Required resources, Efficiency Bonuses, and Specialty effects (which have a significant impact, whether the vessel is in the foreground or not)?  What about ground contact and drill orientation detection for harvesters?  

To be clear.  There are a lot of ways to skin a cat, based on your goals.  And if Kerbalism works in the 99% case, and trades performance for that 1%, then all the more power to you.  But it does make it fundamentally incompatible with MKS (or any mod that leverages missing features).

Stock trades some sleight of hand for feature depth.  The new (MKS) logistics system being worked has different tradeoffs.  But regardless, there is no such a thing as a free lunch.

And one of the prices you pay (to wrap a bow on the genesis of this topic) is performance.  Maintaining the entire breadth of stock offerings without batching and with unloaded vessels would start causing hitches.  And would amplify as your vessel count and bases (loaded/unloaded) got larger.  So you either do sleight of hand and discount unloaded vessels (stock does this), or you cut features (Kerbalism does this).

16 minutes ago, ShotgunNinja said:

The only stock mechanic that is emulated for unloaded vessels is resource consumption/production

Which, as you have probably seen by now, is a pretty deep feature that includes a lot more than just inputs and outputs   

@voicey99 - fixed now.  The sheet did not reflect the 90% EC cost reduction for habs.  @DStaal you probably want to check that one too.  It came as a result of feedback that not everyone has nuclear reactors and there were a lot of Kerbals freezing to death in USI-LS saves

Edited May 11, 2017 by RoverDude

[ShotgunNinja]

3 minutes ago, RoverDude said:

Required resources, Efficiency Bonuses, and Specialty effects (which have a significant impact, whether the vessel is in the foreground or not)?  What about ground contact and drill orientation detection for harvesters?

The equation for trait/experience based bonus was fixed by a contributor recently, it is now equivalent to the stock one. The drill head collision with the ground is evaluated when the vessel is loaded, then its state re-used when it is unloaded (as the vessel has to be landed and can't change lat/long in that case).

 

I agree with what you say in general. Stock has different constrains, so different solutions were designed. None is 'right' in absolute term, just 'right' for the job required.

[RoverDude]

Yep, and in this case, (100%) mod/stock compatibility was not a job Kerbalism took on.  Nothing wrong with that, just the reality of things.

Edited May 11, 2017 by RoverDude

[ShotgunNinja]

@RoverDude Man I wasted a lot of time then! I made it fully modular so people can keep using older mods for love or inertia or both. I am emulating all stock and the most used non-stock modules in background (to an acceptable degree for most mods). And I am maintaining compatibility patches for 36 different mods at the moment. Every time I design something new, usually 80% of the work goes into keeping other mods working. So your last comment was a bit unfair.

[RoverDude]

@ShotgunNinja - With all due respect (and to be clear... this is the MKS thread not the Kerbalism thread).  I warned you ages ago when I noticed just how much of core stock functionality was missing.  And while Kerbalism may work to an acceptable degree for many mods (though not many would have gameplay changes where background activities were a fundamental part of the process), it has never worked with MKS (and probably some other USI mods based on what's missing)... this has been known since day one.  It has nothing to do with fairness, it is simply the reality of things. 

As you say, there is no absolute 'right', merely 'right' for the job.  And 100% compatibility with stock (and mods that leverage stock) is demonstrably something that Kerbalism does not do.  For most people, the 99% case is fine (as I noted earlier).  For MKS users (and again, this is the MKS thread), it is fundamentally breaking.  

Edited May 11, 2017 by RoverDude

[ShotgunNinja]

@RoverDude It wasn't my intention to derail this thread. I was pinged and clarified a misconception about performance with a one-liner. Then I merely replied to questions. Feel free to delete any posts that doesn't belong here.

[damerell]

3 hours ago, RoverDude said:

And I am not referring to a 50hz clock.  In KSP, FixedUpdate runs (by default) 50 times per second.

50 times per second _is_ a 50Hz clock, so I'm not quite clear what you mean. If running converters on that clock is really prohibitive (and while I recognise you know a lot more about this, it does on the face of it seem remarkable that the simple arithmetic that converters do can occupy more than a miniscule fraction of the CPU cycles available every 1/50 second, and that seems to be the import of @ShotgunNinja's comments) then doing background updates once a second or once every ten seconds or whatever (obviously avoiding the naive implementation that does it for every part on the same tick) should sort that out.

[RoverDude]

@damerell - running a lot of converters for a lot of unloaded vessels is prohibitive.  Running a bunch of them for what you have in physics range is fine.  Batching has it's own issues/constraints.  But there's a lot more going on than just doing a bit of math.  You're also checking and consuming resources, dumping thermal heat, and other things that have to work with fuel flow, the resource graph, the thermal model, etc. (and a lot of stuff in MKS already does things in small-scale batches for perf reasons - i.e. logistics only checking every 5 seconds, for example).  

 

And sorry, running FixedUpdate every 0.02 seconds may be the same rate as a 50hz clock, but it is not the same thing.

 

 

 

Edited May 11, 2017 by RoverDude