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

[RoverDude]

4 hours ago, Brigadier said:

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.

Nothing to do with probes - this would only be relevant for active converters.  And just an alternate form to the current wear mechanic (diminishing machinery). 

So if one were to create an interstellar ark ship with a lot of active stuff that was going to be floating around for a hundred years, with all of the converters running, you would either need a manned workshop, or you would have to set an alarm to top everything off every X years (similar to machinery today).

[DStaal]

I have to say: This new version of the wear mechanic sounds a lot like BARIS.

 

[RoverDude]

huh, never used that mod tbh, but not too many ways of skinning this particular cat (either it's binary like DangIt!, etc. or you reduce efficiency like MKS currently).

[maja]

BARIS is about building with quality parts (parts used in more flights and tests are better) and on top of it is the wear and failure mechanic. Not using it, but I used MOLE, so I looked into it.

As I understand it, this newly proposed failure mechanic is about increasing failure probability if not maintained properly only, as an option to current gradual efficiency reduction if not maintained properly.

Edited December 1, 2017 by maja

[DStaal]

I'll admit I was more thinking it sounds/feels very similar, and that RoverDude might find the discussions on which problems they had and how they overcame them useful.

[Daveroski]

Shouldn't these radiators glow before the core heat of the reactor goes above 1000?

 

 

The reactor doesn't seem to be transferring it's core heat to the 4 medium radiators.

Only one drill is in operation here. I tried using 4 of largest radiators and the results are much the same.

The core heat just keeps going up.. this isn't an image of where it stopped climbing.

The radiators never seem to get much of a higher cooling percentage.

 

Edited December 1, 2017 by Daveroski

[RoverDude]

@maja is correct.  The primary goal is to make things a lot more predictable from a base scaling standpoint (i.e. you no longer have to compensate for diminishing returns even on smaller bases), but still provide an appropriate incentive to keep based manned and operating.

Thinking to what @voicey99 noted... this could (in theory) be something set up in the auto-repair mechanic.  i.e. requiring a set amount of replacement parts with a more frequent repair schedule costing more stuff, but also making things less risky.  I have some thoughts on some visuals for this as well to avoid cluttering up the PAW too much. 

I will very likely resurrect ReplacementParts, etc. that were used in the past with USI-LS for the repair and maintenance mechanic.  The question being what an appropriate default 'lifespan' of a base should be... i.e. how long before systems start failing.  The behavior being driven should be a motivation to have redundant systems, and to have crewed bases to keep things running.  

An example would be having a couple of life support modules running at 50% load (which in turn would double their workable lifespan) so that if one failed, you could always operate on backup till you could fix the primary.

Resource wise, ReplacementParts would be tier 4 (like Machinery), and require MatKits/SpecParts/Chemicals (with a higher ratio of SpecParts than Machinery).  And the workshop part module to support this will be moved into some very small core modules, like the pioneer modules and also a revised scout module for the Salamander that would also include a small GC workshop to better jumpstart things.

 

 

[Terwin]

While a wear and tear mechanic is a good option to have, would it not be much easier to just add a 'spare capacity' to things that use machinery so that they can run for a while before the decreasing machinery levels actually have an impact?

(perhaps +5-10% for things that are expected to be manned, vs the +100% currently present in MPUs)

That gives you consistent functionality over short periods(a few days) before the lack of maintenance starts to have a negative effect without any additional resources to track.

Not sure of a good way to balance this to USI-LS though, unless installing MKS reduces the weight and adds a Machinery bin for LS components so they can start tracking wear.

 

Edited December 1, 2017 by Terwin

[voicey99]

1 hour ago, Daveroski said:

Shouldn't these radiators glow before the core heat of the reactor goes above 1000?

Deployable thermal control systems REALLY hate MKS drills, since they have a huge amount of slack core heat transfer (max cooling) to account for production boosts, and they seem to get priority over and interfere with the cooling of other parts. Best thing to do when you have MKS drills on your ship is to use the geothermal-well TCS that comes with MKS (since it has basically unlimited cooling, as long as it's landed) or use radiator panels as they can only cool their parent part and whatever is attach to their parent part so the drills can't touch them (deployable TCSs will still cool the drills fine).

1 hour ago, RoverDude said:

I will very likely resurrect ReplacementParts, etc. that were used in the past with USI-LS for the repair and maintenance mechanic.  The question being what an appropriate default 'lifespan' of a base should be... i.e. how long before systems start failing.  The behaviour being driven should be a motivation to have redundant systems, and to have crewed bases to keep things running.  

An example would be having a couple of life support modules running at 50% load (which in turn would double their workable lifespan) so that if one failed, you could always operate on backup till you could fix the primary.

Resource wise, ReplacementParts would be tier 4 (like Machinery), and require MatKits/SpecParts/Chemicals (with a higher ratio of SpecParts than Machinery).  And the workshop part module to support this will be moved into some very small core modules, like the pioneer modules and also a revised scout module for the Salamander that would also include a small GC workshop to better jumpstart things.

Perhaps each part (i.e. partline) would have its own failure chance to be checked against every hour. As a preliminary equation, what about [base chance] * [total years of uptime]^0.5 * [load]? For example, a part that has a base chance of 0.002% and had been running for 5 years with no maintenance at an average of 210% load would have a 0.0094% hourly chance of failure, which translates to a 0.056% daily chance of failure. Various partlines would have different base chances to add or reduce the hourly chances of failure - Ranger parts might be more rugged given their simplicity, Tundra parts would be quite demanding thanks to their high throughputs and MPUs would be able to go for potentially decades thanks to their automation and slow processing rate before breakdowns became a serious threat. Certain parts might also take longer to fix (affected by skill?) than others - maybe the amount of work needed to fix something could be randomised between a quick hour job and a laborious process leaving you without that potentially critical part or module for days at a time (e.g. your reactor could fail and take a week to fix, in the meantime leaving you relying on emergency power from solar panels or fuel cells and probably shutting down most of your production), though this could be overcomplicating it. A flat-rate time required to fix each part could be a simpler way round it.

[RoverDude]

7 minutes ago, Terwin said:

While a wear and tear mechanic is a good option to have, would it not be much easier to just add a 'spare capacity' to things that use machinery so that they can run for a while before the decreasing machinery levels actually have an impact?

(perhaps +5-10% for things that are expected to be manned, vs the +100% currently present in MPUs)

That gives you consistent functionality over short periods(a few days) before the lack of maintenance starts to have a negative effect without any additional resources to track.

Not sure of a good way to balance this to USI-LS though, unless installing MKS reduces the weight and adds a Machinery bin for LS components so they can start tracking wear.

 

Would still land us in the same boat (you could only plan reliably for that first bit) and this also solves the USI-LS balance issue, since machinery would be purely a mass ofset for non-deployable parts.

3 minutes ago, voicey99 said:

Deployable thermal control systems REALLY hate MKS drills, since they have a huge amount of slack core heat transfer (max cooling) to account for production boosts

This is fixed in stock, so I can actually fix this in MKS now

To the rest - keep the discussion rolling   We're working through some of the details in USI Slack

[Gilph]

2 hours ago, RoverDude said:

@maja is correct.  The primary goal is to make things a lot more predictable from a base scaling standpoint (i.e. you no longer have to compensate for diminishing returns even on smaller bases), but still provide an appropriate incentive to keep based manned and operating.

Thinking to what @voicey99 noted... this could (in theory) be something set up in the auto-repair mechanic.  i.e. requiring a set amount of replacement parts with a more frequent repair schedule costing more stuff, but also making things less risky.  I have some thoughts on some visuals for this as well to avoid cluttering up the PAW too much. 

I will very likely resurrect ReplacementParts, etc. that were used in the past with USI-LS for the repair and maintenance mechanic.  The question being what an appropriate default 'lifespan' of a base should be... i.e. how long before systems start failing.  The behavior being driven should be a motivation to have redundant systems, and to have crewed bases to keep things running.  

An example would be having a couple of life support modules running at 50% load (which in turn would double their workable lifespan) so that if one failed, you could always operate on backup till you could fix the primary.

Resource wise, ReplacementParts would be tier 4 (like Machinery), and require MatKits/SpecParts/Chemicals (with a higher ratio of SpecParts than Machinery).  And the workshop part module to support this will be moved into some very small core modules, like the pioneer modules and also a revised scout module for the Salamander that would also include a small GC workshop to better jumpstart things.

 

 

 

1 hour ago, RoverDude said:

To the rest - keep the discussion rolling   We're working through some of the details in USI Slack

Hi, if your looking for some ideas, I may have a few...

With respect to base scaling, I think the best way to do that is to fix power consumption and heat generation, meaning that that do no get amplified with bonuses. The consequence is that manufacturing/production bonuses are capped at 200% (meaning double) the original specs, using a log function that gives more increase at the beginning and flattens towards the max. I could write a whole TL;DR section of you wish, but I thing it's a good balance of reward, realism, and gameplay consideration.

I started using MKS just after the wear and Replacement Parts got removed, so I can't comment on how useful they were to me in the past, but I know I never felt the need for them after they are gone. As mentioned above, there are mod choices to implement that mechanic.  When you think about the Machinery/Specialized Parts/Material Kits trinity, making RP a tier 4, with all of the code complexity you mention, doesn't seem to justify the effort.

To model what you describe, you can extend the Hab/Home-like mechanic to bases/vessels:

1. Things consume more Machinery as they get older.
2. Factories will reduce output and parts can break, and can be fixed by Kerbals using MK/SP.
3. Bad things like the above will happen slower/less frequent based on a certain mix of Kerbal population

I think this can satisfy your objectives pretty nicely in a much simpler implementation.

Thanks

 

Edited December 1, 2017 by Gilph
typos

[Smurfalot]

While the back and forth about maintenance and such has been interesting, I just want to point something out from the "casual" gamer perspective. 

There is a notable difference between adding interactive complexity/depth to the gameplay and simply creating a huge, repetitive pain in the ass for the player to deal with on a regular basis.

If you add too much complexity for the sake of complexity, I will be forced to neuter all of these extra "features" so that I can actually enjoy playing the game again.

[Nergal8617]

58 minutes ago, Smurfalot said:

If you add too much complexity for the sake of complexity, I will be forced to neuter all of these extra "features" so that I can actually enjoy playing the game again.

RoverDude did say that you would be able to disable the part failure just like you can with the current wear mechanic.  I personally don't like getting varying outputs from my converters so I always turn off the wear mechanic in my games; I actually like the idea of part failure if you don't do maintenance.  As for being repetitive, that's what workshops with automated maintenance are for.

[Smurfalot]

1 minute ago, Nergal8617 said:

RoverDude did say that you would be able to disable the part failure just like you can with the current wear mechanic.  I personally don't like getting varying outputs from my converters so I always turn off the wear mechanic in my games; I actually like the idea of part failure if you don't do maintenance.  As for being repetitive, that's what workshops with automated maintenance are for.

Don't get me wrong, I totally agree with you.

I am just saying that if you make things too complex there is a point of diminishing return where more users will opt out rather than deal with all the extra mechanics, at which point most of the effort put into perfecting those mechanics is largely wasted. 

This is in no way a criticism, Rover does great work. I hate to see him go too far down a rabbit hole when his limited time and energy can be used elsewhere and potentially have more impact for more end users.

[Nergal8617]

11 minutes ago, Smurfalot said:

I am just saying that if you make things too complex there is a point of diminishing return where more users will opt out rather than deal with all the extra mechanics, at which point most of the effort put into perfecting those mechanics is largely wasted. 

This is in no way a criticism, Rover does great work. I hate to see him go too far down a rabbit hole when his limited time and energy can be used elsewhere and potentially have more impact for more end users.

That's true; should probably keep the K.I.S.S. principle firmly in mind but Rover usually does.

Edited December 1, 2017 by Nergal8617

[NepalRAWR]

I have built my first ground base but I have a problem: Everytime when I use my small spaceship to fly to a new biome the hab timer of my scientist expires when I fly further then 150m from my base away

I have already tried to transfer my crew in my base and waited 20 days but if I tried to fly, my scientist and my engineer became tourists. Only the pilot has everytime 9 days hab time.

Is this normal and is there a way to solve the problem? What am I doing wrong?

[voicey99]

43 minutes ago, NepalRAWR said:

Is this normal and is there a way to solve the problem? What am I doing wrong?

This is normal, since habitation time is shared between vessels within 150m of each other, and when you go out of 150m range you lose the habitation time granted by the other vessel. I'm not entirely sure on how this works, but it might be that if you have been on the surface for longer than the original habtime in your vessel, it recalculates for the "extra" time you gained by being near the base and takes it away, potentially reducing it to zero - the latter part is just me guessing, so i might be right or wrong. Your pilot would not have lost any habtime from when they started, since over 1yr counts as indefinite for them (I assume the combo time was >1yr?).

I've never had to deal with this, but try shuttling the crew between a couple of other vessels as well?

[RoverDude]

@NepalRAWR - there's also a fix for a bug related to that (essentially the hab bonus should drop, but it is also currently resetting your timer too far back in time).

[NepalRAWR]

15 minutes ago, RoverDude said:

@NepalRAWR - there's also a fix for a bug related to that (essentially the hab bonus should drop, but it is also currently resetting your timer too far back in time).

where is the fix?

[LameLefty]

3 hours ago, NepalRAWR said:

I have built my first ground base but I have a problem: Everytime when I use my small spaceship to fly to a new biome the hab timer of my scientist expires when I fly further then 150m from my base away

I have already tried to transfer my crew in my base and waited 20 days but if I tried to fly, my scientist and my engineer became tourists. Only the pilot has everytime 9 days hab time.

Is this normal and is there a way to solve the problem? What am I doing wrong?

I experienced this same kind of thing (I think, anyway) a week or two back in my Career game when I sent my first mission to Minmus. I included resources and Hitchhiker module that was supposed to give me something like 22 days of Habitat time. Trip out was 8 days or so, course, with 8-ish days for the trip back, I thought I'd have at least SOME time for an excursion in the lander. But as soon as my pilot and scientist exceeded 150m from the orbiting part of the vessel, my scientist became a tourist. I understand the Wiki on GitHub isn't completely up to date, but this isn't at all what I expected to happen.

1 hour ago, RoverDude said:

@NepalRAWR - there's also a fix for a bug related to that (essentially the hab bonus should drop, but it is also currently resetting your timer too far back in time).

I haven't checked Git yet, but is there a new release pending?

[RoverDude]

10 minutes ago, LameLefty said:

I experienced this same kind of thing (I think, anyway) a week or two back in my Career game when I sent my first mission to Minmus. I included resources and Hitchhiker module that was supposed to give me something like 22 days of Habitat time. Trip out was 8 days or so, course, with 8-ish days for the trip back, I thought I'd have at least SOME time for an excursion in the lander. But as soon as my pilot and scientist exceeded 150m from the orbiting part of the vessel, my scientist became a tourist. I understand the Wiki on GitHub isn't completely up to date, but this isn't at all what I expected to happen.

I haven't checked Git yet, but is there a new release pending?

Yep - I have some things to do, and @DoktorKrogg  has the updated Orbital Logistics code to check in, then there will be a constellation pre-release

1 hour ago, NepalRAWR said:

where is the fix?

Will be in the USI-LS pre-release

[Urses]

i am on the idea for the machinery to get an option for the science tree  like "Realability" and enable to "overload" machinery using parts.

You can load the parts to maybe 105% machinery for support but for calculations all over 100% will be ignored. but this way they can stay at 100% output for some time and through maintance you can provide a longer work period at max lvl.

And if this prozess is linked to progress through tech tree and USI generations we have a interesting progression from the steps. As they are Ranger->Duna->Tundra->Realability. We have a part Overload witch 115%->110%->105% and have a guide line for using the automatic outposts.

Ranger for full automatic, Duna for allmost automatic and Tundra for prefereable manned work?

[voicey99]

23 minutes ago, Urses said:

i am on the idea for the machinery to get an option for the science tree  like "ReLIAbility" and enable to "overload" machinery using parts.

You can load the parts to maybe 105% machinery for support but for calculations all over 100% will be ignored. but this way they can stay at 100% output for some time and through maintENance you can provide a longer work period at max lvl.

And if this proCess is linked to progress through tech tree and USI generations we have a interesting progression from the steps. As they are Ranger->Duna->Tundra->ReLIAbility. We have a part Overload wHICh 115%->110%->105% and have a guide line for using the automatic outposts.

Ranger for full automatic, Duna for aLmost automatic and Tundra for prefeRAble manned work?

@Terwin suggested something similar to that, and the response was that it would still not eliminate the annoying production tail that the change is designed to get rid of.

[Urses]

1 hour ago, voicey99 said:

@Terwin suggested something similar to that, and the response was that it would still not eliminate the annoying production tail that the change is designed to get rid of.

And for these this would bocome an aditional Tier4 ressource? Why not go a step lower and stop there?

Wear is present only if there is lack on maintance. For this we use MaterialKits as they provide all small bits needed. And as more Complex maschinerie you have as more you need of them. Like a Ranger module needs only 1 per day and a Tundra NuclearPlant like 1 per hour. And only then if you don't have basic materials to provide maintance with MK's, your machinery wears of and sink the efficiency. 

This way we have the wearing component but have the ability to stay on 100% effiency without jumping up and down permanently.

We can see the wearing process in reduction of MaterialKits reserves, but as long we can provide them we have no machinery losses. And if we lack MK's machinery will be used instead and sink the effinecy, but if we bring new MK's in, we stop this and can bring new charge on machinery to provide maintance and regenerate effiency to 100%.

Edited December 2, 2017 by Urses

[Wyzard]

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.

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.)

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.)

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).