RoverDude

Put the IsGrouchy flag back to true, try again

Thanks for the feedback, gang

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

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.

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. 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. New save setup only. To change a save in progress, hit the green cube in the space center screen. 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.

There's a patch for TAC-LS included, though some parts are not as useful because TAC lacks some of the breadth of USI-LS. LLL parts are fine, but I am not aware of any configs for them for MKS. And yeah... what do you mean by EVA? Also.. I hope you feel happier soon. @Rocketmanreturns - if you're not on the 1.3.1 versions, you may have some old bugs that have since been fixed.

@IgorZ beat me to it

A full tier lower (Matkits are used to make machinery). All MKS parts have machinery as a mass deferment for the complex bits. Expandable parts use the simpler MatKits for the expansion process (which is assumed to be mostly bulkheads and panels and such).

Still need Machinery to act as deferred mass for non-expandable parts. @Fergrim - Dangit is a completely different scope and well beyond what I'd have in mind for this.

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

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

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

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.

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

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 Will be in the USI-LS pre-release

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

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

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

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

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

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

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

Discussion time So was talking to @DoktorKrogg in USI chat about the wear mechanic. Currently, machinery has a direct impact on efficiency, but is also consumed. It is then later replenished by maintenance. The downside is that this gives converters a long tail of diminishing performance that makes making simple base conversion calculations challenging. The idea we're noodling is to remove machinery consumption so that machinery becomes a mass-offset tool. This makes making things like hab modules a lot easer to balance between USI-LS (which has no machinery concept) and MKS. To simulate wear, we'd switch to a part-failure mechanic, where the longer a module is in use, the greater the chance of it outright failing. This can be reset through regular maintenance (and would consume a resource), or could be done automatically with a manned workshop (we'd assume the engineers in question would be running about fixing things). Or, could be turned off completely (similar to how wear can be turned off today). Naturally, if you let things go so far bad that the module actually fails, the repair cost would be steeper (i.e. it would remove a bunch of your machinery). Thoughts?

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

There are a few parts where you can change their characteristics in the VAB via the PAW