voicey99

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.

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.

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.

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.

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

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

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?

What exactly is your problem here? To bring up the debug on a Mac, I believe it's cmd-f12.

The HG-5 is an extremely weedy relay antenna, and it can only communicate with a built-in antenna from up to 158km away. If you want to relay to the probe, give it a proper antenna. See below for a tool to calculate these things:

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

And as far as specifying maintenance interval goes (I edited that post), it would be great to see something like that as well, since small bases yet to establish themselves might need to scale back on the maintenance to save resources, but also while risking breakdowns as the tradeoff. Some converters might be able to go longer without intervention than others (MPUs should last decades to keep their unmanned advantage), meaning they might not all need to be serviced at one cosmically fixed interval (scheduling maintenance intervals for each processing part maybe, or is that too complex?).

Would parts fail during catchup i.e. it would simulate a backlog of maintenance and apply a failure chance every catchup tick? Also, I think a good idea would be that maintenance checks would consume a fixed amount of machinery, and you would be able to specify the time interval between them so you could keep them pristine for more resource cost and have a very low (but nonzero) failure rate, or be cheap and skimp on maintenance but run an exponentially (not to steep, though) increasing risk of failure the longer you leave them.

Could you share a screenshot of what you're trying to do?

Are you doing it from EVA (which you have to IIRC)?

I believe it is determined by the vessel that is initiating the push/pull requests, i.e. the one with the processor on it. LL will only pull resources if it is under 50% capacity and has an MKS processor on the vessel that requires those resources, and will only push resources if it is over 85% capacity and has an MKS processor on the vessel that produces those resources. It doesn't need to be activated to do this, and I can write a patch to add this behaviour to the stock ISRU if needed. I don't use LL since I have yet to build a decentralised base rather than a single, monolithic structure, so this is what I think is the case from some quick experiments and reading the logistics code.

Catchup is still done 6h at a time, and that means you actually need 12h of storage as PL only empties to/fills to half full (i.e. it only uses half the container capacity). I recommended 60h for LL, since LL can only transfer 10% of the container volume per catchup cycle. EC is not included in catchup.

See here.

Yep, since you need some storage as a buffer. 60 hours worth of production storage is needed if you don't want to lose any (since LL can only transfer 10% per 6h chunk), and then you will also lose some to the initial catchup chunk. Stock ISRUs won't, only an MKS Mobile Processing Unit (or other MKS converter for other resources) will. I can write you a small patch to add LL functionality to the stock ISRUs, but they don't trigger LL by default. Again, you will also need 60h worth of miner production on the processor for the same reasons. The MPU will push LFO to the ship as it runs if the LFO output container is full enough and the ship has local-logistics-enabled tanks on it (so just any old MKS tank that can transfer out to normal fuel tanks as it fills). You can also use manual local logistics from the Kolonisation Dashboard to transfer within 150m, which can even transfer to non-MKS tanks.

Put this into a patch: This adds it to cmd modules and wheels, it can be applied to more if needed.

What is the issue? The OP states it's under the zlib license, which allows editing and redistribution so long as you give credit and a notice that it's been modified.

The version of USITools bundled with the current version of MKS has a glitch that breaks the custom categories, replace it with this hotfix to bring them back.

Yes, and you may need more batteries on the distributing vessel as well. The amount moved is proportional to the total storage (10% a tick, as earlier), so the more you have the more you shift.

It's inverted from what they originally said, since the IVA itself is fine but the portrait camera is clipped into the side, likely as a consequence of the Salamander's squashed appearance - is the portrait camera pos fixed in place? Also, oddly, it seems to vary slightly; sometimes being completely black, sometimes only covering part of it and sometimes not covering it at all.

Just had a look, the parts of the DLL dealing with power are just extensions to the main ModuleLogisticsConsumer and so power is indeed bound by 10% a tick. I don't know how many ticks there are in a game-second (I believe it can vary?), but to increase transfer rate you should stick on more batteries as 10% of more is more.

There seems to be some separate stuff dealing with EC (it isn't part of the main LL module), and as far as I can see there doesn't look to be a tick limiter, though I could be wrong since I'm restricted to "I think this does this" insofar as reading code is concerned. The 10% resource transfer limit is baked into the DLL and explicitly commented on here at line 211 and 223.