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

[DoktorKrogg]

Sorry, I'm kind of late to the party on the Machinery discussion (fell behind on my daily forum digest emails). I'm glad to see it sparked a lively discussion! I don't really have a ton to add that hasn't already been brought up but I went back thru our previous conversation in the USI team chat and thought I'd pull out some of the highlights to move into the discussion here:

• Currently, Machinery plays several roles.
  • It lets you reduce the launch mass of parts (MaterialKits also do this).
  • It affects the efficiency of the part.
  • It simulates wear by being consumed over time, thus reducing efficiency.
• What @RoverDude is ultimately proposing is that we decouple wear from Machinery and simulate it another way. Machinery would still be "like MatKits, but for parts that do something", i.e. still a way to lower launch mass and still affects efficiency. It just wouldn't be consumed anymore. Whereas MatKits are consumed when you use them to build something, Machinery would stay around forever, allowing you to move it around your base to tweak the efficiency of parts.

Frankly, removing wear from the efficiency calculation makes our lives easier when it comes to balancing and maintaining code (especially in regard to keeping MKS and USI-LS as separate, yet complimentary mods). It makes base planning easier too. We want to keep the concept of wear and tear though. So really what we're asking is, how do we simulate wear if not with Machinery? A couple possibilities:

• Give parts a lifespan and when that timer is up, they stop functioning forever. (I like this idea for smaller parts like drills and the Ranger bits.)
• Bring back ReplacementParts as a consumable. As long as you have a staffed workshop and keep ReplacementParts around, your base will continue to function indefinitely. (I like this idea for larger parts.)
• If you choose not to have a staffed workshop or don't keep enough ReplacementParts on hand, you run an increasing risk of parts breaking down the longer you let it go.

I tend to agree with the concerns people have expressed in regard to overlap with mods that simulate random failures. So I'm not in love with the third option in that list. I think instead, we could just give every part a "health bar" that drains on a timer (it could be slightly different for each part to avoid having your entire base shutdown simultaneously). For smaller parts, like drills and Ranger parts, when the health bar runs out, the part is used up. Find some way to replace it (KAS, OSE Workshop, recycle it and deploy a replacement via GC, send replacements from Kerbin, whatever). For larger parts, the health bar stays at 100% (or at least depletes much slower) for as long as you have a staffed workshop and a steady supply of ReplacementParts. Fail to meet either of those requirements, and the health bar starts to drain on them too. In all cases, the health bar can never be refilled. Once you let it hit zero, the part is broken forever. I think the "failure state" for larger parts could just be a severe efficiency penalty as opposed to complete shutdown (this could be a setting). And/or it could just consume ReplacementParts faster until it's replaced.

I also agree that it would be ideal to have some kind of an alert system for parts that are about to fail/have failed. I have some ideas on how to implement that.

[Nergal8617]

5 minutes ago, DoktorKrogg said:

I tend to agree with the concerns people have expressed in regard to overlap with mods that simulate random failures. So I'm not in love with the third option in that list. I think instead, we could just give every part a "health bar" that drains on a timer (it could be slightly different for each part to avoid having your entire base shutdown simultaneously). For smaller parts, like drills and Ranger parts, when the health bar runs out, the part is used up. Find some way to replace it (KAS, OSE Workshop, recycle it and deploy a replacement via GC, send replacements from Kerbin, whatever). For larger parts, the health bar stays at 100% (or at least depletes much slower) for as long as you have a staffed workshop and a steady supply of ReplacementParts. Fail to meet either of those requirements, and the health bar starts to drain on them too. In all cases, the health bar can never be refilled. Once you let it hit zero, the part is broken forever. I think the "failure state" for larger parts could just be a severe efficiency penalty as opposed to complete shutdown (this could be a setting). And/or it could just consume ReplacementParts faster until it's replaced.

I like most of this, the only thing I really have a problem with is the "In all cases, the health bar can never be refilled." part.  On one hand I can sort of agree with it but most of the methods of replacing parts(with the exception of sending a new one from Kerbin) amount to rebuilding it in situ, so why can't I just rebuild the guts of the part over time?  It should cost resources to repair a part but in a lot of situations I shouldn't have to simply scrap the whole part and replace it.  For instance the Tundra Industrial Refinery, sure the internals might wear out without maintenance but unless it blows up completely the hull should still be there and my engineers should be able to repair and replace the internal parts.  I can even make this argument for smaller parts like drills, the part of the drill that is going to see the most wear is the cutting head and those are replaceable.

[AccidentalDisassembly]

1 hour ago, DoktorKrogg said:

Sorry, I'm kind of late to the party on the Machinery discussion (fell behind on my daily forum digest emails). I'm glad to see it sparked a lively discussion! I don't really have a ton to add that hasn't already been brought up but I went back thru our previous conversation in the USI team chat and thought I'd pull out some of the highlights to move into the discussion here:

• Currently, Machinery plays several roles.
  • It lets you reduce the launch mass of parts (MaterialKits also do this).
  • It affects the efficiency of the part.
  • It simulates wear by being consumed over time, thus reducing efficiency.
• What @RoverDude is ultimately proposing is that we decouple wear from Machinery and simulate it another way. Machinery would still be "like MatKits, but for parts that do something", i.e. still a way to lower launch mass and still affects efficiency. It just wouldn't be consumed anymore. Whereas MatKits are consumed when you use them to build something, Machinery would stay around forever, allowing you to move it around your base to tweak the efficiency of parts.

Frankly, removing wear from the efficiency calculation makes our lives easier when it comes to balancing and maintaining code (especially in regard to keeping MKS and USI-LS as separate, yet complimentary mods). It makes base planning easier too. We want to keep the concept of wear and tear though. So really what we're asking is, how do we simulate wear if not with Machinery? A couple possibilities:

• Give parts a lifespan and when that timer is up, they stop functioning forever. (I like this idea for smaller parts like drills and the Ranger bits.)
• Bring back ReplacementParts as a consumable. As long as you have a staffed workshop and keep ReplacementParts around, your base will continue to function indefinitely. (I like this idea for larger parts.)
• If you choose not to have a staffed workshop or don't keep enough ReplacementParts on hand, you run an increasing risk of parts breaking down the longer you let it go.

I tend to agree with the concerns people have expressed in regard to overlap with mods that simulate random failures. So I'm not in love with the third option in that list. I think instead, we could just give every part a "health bar" that drains on a timer (it could be slightly different for each part to avoid having your entire base shutdown simultaneously). For smaller parts, like drills and Ranger parts, when the health bar runs out, the part is used up. Find some way to replace it (KAS, OSE Workshop, recycle it and deploy a replacement via GC, send replacements from Kerbin, whatever). For larger parts, the health bar stays at 100% (or at least depletes much slower) for as long as you have a staffed workshop and a steady supply of ReplacementParts. Fail to meet either of those requirements, and the health bar starts to drain on them too. In all cases, the health bar can never be refilled. Once you let it hit zero, the part is broken forever. I think the "failure state" for larger parts could just be a severe efficiency penalty as opposed to complete shutdown (this could be a setting). And/or it could just consume ReplacementParts faster until it's replaced.

I also agree that it would be ideal to have some kind of an alert system for parts that are about to fail/have failed. I have some ideas on how to implement that.

My two cents:

1. The wear mechanic needs to be simple. MKS is already complex.

2. On that note: making a distinction between "small" parts and "large" parts adds complexity for complexity's sake. Attempts at logically distinguishing what "should" and "should not" be reparable will be masochistic and won't add anything to the gameplay. (Why can't small machines be maintained with a resource called Machinery? Or, if ReplacementParts are used... are they not parts meant to replace others...?)

3. Never being able to "refill the health bar" or adding part lifespans also adds complexity for complexity's sake and stretches logic in an aggravating way for the player. If you run out of spare machinery pieces or ReplacementParts or kits full of materials, sure, the machines will probably stop working after a while. But if you ship in (or make) more machinery etc. for the base, it makes no sense not to consider that act the one that makes parts work again. Unless your purpose is to force players to go manually replace things with kerbals every so often (why?), it makes mores sense to incorporate the wear mechanic into the overarching challenge of MKS, which is the process of making a base self-sustaining, not performing individual acts of maintenance as a kind of janitorial duty rather than getting a resource or building something for the base overall.

4. The resource used to keep rudimentary base things going (like drills for resources) needs to be the easiest (or nearly the easiest) to create, because it's the condition of possibility for the rest (if you turn on wear). I can't remember how to make Machinery (there are so many resources!). Hopefully it's somewhere down at the bottom of the tree of things that get combined with other things to make stuff.

Seems to me that wear should either use an existing resource (Machinery?) or combine Machinery and ReplacementParts (and maybe even MaterialKits) into something else. For the most part, those things are not meaningfully different on a conceptual level in context. Things that can wear out consume the resource every X time from any container on the base. When there's no more, parts' "health" counts down slowly from 100 (or whatever). (Perhaps) after reaching 50 or some other arbitrary number, efficiency begins to drop (= grace period). When it hits zero, efficiency either bottoms out (and the base is still minimally functional) or things shut down, based on a setting as you described. The nuance could come in the form of better/worse parts consuming more or less of the resource, or wearing out slower when they're out of replacement parts, or (maybe) having different efficiency floors unless the difficulty setting says otherwise.

Easy that way for a player to determine (A) do things wear out? [OFF/ON] and (B) how much does it suck when things wear out? [0-100 suckiness], IMO.

Edited December 5, 2017 by AccidentalDisassembly

[QuakeIV]

I cant seem to disable the habitation effects.  I have set both Homesickness and NoEVA settings to 0 for normal kerbals and veterans in the config files "C:\Users\Matthew Adler\Desktop\Desktop Programs\KSP 1.3.1\GameData\UmbraSpaceIndustries\MKS\Patches\USI-LS.cfg" and "C:\Users\Matthew Adler\Desktop\Desktop Programs\KSP 1.3.1\GameData\UmbraSpaceIndustries\LifeSupport\Settings.cfg".

My kerbal in space however still cannot gain the ability to pilot their vessel, they are stuck as a tourist.  I save edited the grouchy flag to false but it just reset itself to true again as soon as I loaded up the game.  What gives?

 

[voicey99]

5 hours ago, DoktorKrogg said:

• Give parts a lifespan and when that timer is up, they stop functioning forever. (I like this idea for smaller parts like drills and the Ranger bits.)
• Bring back ReplacementParts as a consumable. As long as you have a staffed workshop and keep ReplacementParts around, your base will continue to function indefinitely. (I like this idea for larger parts.)
• If you choose not to have a staffed workshop or don't keep enough ReplacementParts on hand, you run an increasing risk of parts breaking down the longer you let it go.

I tend to agree with the concerns people have expressed in regard to overlap with mods that simulate random failures. So I'm not in love with the third option in that list. I think instead, we could just give every part a "health bar" that drains on a timer (it could be slightly different for each part to avoid having your entire base shutdown simultaneously). For smaller parts, like drills and Ranger parts, when the health bar runs out, the part is used up. Find some way to replace it (KAS, OSE Workshop, recycle it and deploy a replacement via GC, send replacements from Kerbin, whatever). For larger parts, the health bar stays at 100% (or at least depletes much slower) for as long as you have a staffed workshop and a steady supply of ReplacementParts. Fail to meet either of those requirements, and the health bar starts to drain on them too. In all cases, the health bar can never be refilled. Once you let it hit zero, the part is broken forever. I think the "failure state" for larger parts could just be a severe efficiency penalty as opposed to complete shutdown (this could be a setting). And/or it could just consume ReplacementParts faster until it's replaced.

Instead of a part suffering a Critical Existence Failure when its health bar reaches zero, what about simply giving it an age stat and a "part half-life" instead? As this age increases past a certain point, breakdowns become more common and after another point efficiency starts to suffer as well, and these effects ramp up over time, and every half-life their effects double until the part is too unreliable and slow to be of any practical use. Also, instead of having to replace the part, what about an option to have an engineer/mechanic go out and, using e.g. half the MatKits required to make it and a substantial quantity of ReplacementParts, overhaul the part to restore it to full working condition - if this part is inline in the centre of a very big base, replacing it is just not an option.

2 hours ago, QuakeIV said:

I cant seem to disable the habitation effects.  I have set both Homesickness and NoEVA settings to 0 for normal kerbals and veterans in the config files "C:\Users\Matthew Adler\Desktop\Desktop Programs\KSP 1.3.1\GameData\UmbraSpaceIndustries\MKS\Patches\USI-LS.cfg" and "C:\Users\Matthew Adler\Desktop\Desktop Programs\KSP 1.3.1\GameData\UmbraSpaceIndustries\LifeSupport\Settings.cfg".

My kerbal in space however still cannot gain the ability to pilot their vessel, they are stuck as a tourist.  I save edited the grouchy flag to false but it just reset itself to true again as soon as I loaded up the game.  What gives?

IIRC that file only applies to new saves, to change it for saves already in progress you have to change the settings from the KSC screen. I'm not sure if this restores already grouchy kerbals, if it doesn't then open the persistence, find the kerbal's STATUS_DATA listing and change isGrouchy to False.

Edited December 5, 2017 by voicey99

[RoverDude]

5 hours ago, AccidentalDisassembly said:

4. The resource used to keep rudimentary base things going (like drills for resources) needs to be the easiest (or nearly the easiest) to create, because it's the condition of possibility for the rest (if you turn on wear). I can't remember how to make Machinery (there are so many resources!). Hopefully it's somewhere down at the bottom of the tree of things that get combined with other things to make stuff.

I see it as exactly the opposite.  Temporary (and by that I mean a lifespan in years) should be where you start, but to extend that lifespan requires either shipping stuff in, or fabricating on-site.  This would be consistent with the rest of the MKS, where everything can be bootstrapped.

14 hours ago, BRAAAP_STUTUTU said:

So,say i wanted a fully self-sustaining kolony using tundra parts,USI-LS and some reactors, how much of each would i need?

How many Kerbals?  And for how long?  The difference between a base that will last 100 years and one that will last indefinitely can be significant.

4 hours ago, QuakeIV said:

I cant seem to disable the habitation effects.  I have set both Homesickness and NoEVA settings to 0 for normal kerbals and veterans in the config files "C:\Users\Matthew Adler\Desktop\Desktop Programs\KSP 1.3.1\GameData\UmbraSpaceIndustries\MKS\Patches\USI-LS.cfg" and "C:\Users\Matthew Adler\Desktop\Desktop Programs\KSP 1.3.1\GameData\UmbraSpaceIndustries\LifeSupport\Settings.cfg".

New save setup only.  To change a save in progress, hit the green cube in the space center screen.

1 hour ago, voicey99 said:

Instead of a part suffering a Critical Existence Failure when its health bar reaches zero, what about simply giving it an age stat and a "part half-life" instead? As this age increases past a certain point, breakdowns become more common and after another point efficiency starts to suffer as well, and these effects ramp up over time, and every half-life their effects double until the part is too unreliable and slow to be of any practical use. Also, instead of having to replace the part, what about an option to have an engineer/mechanic go out and, using e.g. half the MatKits required to make it and a substantial quantity of ReplacementParts, overhaul the part to restore it to full working condition - if this part is inline in the centre of a very big base, replacing it is just not an option.

I'm in agreement regarding not having to have the part replaced.  Though you will have to replace a lot of the mass.  Have some thoughts on the half-life bit as well.  Probably in the form of allowing for repeated failures as things break down.  Still costs a fixed cost to repair, so running stuff into the ground till they hit their first breakdown point (while keeping backup systems) could be a valid scheme when figuring out base maintenance.

[Daveroski]

I've been playing with this mod for a while and think that it would be better if on-site base building would progress very differently from the flat-pack system currently in use.

I would like to be able to take a team of guys and all the equipment needed to build a hub with 5 nodes. Front, back, left, right and top.

Then from each of those nodes, I would 'grow' my base. One piece at a time. The initial parts would be 'construction' and 'industrial' units to assist with building the rest of the base.
Bases would then be built in a more freestyle form depending on the site. (gravity, atmosphere, etc.)

Using current 3D printing technology this is already a reasonable concept.

Individual surface mountable parts would be 'printed' and manually installed.

Ships and rovers would be built on-site in the same way.

Being able to get at a worlds' resources and then having to wait for months or years for an Ikea style flat-pack from home kind of defeats the objective of trying to build a self sufficient base, which let's be honest, is what we are all trying to do.

My points are being able to build directly from a node (One part at a time or not) and not having to wait for deliveries from home because we need to add a part here or there.

2c

 

[RoverDude]

You can do this today with KAS and OSE Workshop   

To go one step further... once in-situ DIYKits are done, you would be able to do this natively with MKS and it's bundled bits only.  Spawn your new parts, wheel them into place with the Konstruction bits, and snap them together with konstruction ports.

[Daveroski]

1 minute ago, RoverDude said:

You can do this today with KAS and OSE Workshop   

OSE Workshop? I must check it out. I do hope that it is compatible with your system too.

 

[RoverDude]

Yep, I have native OSE support   They were the ones who came up with the MaterialKits resource we use in MKS.

[Daveroski]

Ah now that might have just opened up the game for me. It was becoming rather a chore. I really like the idea of being able to build from a node. That will make for much more interesting bases and space-stations.

Thank you so much for the information.

 

[sh1pman]

You still need to ship huge KIS containers in order to build actual base parts that are bigger than Ranger series. 5m KIS container to build 3.75m Tundra parts, for example. And then you need to attach it to your base. Not the easiest thing to do.

[QuakeIV]

Thanks for the replies so far.  I have adjusted the settings using the green cube, and the kerbonaut was still stuck as a tourist.  I checked the save data and isGrouchy was set to false.  I am unsure of what has gone wrong.

[mike5brown]

Quick question about drills. I’m working on a mining base and trying to figure out which drill(s) to take. Are the efficiency percentages per separatator or per drill head?  If it is for drill head I’m trying to see the advantages of taking a 500 vs a 100. 

 

On part wear I don’t mind a life span but we need a part overhaul function to off set it. I can downcheck a part and have it fully offline for a time period and consume parts to get it online good as (almost) new. Grab time and resources costs from ground construction as a starting point. Although GC is material kits only from my understanding (need to figure out mining and production first). 

[voicey99]

2 hours ago, QuakeIV said:

Thanks for the replies so far.  I have adjusted the settings using the green cube, and the kerbonaut was still stuck as a tourist.  I checked the save data and isGrouchy was set to false.  I am unsure of what has gone wrong.

Hm. Try HyperEditing something with crew capacity over so it triggers him to come back (hab is shared within 150m), and when you edit it away again he should stay normal. If that doesn't work, give me the savefile or something.

9 minutes ago, mike5brown said:

Quick question about drills. I’m working on a mining base and trying to figure out which drill(s) to take. Are the efficiency percentages per separatator or per drill head?  If it is for drill head I’m trying to see the advantages of taking a 500 vs a 100. 

On part wear I don’t mind a life span but we need a part overhaul function to off set it. I can downcheck a part and have it fully offline for a time period and consume parts to get it online good as (almost) new. Grab time and resources costs from ground construction as a starting point. Although GC is material kits only from my understanding (need to figure out mining and production first). 

Drill stats are per drillhead - It says it in the part description.

That was my thoughts on part lifespan as well. I said you should be able to restore the part, and (not said then) how long the downtime should be would depend on the part.

[mike5brown]

Ah so it does, I was reading the wiki page.  That description contradicts the wiki “The separator slots in drills can all be configured for a single resource or multiple resources. The total efficiency of the drill is divided equally across the separators.”

I think I can trust the description over the wiki.  

 

Now I need to design a mining rig for one of the industrial strippers.  Those things are obnoxiously large, then again 1 separator replaces my entire rig of 100s. What’s the rule of thumb for cooling needed for one of those things?

[Daveroski]

I can not access the KIS inventory of C3_Kontainer_KIS_04 while on EVA and the kerbal has to smooch with the container C3_Kontainer_KIS_03 (the next size down) to be able to access it.

 

[DStaal]

15 minutes ago, Daveroski said:

I can not access the KIS inventory of C3_Kontainer_KIS_04 while on EVA and the kerbal has to smooch with the container C3_Kontainer_KIS_03 (the next size down) to be able to access it.

This is technically either a KIS issue or just a KSP one - you need to be within the KIS grab distance of the *center* of the container to grab something out of it on EVA.  By default that's 3m, so you have to be within that range.  The 5m KIS container obviously will give you trouble with that.   It can be done by walking up to the side (not the end) in the middle, in my experience.  You can also adjust what that distance is using the settings config file in KIS.  (I haven't tried, but you might also be able to work around it by using one of the Konstruction parts with a large grab distance...) 

[mcortez]

Just my 1/2 cent thoughts on possible wear/failure mechanic.

I liked the half-life concept, especially if there was a way to know that half-life value prior to launch.  As each half-life expires, you have a chance of failure - this chance perhaps doubles at each half-life.  Half-life would be no less then 3 months (similar to Spirit & Opportunity, designed to last at least 3mo ended up lasting much longer.). 

Also, if possible, there should be a disabled (powered down) option.  This renders the part in-operable and freezes the threshold timer.  This allows you to take built-in a spare or backup, in case your primary fails. If you're feeling particularly sadistic, you have a chance of failure on initial power-up.

Chance of failure would start at something like 1/2 to 2 percent.  I like a doubling scale at each interval since things can get rapidly bad for parts well beyond their designed lifetime.

Doing maintenance, which consumes a resource, resets the part back to "launch" state. So chance of failure at the next half-life goes back to original value, and the half-life timer resets to zero/Now().  Maintenance could be automated via a crewed part. 

Optional: future pack of robotic parts that let's you send out a maintenance robot/probe/ROV  that is uncrewed but has manipulator arms/claws that can do maintenance. You could even ship out such a ROV already attached to a deep space exploration vessel, so you can do maintenance during transit - vs having backup parts attached and powered down.

Failures would come in multiple varieties, with players able to enable and disable all possibilities via MKS config screen.

1. Catastrophic failure.  Part explodes. 

2. Critical Permanent failure. Part ceases to function and cannot be repaired, must be replaced.

3. Critical Repairable Failure. Part ceases to function, can be repaired via maintenance, requires a large amount of resource.

4. Partial Failure. Part's efficiency is reduced by a percentage.  If implemented for parts without an efficiency, their function is reduced in some other way - for example storage parts could either have their input/output rates reduced (not sure if the resource system allows for this) or their storage capability reduced (like batteries that have had too many charge cycles.). Depending on how this is implemented, it could be a fixed rate of reduction (50% each failure) or random.

If the failure possibilities are configurable, people can play without them, or if they like to live on the edge they can risk explosions.  Default might just be the efficiency and repairable options.

I can't decide if I like a flat/fixed chance of each failure type or if I like stacked.

Flat: at each half-life, check to see if the part has a failure. If it does, then check against a fixed chance 75% efficiency failure, 15% critical repairable, 9% critical unrepairable, 1% explodes.

Stacked: each failure type has an initial percentage at launch. At each threshold a test occurs against each active failure type, and then all the percentages increase for next half-life.

Lastly I would suggest a new resource "Quality", available only at launch and not adjustable in flight.  If possible this resource is used to modify the initial values "at launch."  They could either (whichever is easiest) change the half-life rate, or the initial chance of failure at half-life percentages.  This way you can make a design choice at launch to pay for a high quality part that either has a longer "designed for" / "warranty" period (larger half-life) or has a lower chance of failure at the first threshold point. Optional: In Situ upgrade between quality levels, or perhaps ability to repair/maintain with lower quality or jury-rigged parts (uses less maintenance resource)

Why do I suggest this system:

1. Configurable failure types let's players decide how they want to play.

2. Very well known, easily predictable wear/failure mechanic at launch until first half-life. IE: no chance of failure during warranty period.  That way you know exactly what the output rate is until X months, and that you know you have that long to get someone on site to do maintenance.

 3. If implemented, the partial Failure with fixed efficiency loss, allows for you to do statistical modeling.  You might know for example, that a part has a 50% chance of failure at it's half-life, so include two and then make contingency plans for having 200%, 150%, 100% depending on if they both keep working, one fails or both.

 

[RoverDude]

Thanks for the feedback, gang

[AccidentalDisassembly]

6 hours ago, RoverDude said:

I see it as exactly the opposite.  Temporary (and by that I mean a lifespan in years) should be where you start, but to extend that lifespan requires either shipping stuff in, or fabricating on-site.  This would be consistent with the rest of the MKS, where everything can be bootstrapped.

It makes sense that you'd have to arrive with a cache of spare parts / life support to hold you over, or ship some in shortly, yes.

However, making maintenance and basic construction materials difficult to obtain is the exact opposite of bootstrapping. Bootstrapping suggests using a small starter base (sure, I guess it could be temporary) and its capabilities to progress to larger more complex bases. In other words, bootstrapping IS fabricating on site. So if you want bootstrapping (as opposed to shipping in bits and pieces constantly), you have to have spare parts and basic building materials be first: if the machines don't run, you can't get anything else working. It would make sense to make fancy, exotic things harder to obtain (science stuff, labs, fuel refining, I don't know), but drills and habs and refineries and workshops are the first elements of bootstrapping (ergo maintenance materials too).

One logical progression would be something along the lines of (A) Base drops, (B) While burning through starter materials, acquire capability to prolong life support (if it's on) and the life of the existing base (meaning replacement parts), (C) Use the existing base to build more parts for itself. In this case, the actual practical outcome of the wear mechanic is the need to set up this first set of gathering/refining/production chains as a precursor to others. Once it's established, you add more resources/refineries etc. to the mix and things get progressively more complex.

Missions from the homeworld would accelerate that process quite a bit, of course, or you could just shoot an entire 500-ton base into space if you want.

It depends on what you mean by bootstrapping and the way you think that should translate into gameplay. If you want the gameplay to look more like (A) Drop base, (B) Figure out resupply and expansion missions for years, enhance base/ship elements from homeworld during that time, (C) NOW it's self-sustaining and can expand itself, that's a different way of looking at it, and of course it's up to you. In this case, though, the wear mechanic only means additional mass on the supply missions, for that phase of the base (and one more resource to keep track of) -- until the base can do things on its own, at which point it would come to mean another resource gathering/refining/production loop in addition to the others.

[voicey99]

7 minutes ago, mcortez said:

I liked the half-life concept, especially if there was a way to know that half-life value prior to launch.  As each half-life expires, you have a chance of failure - this chance perhaps doubles at each half-life.  Half-life would be no less then 3 months (similar to Spirit & Opportunity, designed to last at least 3mo ended up lasting much longer.). 

Also, if possible, there should be a disabled (powered down) option.  This renders the part in-operable and freezes the threshold timer.  This allows you to take built-in a spare or backup, in case your primary fails. If you're feeling particularly sadistic, you have a chance of failure on initial power-up.

Chance of failure would start at something like 1/2 to 2 percent.  I like a doubling scale at each interval since things can get rapidly bad for parts well beyond their designed lifetime.

Doing maintenance, which consumes a resource, resets the part back to "launch" state. So chance of failure at the next half-life goes back to original value, and the half-life timer resets to zero/Now().  Maintenance could be automated via a crewed part. 

I meant that a part would have a failure chance to be checked at small intervals (e.g. every day, 3mo is waaay to long), and there would be a base chance for failure that would gradually increase with age to the point where it doubles every HL, rather than a slab system whereby the HL is the failure interval and it won't fail until the next, where it will be double. With respects to overhauls, I planned to separate routine maintenance from overhauls whereby routine maintenance would reset a part's failure chance to the base value (it would increase with time as a multiplier of the base rate), but this base rate would keep ratcheting upwards as the part ages so you will start to get failures even with good maintenance in old parts. An overhaul would reset the base rate to its original showroom value, like you posited for maintenance.

I do like the idea of startup failures, though i think these should be introduced as another base chance after quite a few half-lives so they are only a problem for machines reaching the end of their lives. General failures would also only kick in after a HL or two, and efficiency loss would also start to manifest itself in very elderly machines well beyond their design lifetimes to finally kill it off.

30 minutes ago, mcortez said:

1. Catastrophic failure.  Part explodes. 

2. Critical Permanent failure. Part ceases to function and cannot be repaired, must be replaced.

3. Critical Repairable Failure. Part ceases to function, can be repaired via maintenance, requires a large amount of resource.

4. Partial Failure. Part's efficiency is reduced by a percentage.  If implemented for parts without an efficiency, their function is reduced in some other way - for example storage parts could either have their input/output rates reduced (not sure if the resource system allows for this) or their storage capability reduced (like batteries that have had too many charge cycles.). Depending on how this is implemented, it could be a fixed rate of reduction (50% each failure) or random.

If the failure possibilities are configurable, people can play without them, or if they like to live on the edge they can risk explosions.  Default might just be the efficiency and repairable options.

I can't decide if I like a flat/fixed chance of each failure type or if I like stacked.

Flat: at each half-life, check to see if the part has a failure. If it does, then check against a fixed chance 75% efficiency failure, 15% critical repairable, 9% critical unrepairable, 1% explodes.

Stacked: each failure type has an initial percentage at launch. At each threshold a test occurs against each active failure type, and then all the percentages increase for next half-life

I would go for Flat, but at small intervals rather than half-lives. Stacked seems quite crude. The case with both of them is that a part should be able to fail at any time (with a reasonable compromise to save on processing power being used to continually flip coins on all converters) rather than at large, set and predictable intervals from manufacture/renewal.

Critical unrepairable would not be strictly unrepairable but rather require an overhaul of the part in the same way as resetting the age i.e. you're gutting it and replacing all the machinery inside with new stuff at a significant cost of resources (also resetting age to 0, which regular repairs would not do). Critical repairable would require a cost in ReplacementParts

[Nergal8617]

2 hours ago, mike5brown said:

Now I need to design a mining rig for one of the industrial strippers.  Those things are obnoxiously large, then again 1 separator replaces my entire rig of 100s. What’s the rule of thumb for cooling needed for one of those things?

Lots .  Each separator generates heat and each industrial stripper has multiple separators.  Then you add in the fact that load goes up as your Kolonization bonuses go up which causes each separator to generate more heat, use more EC and output more of whatever it is mining.  I know there is a formula floating around somewhere to calculate it but I can't seem to find it at the moment, maybe another helpful person can point us in the right direction?

[Daveroski]

2 hours ago, DStaal said:

 You can also adjust what that distance is using the settings config file in KIS. 

That setting is apparently for the 'grab' range not the open inventory range.

 

[voicey99]

4 minutes ago, Nergal8617 said:

Lots .  Each separator generates heat and each industrial stripper has multiple separators.  Then you add in the fact that load goes up as your Kolonization bonuses go up which causes each separator to generate more heat, use more EC and output more of whatever it is mining.  I know there is a formula floating around somewhere to calculate it but I can't seem to find it at the moment, maybe another helpful person can point us in the right direction?

It's this formula, which also acts as a multiplier for heat produced (as a % of the VAB value, just add the total % load and multiply the VAB value by that). The best thing to use for MKS stuff is the MKS-brand Thermal Cooling System, which has a huge per-part cooling capacity.

3 minutes ago, Daveroski said:

That setting is apparently for the 'grab' range not the open inventory range.

I believe it does both.

Edited December 5, 2017 by voicey99