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

[voicey99]

1 minute ago, Wyzard said:

I was under the impression that the automated MPUs already held more machinery than needed for full efficiency, so they could run at 100% for quite awhile before starting to degrade.  But looking at the part configs now, it seems that's not the case — e.g. for the 2.5m MPU, all the converters have REQUIRED_RESOURCE blocks that say 650 machinery is needed, and that's also the limit of how much the part is able to hold.  So I'm confused.

I think the REQUIRED_RESOURCE tab gives how much machinery the amount in the part will be compared to e.g. if the RR is 100 and you have 70 you will get a multiplier of 0.7 (it might go above 1 in this way as well). MPUs will degrade from the start, but they use machinery a lot slower than other parts.

6 minutes ago, Wyzard said:

Anyway, I like gradual degradation better than abrupt failure.  Automated refineries are things that you generally don't need to visit very often, and — assuming you'd only learn that a part has failed when you load the vessel it's on — I wouldn't want to open an auto driller expecting to let it catch up on production and push lots of stuff to PL, only to discover that it broke months ago and has been sitting idle ever since.  Gradual degradation is at least predictable, and you can decide how much loss of efficiency you're willing to put up with, vs. how often you send an engineer to do maintenance.  But it'd be good for automated parts to have some built-in redundancy in the form of extra machinery capacity (as I thought the MPUs already did).

(For parts intended to be used on crewed bases, it probably doesn't matter much since one can expect there'll always be an engineer around to do maintenance and fix things promptly when they break.  I'm more concerned with unmanned, automated things.)

I find the current machinery requirement too predictable, and it doesn't allow for any actual bad things to happen. Actual failures would make you incorporate redundant systems into your base and keep you on your toes (although I agree it should notify you straightaway to avoid an incredibly frustrating situation) - for  example, you could find out the agrimodule that supplies your small science outpost has failed, you would need to send out an engineer to fix it before they starve, but you could also incorporate a spare machine to keep things going until you can fix the original. If this mechanic were to be on a per-bay basis, the larger machines would already have redundancy in the form of other bays and would only take a production hit rather than outright failure, though I would also support the inclusion of a special optional bay into all processing parts that is a designated backup, so you could reserve a portion of the part's processing capacity so when a bay fails the backup would kick in to keep production going at whatever portion of the original part capacity you reserved for it until you can fix the original.

30 minutes ago, Wyzard said:

On the other hand, abrupt failure could work well if the player is notified immediately when a failure happens, even when the vessel isn't loaded — similar to how Ground Construction notifies you when a construction job has finished.  (I know KSP doesn't process parts on vessels that aren't loaded, but this could probably be accomplished by having the loaded part part decide how far in the future it'll fail, and saving that number outside the vessel to be tracked separately, similar to what Kerbal Alarm Clock does.  I believe a binomial distribution can be used to decide when the next failure will occur, as a random length of time based on the part's per-second probability of failure.)

A set failure date could be hard to pin down if the failure chance relies on load - time is one thing, but load is dynamic according to planetary bonuses and changes constantly. Maybe it could calculate it based on the current rate of increase - crude, but much simpler to do. Calculating the failure date every time a part is switched on could cause the game to hang on activating the thing, and dynamically calculating it every time interval (hourly?) could cause timewarp lag or a spike on the interval, every interva, though it remains to be seen exactly how hardware-intensive this would be. It looks like a binomial distribution (i.e. coin-flip every interval) is going to be what is used, though the formula for determining the failure chance and the time interval has not been settled upon.

38 minutes ago, Wyzard said:

BTW, I've always thought it's a little weird that drills don't degrade — really, they ought to suffer more wear & tear than anything.  The stock drills don't have a wear&tear mechanic and I guess that sets a precedent, but I wouldn't mind if MKS were to add a machinery requirement to all drills (including the stock ones).

If MKS added a machinery requirement to stock drills, this could be seen as intruding on the stock gameplay and falling outside of MKS' scope as a mod. I would't mind either, but then the ISRU would have to have machinery as well and there could be complaints. In addition, I think the drills would be better off having gradually degrading performance over outright failures, since drills would become blunted and worn well before the driving mechanism could break, and having both mechanics on a single part would be nasty.

[jd284]

46 minutes ago, voicey99 said:

I find the current machinery requirement too predictable, and it doesn't allow for any actual bad things to happen.

In my opinion, that shouldn't be the job of MKS. There are plenty of mods that add interesting failure modes, and I don't think MKS needs to reinvent that wheel.

The main problem I have with adding failure possibility is that it doesn't really work very well with KSP's (non-existent) model of background processing. If a failure happens, and I can't immediately react to have it taken care of, it's a bad design. So basically, failures should not ever happen during catch-up of background processing, only at the end of it. I don't want to come back to a colony after several months only to find that it failed and nobody told me. Nor do I want to visit every colony every day just in case.

Personally I like the  way machinery works, perhaps it's just a bit too "smooth" though. Maybe making it operate in steps would work better? Instead of linearly scaling throughput with amount of machinery, you could have steps of 25% and each time machinery falls by a quarter, throughput reduces by another 25% step. Like having multiple machines inside, and each time one of them fails.

[voicey99]

Is the general opinion here that people don't like this change? I feel like I'm on my own in supporting it.

Quick opinion poll here.

[Wyzard]

Some other ideas that come to mind:

• Make the machinery consumption rate vary randomly, instead of being a constant.  You know how long a part can be expected to last on average, but it might wear out more quickly, or it might last longer.
• Keep machinery-based gradual degradation, but add abrupt failure with a chance that increases as machinery goes down.  A part with 99% of its expected machinery is very unlikely to fail (though it's still possible), but one running at 5% machinery is not only very inefficient, it's also likely to die at any moment.  Failures aren't entirely predictable but at least you can get a sense of how much risk there is.
• Instead of having mechanical parts actually contain machinery as a resource, have the required resource be something invisible, sort of like the Construction resource used by MKS inflatables.  The "perform maintenance" command consumes machinery from warehouses and replenishes the invisible resource (similar to inflatables with MaterialKits) to restore the part's efficiency.  The idea is that you can't repair a worn-out machine just by pumping machinery into it with a resource transfer — you can transfer machinery between warehouses that way, but it takes an engineer to actually install the machinery into the part that needs it.

Edited December 2, 2017 by Wyzard

[Nergal8617]

47 minutes ago, Wyzard said:

• Make the machinery consumption rate vary randomly, instead of being a constant.  You know how long a part can be expected to last on average, but it might wear out more quickly, or it might last longer.
• Keep machinery-based gradual degradation, but add abrupt failure with a chance that increases as machinery goes down.  A part with 99% of its expected machinery is very unlikely to fail (though it's still possible), but one running at 5% machinery is not only very inefficient, it's also likely to die at any moment.  Failures aren't entirely predictable but at least you can get a sense of how much risk there is.

Interesting ideas, but not something I would want to deal with.  I'm fine with parts breaking at random, it gives you a challenge to overcome and a reason to design redundancy into your bases, but the whole reason I turn off the current wear mechanic is because I don't like having the output of my converters vary as they consume machinery.

[voicey99]

11 minutes ago, Nergal8617 said:

Interesting ideas, but not something I would want to deal with.  I'm fine with parts breaking at random, it gives you a challenge to overcome and a reason to design redundancy into your bases, but the whole reason I turn off the current wear mechanic is because I don't like having the output of my converters vary as they consume machinery.

This combination of the two also just means you have to deal with both machinery and breakdowns, so you just have both systems to deal with.

[RoverDude]

Remember, gang - the whole point is to make conversion rates more predictable, not less   

[Wyzard]

18 minutes ago, RoverDude said:

Remember, gang - the whole point is to make conversion rates more predictable, not less   

Hmm.  I didn't get that from your original post on the topic ­— you said the idea was that "the longer a module is in use, the greater the chance of it outright failing", which sounds like adding a random factor.  Currently, conversion rate is predictable since it's fully deterministic.  It may be inconvenient to calculate, but anything involving a random factor would be non-deterministic and therefore impossible to predict.  (Or am I misunderstanding what you meant?)

Maybe just make converters run at full efficiency until the machinery runs out?

[RoverDude]

The long tail makes things really hard to predict - it is one of those complaints.

The current design I am looking at is to have machinery non-consumed (but remain a required resource).  And introduce, an alternate wear mechanic that is replenished at the exact same rate machinery wears today.  So the only time you're risking your stuff breaking down is if you choose to not do maintence.  There would also be a floor, so you would not have stuff failing immediately just because of bad luck.  But there would be a threshold (likely configurable) after which, if maintenance is not performed, you have an ever increasing chance of stuff going south.

[Nergal8617]

12 minutes ago, RoverDude said:

The current design I am looking at is to have machinery non-consumed (but remain a required resource).  And introduce, an alternate wear mechanic that is replenished at the exact same rate machinery wears today.  So the only time you're risking your stuff breaking down is if you choose to not do maintence.  There would also be a floor, so you would not have stuff failing immediately just because of bad luck.  But there would be a threshold (likely configurable) after which, if maintenance is not performed, you have an ever increasing chance of stuff going south.

I like this design, this would cause me to turn the wear mechanic back on.

[Fergrim]

Also guys, dangit does a good job of this as does the system included with BARIS though i don't know how modular BARIS' system is and if it's compatible with USI.  I know from experience that dangit is compatible with USI np.  Drills are definitely included in it giving things both a lifetime and a mean time between failures.  It is a fairly lightweight mod overall also.

And just to weigh in on a general principle, I'm a way bigger fan of unpredictability over predictability.  The more predictable something is, the more it risks feeling like a spreadsheet with a GUI.  The X series of games fell into this trap despite having a variety of long production chains.  Things were so predictable, the moment you got yourself set up, you could simply leave the game run and accumulate untold riches.

@RoverDude I had a quick question for you regarding the liquid/ox version of your karbonite engine.  The one with 3000kn thrust.  I'm just wondering how I should be using it, or having it fit in balance wise in my career playthrough.  Atm it's the most powerful engine I have access to by about triple and I guess I figured hearing it from the horses mouth would help me decide how to feel about it.  What gap/role is it meant to fill?

Edited December 3, 2017 by Fergrim

[Nergal8617]

1 hour ago, Fergrim said:

Also guys, dangit does a good job of this as does the system included with BARIS though i don't know how modular BARIS' system is and if it's compatible with USI.  I know from experience that dangit is compatible with USI np.  Drills are definitely included in it giving things both a lifetime and a mean time between failures.  It is a fairly lightweight mod overall also.

I might have to look into what dangit actually does (I've never read up on it) but I know BARIS comes with some other mechanics in addition to the part failure that I personally don't want.  In all honesty I'd rather see a revamp of the current wear mechanic along the lines RoverDude mentioned a couple of posts ago than add another mod to my list.

[voicey99]

12 hours ago, RoverDude said:

And introduce an alternate wear mechanic that is replenished at the exact same rate machinery wears today.  So the only time you're risking your stuff breaking down is if you choose to not do maintenance.  There would also be a floor, so you would not have stuff failing immediately just because of bad luck.  But there would be a threshold (likely configurable) after which, if maintenance is not performed, you have an ever increasing chance of stuff going south.

I don't really understand that statement. Are you saying maintenance grants immunity to breakdowns for a short while, after which they become a thing and start to increase? And what is this floor?

I think there should still be a chance for well-maintained modules to break down, but a very low one on the order of a percent or so per year, which would not be enough to be a significant issue but nonetheless make you keep it as a consideration.

[BRAAAP_STUTUTU]

So, what's the point of using the kerbals with the MKS specefic jobs when the pilot/engineer/scientists can do effectivily the same but are more versatile?

[voicey99]

1 minute ago, BRAAAP_STUTUTU said:

So, what's the point of using the kerbals with the MKS specefic jobs when the pilot/engineer/scientists can do effectivily the same but are more versatile?

They're cheaper (possibly bugged right now), so you can fill out your bases with cheap filler kerbals, since you might only need a few of the engineer traits so you include a few of the relevant kerbals for less money where space and supporting them isn't an issue. Having more kerbals also makes your bases feel more lived-in and gains you rating points and rewards faster.

[BRAAAP_STUTUTU]

Just now, voicey99 said:

They're cheaper (possibly bugged right now), so you can fill out your bases with cheap filler kerbals, since you might only need a few of the engineer traits so you include a few of the relevant kerbals for less money where space and supporting them isn't an issue. Having more kerbals also makes your bases feel more lived-in and gains you rating points and rewards faster.

If they are only cheaper, well i guess, but i still have to pay the same amount for them as the main jobs, which is bugged i guess?

[voicey99]

1 minute ago, BRAAAP_STUTUTU said:

If they are only cheaper, well i guess, but i still have to pay the same amount for them as the main jobs, which is bugged i guess?

Yeah, they should be muuuch cheaper than the primary kerbals. The bug has persistent through several versions, but a fix is coming in the next release (whenever that is).

[Rocketmanreturns]

Again, my thanks to Roverdude and all those who help to keep this fantastic mod alive.  Now down to business.

My Kerbals have been in DeepFreeze (mod) for several Kerbal months.   I ran out of electricity and D.F. put them in a coma state (per my settings).  After they woke up I got a message that they could return to work but they were all tourist.  I immediately put three of them (and a L3 scientist) in a fully supplied 3.75 Medbay and sent the rest back to Kerbin (they were orbiting Kerbin and they were not tourist for more than a Kerbal hour or two).  That was about one or two Kerbal weeks ago and they are all still tourists.  Note also that they can EVA.

My questions are:

1.      Is this the Permanent Tourist bug (I have 1.2.2)?

•  If it is, I know how to edit the persistence file or I can use Ship Manifest to edit them back.
•  If it is, is there a patch for 1.2.2?

2.      Why were my kerbals turned into tourists after waking from DeepFreeze?

3.      How long does it take for a “tourist” to heal while back on Kerbin?

4.      Is there any formula that gives a player some idea of Medbay heal times?

I have:

KSP - 1.2.2 - Career mode (but I am not running contracts)

USI MKS - 0.51.0

USI LS - 0.5.25

DeepFreeze - V0.32.4.0

I am heavily mod’d but these seem to the important ones.

 

Thanks for your help.

[voicey99]

7 minutes ago, Rocketmanreturns said:

1.      Is this the Permanent Tourist bug (I have 1.2.2)?

•  If it is, I know how to edit the persistence file or I can use Ship Manifest to edit them back.
•  If it is, is there a patch for 1.2.2?

It's not the permatourist bug, that was with tourist kerbals being recovered at KSC and appearing in the AC as tourists (see 3). If they can EVA, they are not tourists - the skill label in their portrait does not update after they change state, you will have to reload the vessel to see it.

11 minutes ago, Rocketmanreturns said:

2.      Why were my kerbals turned into tourists after waking from DeepFreeze?

It probably touristified them during timewarp since they ran out of EC, but detouristified them after the ship updated when it loaded.

13 minutes ago, Rocketmanreturns said:

3.      How long does it take for a “tourist” to heal while back on Kerbin?

Do you mean in the AC? They don't - they are supposed to be detouristified when they pass below 25km (?) on Kerbin, and if they don't and you recover them as tourists then it is the bug. Find their STATUS_DATA listing and change their OldTrait to whatever it was before, and do the same with their trait in their KERBAL listing. This fixes them.

15 minutes ago, Rocketmanreturns said:

4.      Is there any formula that gives a player some idea of Medbay heal times?

(no clue, sorry)

[RoverDude]

7 hours ago, Nergal8617 said:

In all honesty I'd rather see a revamp of the current wear mechanic along the lines RoverDude mentioned a couple of posts ago than add another mod to my list.

This.  Also the bit that I can achieve better integration and less friction with dependencies (like when modders stop updating stuff or run late) by integrating what I consider core mechanics.

 

4 hours ago, voicey99 said:

I don't really understand that statement. Are you saying maintenance grants immunity to breakdowns for a short while, after which they become a thing and start to increase? And what is this floor?

There will be a threshold where if you want to spend enough parts, you can effectively have your base in a constant maintenance mode where outright failure simply won't happen (remembering that these things will of course be configurable), vs. skimping on maintenance but taking a risk that something might break down on you.  Likely implemented as a sliding window of some sort with both upper and lower bounds configurable.

@Rocketmanreturns - lots of changes between the 1.2.2 version of USI mods and 1.3.x - you may very well be dealing with something that has been fixed in the past.

[voicey99]

2 minutes ago, RoverDude said:

There will be a threshold where if you want to spend enough parts, you can effectively have your base in a constant maintenance mode where outright failure simply won't happen (remembering that these things will of course be configurable), vs. skimping on maintenance but taking a risk that something might break down on you.  Likely implemented as a sliding window of some sort with both upper and lower bounds configurable.

So this means i will use a constant stream of parts in exchange for immunity to breakdowns? That seems fair, though there should be a tradeoff of some description e.g. it would reduce breakdowns to a tiny but nonzero chance (to where they will be very rare, but still happen) or the parts cost would be prohibitively expensive for any base that does not have parts production set up (replacing a part as soon as it shows the slightest sign of damage is going to eat a lot of spares vs only replacing it when it actually starts to fail).

[RoverDude]

Probably more along the lines of 'Your base, fresh out of the box, is going to be fine for X years/months/whatever, but if you want to keep using it, either ship in a decent stockpile of spare parts and the people to install/maintain everything, or risk things slowly breaking down'.

 

EDIT

And by slowly breaking down, I do not mean a reduction in efficiency like we have today, but something more binary, like modules shutting down till repaired, hence a need for either maintenance or redundancy (i.e. having two recyclers in case one breaks down on year ten).

Edited December 3, 2017 by RoverDude

[voicey99]

17 minutes ago, RoverDude said:

Probably more along the lines of 'Your base, fresh out of the box, is going to be fine for X years/months/whatever, but if you want to keep using it, either ship in a decent stockpile of spare parts and the people to install/maintain everything, or risk things slowly breaking down'.

So does this mean a base will need constant maintenance to stay in this state, or will a visit from the maintenance guy every few years/months/whatever be enough to keep it running perfectly?

[RoverDude]

It would be analogous to Machinery today.  i.e. either visit it, or add a repair shop with the right resources.

[notthebobo]

Interesting discussion, it's nice to see how the game play thought processes differ amongst everyone.

1 hour ago, RoverDude said:

It would be analogous to Machinery today.  i.e. either visit it, or add a repair shop with the right resources.

My thoughts: if it would be analogous to Machinery, and Machinery would be retained but not consumed anymore, what would be the purpose of Machinery?  It seems like you're recreating how Machinery works today, where an engineer in a workshop ensures your base 's machinery stays topped off. I must be missing something.