At a quick glance, it looks good. Fairly simple and straightforward, while removing the behind the scenes "magic" that needed for the previous implementation to work.

I don't think it would actually matter if you did all the research needed to figure out what would be reasonable numbers if you wanted to express estimated power needs of such systems in kWh (not to mention what would you base the estimates on for something we never built/used yet, maybe if there are such info for the ISS available that could be used as a baseline, still, they don't generate water and oxygen the way the habs do); what the "power unit" itself is doesn't matter as long as the calculations made with them are consistent and the whole thing works as a closed system. Maybe it would be needed if you wanted to give the player a more detailed way to manage power by knowing exactly how many units are being produced and used over any given timeframe so that they can decide which system is best to be turned off when low on power, but that might be simply too much for some players to want to care about. "Do I see 100% on the systems? Yes, then all is fine. No, then I may need to save power by turning something off." That should be enough from a gameplay perspective.

A simple enough additional feedback could be that the hab system view (the detailed one) could give an estimated charge/drain rate (over some period) instead of just saying "charging" and "draining" so that if it says something like "76.4% (-17.2% per [timeframe]), then the player would be able to estimate how long will it last under these conditions, and recheck after having turned one or another system off to see if that lowered drain to the point where it may still be negative but at least lasting until charging is expected to pick up again.

I like the idea of "producing" and "maintaining" states of the systems. I actually made a note about suggesting something similar at one point, actively manageable by the player, but this implementation is simpler from a gameplay perspective (and doesn't need additional UI elements) and does effectively the same. It also gives a bit of room for balancing: you can slightly reduce the maintain mode power drain a bit if more unused charge is needed. It may worth keeping in mind that the heater and water systems will be the most likely to run in low power mode (heater almost always, water occasionally), while oxy will likely never, so those two would make more impact with their difference between high/low power mode.

You could also do the same dual mode thing for electrical: when the player is not in the hab, the power drain could drop by 5-10 points; internal lights could get turned off, computers go standby, appliances/tools not used etc. It would also add a bit of overhead to be sent to the battery.

As for the suit, if you consider how much electricity that might use/be able to store compared to what the hab and its battery does, it should be a tiny amount, like, 2-5 units/tick, maybe, and even that should charge the suit fairly quickly. You could simply establish a power draw scheme similar to that of the hab systems: heating needs up to this much (depending on external temp, I suppose), light draws this much per tick when turned on, scanner needs this much per tick when turned on, and I want the suit to be able to run for x ticks with a single recharge, so how big the battery should be? And then set the charge draw to get a reasonable charge time with that capacity needed to be filled, and use that as additional drain while the suit is charging. Currently you have a 25-55 units/tick overhead (more if you adjust the low power drain state of some systems, the ones more likely to spend more time in that state), so if you can fit it into that budget with maybe a little leftover, it should be good (the suit will not draw power indefinitely, only for a limited amount of time, after which it will drop off the power draw side of the budget anyway).

This issue still appears to be present in 0.60, systems show 0% with as much solar capacity installed as possible (4 large and 1 small is the most I had in this case), while the portable panel is able to charge the suit very slowly as intended.

If/when keys are held down, they are repeated at a relatively slow rate, and then there's only one click per selection movement. But usually there's an extra click at the end when the key is released so I wonder if it's something like a separate instance of the "repeater" timer is initialized for each keypress and then they start to interfere with one another?

I may have been editing the OP just before you responded... Adding the remark about mouse acceleration in reverse as the possible cause.

This sounds like one of the common Unity issues with input device management, where the engine incorrectly detects a constant phantom input under certain conditions. A typical symptom of it is the "left" control being stuck, manifesting itself in the player character constantly spinning to the left without any user input at all, or in this case, the selection being constantly forced to the left.

Do you have any kind of game controller/gamepad or joystick (anything other than a regular keyboard and mouse) plugged in? Try to unplug all of them before starting the game and see if the issue persists. Also, if you have any virtual joystick/gamepad software (things that emulate such input by mapping their functions to keyboard keys or mouse movement), that is also prone to cause this even when not running: you have to completely uninstall them to fix this.

If this is the case, there's not much the developer can do: I've seen this issue in a number of other Unity based games and all they could do was adding various workarounds to disable input devices completely, or tell the player to physically remove them before playing, since the cause is not in their code, but in Unity itself.

There is one thing that was never really clear to me (and your wording may hint at that you intended it to be the second): does the Electrical system itself use power when turned on, or it's only supposed to generate charge for the battery? If it does not use power, then what powers the Hab itself? There are the internal and external lights, ther airlock doors, the compressors/pumps for the airlock, the computers and other displays inside, the trafting tools, the (currently only make believe) kitchen equipment, etc. And even then, Electrical would have to be able to generate 3x as much power than each of the other systems, since it needs to produce enough reserves for the night for all 3 of them, and yet, it requires only one set of solar panels, not 3. So this is one thing that needs to be made consistent and clear, which it currently isn't at all: all 4 systems (need to and) do consume power, and each need to produce enough to run and to make reserves for itself for the night.

And then saying if 100% is when you have enough input to run the system during the day without external supply, or when you have enough to put sufficient reserves away for the night too is just the matter of how you define it, so, sure, 50% when no leftover and 100% when enough leftover for the night works just as well. However, then we're back to the issue of 100% not being really 100% due to the reduced effectiveness in the morning and evening, so you'd again have to offset the consumed/stored ratio to make 100% truly mean you have enough to run for a whole day... or expect the players to realize that on their own, and experiment with by how much they need to go over 100% to have the power actually last through the night (which might kill them on their first night so not much experimenting will go on in that game anymore).

Reducing panels slots may not be a good idea. The players won't necessarily have enough large panels to use only those for all systems, and when they have less, only 3 mounts per system may not be enough to fully power all systems. Granted, you could just expect them to actively manage power drain in this case by having to choose one system which they need to turn off for the night. And it would be an even bigger issue when a storm reduces power output to 15%; even with 5 large panels you'd only get 75 units for any system with the current balance, while they need 100 just to function without producing reserve, which means you need to start saving power a few days prior a storm to have a fully charged battery when it arrives, and even then, you'd be able to operate one, maybe two systems only during the day when you have at least a partial charge. Not necessarily a bad thing, but it would likely kill the player the first (few) times before they realize this.

If you insist on limitng the excess that can go towards charging the battery, then the better way is to go back to a hardcap: no matter how much input is installed, only a maximum of 300 units (150%) per tick will be taken into account / displayed of it, and the rest is ignored. It actually even makes sense, since power supplies and their internal components are rated for a maximum load / current, and their output increases only up to that point, no matter if their feed would be able to provide more.

I didn't want to make the above post even longer...

What also could work, and would be closer to the current method, is a much simplified version of the above solution paired with the removal of the 100% hardcap on power utilization per system regardless of actual power, and loss of any excess (which never made sense to me anyway).

Let's just say each system consumes 100 units (important, not percent, units, everything is still in units, percentage is only for display) per tick, day and night. When you have less than that provided to one particular system from local source, at any time of day, the missing amount is drawn from the battery. When you have more than that provided from local source, the excess is not lost, unlike currently, but sent to the battery to charge it. There is no artificial cap: if you install 5 large panels to any one system, you get all of the provided charge, the amount not used locally being sent to the battery as long as electrical is operational and turned on to route the charge. So you don't need to magically create the reserve battery charge out of nowhere in the electrical system like currently, instead, it is actually and visibly provided by each system itself in the form of above 100% power, assuming you can achieve it by adding the required amount of power input. And again, the battery needs to have a capacity of at least, but preferrably slightly more than 400 units (or the combined power unit needs per tick of all the systems if it's a different amount for each) times however many ticks are there in the not producing period of the day.

In practical terms it means that if you see less than 100% power on any system during the day, that one has a power deficit and you need to add more panels or you will run out of reserve power even during the day. If it has 100-200%, then you have enough power for it during the day, but will run out of reserves during the night. And if it has more than 200%, then it generates enough to run constantly (from local power during the day while also charging the battery, and during the night from the reserves it accumulated for itself during the day).

The power unit capacity of the panels would be the same as above, 100 units for the large, 60 units for the small and 40 (20?) units for the portable. The difference would be that when 2 large panels are installed, you will now see 200% power, since that's how much the unit actually needs during the time it can generate power versus during the time it can not, to be fully supplied for an entire day: 200% for half a day then 0% for the other half = 100%. The RTG would also be 100 units, but you only need one of those per system: 100% for the day and also 100% for the night, not adding to nor drawing from the battery.

This would also make it possible to set different power needs (less/more than the uniform 100 units) for each system, to give more room to contol power need by having to choose what can you turn on and what you can not when power input is limited (storm, lack of panels), only the display percentages won't look so nice due to the needs possibly not matching the stepping possible by mixing the sources (combination of 100/60/40).

This would be just yet another hack, not addressing the issue, only forcibly covering another symptom.

Actually, you are not fighting the laws of physics, you are fighting an oversimplification which you chose to use yourself instead of making things work as they in fact do (or as close to it as it's reasonable in a game), which approach created an unsolvable anomaly. This anomaly already manifested itself in the day/night power mode difference, for which you hacked a workaround in (reduced duty cycle during the night), but that addressed only a symptom, not the cause. This RTG issue is just another manifestation of that anomaly, and the real solution is to rethink and rework the entire power system, by eliminating the one single and fundamental flaw: the power output of the panels being defined as a unitless percentage, and what's worse, that percentage meaning a different amount depending on what the panel is installed into, instead of a real fixed charge capacity per panel.

Let me explain:

All four units draw "100%" power each, whatever unit of measurement that may represent (maybe we could call it buccaneer-samurai, and then we aren't even accused of, erm, borrowing that name from elsewhere ;), to work per any chosen time frame or "tick". During the day, it needs to come from the solar panels (or the RTG), during the night, it needs to come from the battery. However, the battery also needs to be charged during the day so that you can take this 100% per system out during the night too. This means that during the day you actually need a total of 800% power per tick, 400% to run the units, and another 400% to put into the battery. And that 800% (or close to it, due to the aforementioned hack covering some of what's missing) is actually what's being generated, only it's reported as 4x 100%. Oxy, heat and water generate 3x 100% with 3x 100% panel input, while electrical generates (by my guesstimation) 500% with only 100% panel input.

And this is the anomaly itself: a large panel generates "50%" power when installed in oxy/water/heat, but it generates "250%" when installed in electrical. And the RTG does the same, except it generates that both day and night, so a single RTG effectively generates "500%", being able to cover more than all units combined need.

And the solution is to move away from this unitless, percentage based power scheme, and actually measure the power draw of the systems, and the power generation of the individual solar panels, in a very specific power measurement unit internally; you can still display the supply/demand in percentage to the player, but those percentages result from calculations done based on comparing the actual and specific power units produced and consumed in the background.

Here's how it could work:

Each system consumes 100 units per tick when turned on. This means that each needs to have a total solar panel capacity of 100 units per tick installed. But this only covers their power need during daytime when theres input. To harvest enough reserve power for the night, they need twice as much, so 200 units per tick power input needed for the duration of the daylight period. This also means you don't need the hack for "slowing down" the systems at night anymore, since instead you will simply make sure you harvest enough power to begin with. When this 200 units input is met, the system displays 100%, while internally only 50% is used locally, and another 50% is sent to the battery (when electrical is turned on and functional to manage the power flow; if/when electrical is not running, the excess is not sent to the battery and simply lost). Battery capacity needs to be large enough to hold 400 units per however many ticks are in the period of time when panel output is not at 100%, or preferably even larger to allow "overcharging" to store reserves for short power outages.

However, since power generation is not uniform throughout the day, the total power units harvested will be less than needed for an entire day. The simplest solution is to just offset the power used vs. power sent to storage ratio to, say, 90/110, so that while input is not yet 100%, the missing amount is still drawn from the leftover reserve from the previous day (since you know the actual numbers, you can make a better estimate of by how much the effective mean power generation is lower during the day, as in, ramping up from 0 to 100%, staying there for a while, then dropping back to 0, which will result in a mean value of something less than 100%, and that is by how much the used/stored ratio needs to be offset). Then there's a 5th "system" which may also need to be charged: the EVA suit when the player is in the Hab, so let's spread it's overhead across the 4 systems and set, say, an 85/115 used/stored ratio for each (creating a 20 units / tick charge capacity for the suit).

Now this means that we have an 800 units power pool per tick to fill: 340 units is to be consumed to run the systems, and 460 units is to be sent to storage (of which 20 units may get sent into the suit instead). From the side of power generation, it's a total of 800 units input needed, 200 per system, potentially spread across 5 solar mounts per system. If we want to keep the current panel amounts, then it means a large panel supplies 100 units (50% of 200), a small one supplies 60 (30% of 200) and a portable supplies 40 (20% of 200, tho I think the portable should be less, as it's not even half as big as the small one yet provides 65% of it's output; 20 units/10% would fit better to its size, which would be perfect when conisdering we set aside 20 units for the suit, so when the portable is used on EVA, you indeed get 20 units from it). The power output (in units) of the panels then would get reduced by local light levels as dictated by time of day and storm density. And an RTG would provide 85 units per tick, day and night, so this system, if powered only by the RTG, would be "power neutral", it would not produce charge nor draw from the reserve.

Now, this approach still has one simplification in terms of how the power state of the systems is displayed: 100% means the system actually gets 200% input, 100% to be used and 100% to be stored. When running on panels, this wouldn't really be an issue, but when an RTG is installed, this would result in showing only 42,5%, even tho that would be correct: with panels, it's 100% (200 units) for half a day then 0% for the other half, with the RTG it's constant 42,5% (85 units). If needed, this could be addressed by splitting the power display into two values: local and charge. When the solar panels start generating power and their output goes from 0 toward whatever the maximum installed is, it would first increase the "local" display to 100%, then once local demand is met, the excess harvested would get directed to the battery, so "charge" would also start to rise to however many units are actually provided. For example, 200 units worth is installed and it's early morning with only 30% panel efficiency at the moment, so it's only 60 units provided vs. the 85 units needed to run just the system with nothing left to send to battery (the missng units would be actually drawn from the battery, and thus the system would be in "yellow" state), so it would read as "Local: 70,5%, Charge: 0%". Later in the day with 80% panel efficiency at that time of day, you have 160 units provided so you have the local 85 (85 out of 85) covered and have another 75 (75 out of 115) to send to battery, so it's now "Local: 100%, Charge: 65%". And then the RTG would always just show "Local: 100%, Charge: 0%" as it generates constant 85 units, 85/85 local use covered with 0/115 for charge (and if you had panels added to that, then the panel output would just change the charge value based on current efficiency).

All this would also make it possible to individually differentiate the power use of the 4 systems, to reflect what would be "realistic" for them, instead of a uniform power consumption. You could "weight" the systems differently so that they still add up to a total of 340+460 (use+battery charge), but by running/not running one or the other you could save more or less power, for example, during a storm. One possible weighting could be 55 units for electrical (hab lighting, airlock, computers, all the other appliances inside), 75 for oxy (mostly pumps, magnetic valves, the electrolysis unit, control electronics), 115 for water (pumps, control electronics, and some heat generation method for melting the ice which needs a lot of power) and 95 for the heater (control, air compressor/pump, and the heating elements which are again high power components), while their excess could simply be uniformly 115 sent to the battery, or also adjusted to result in 200 units total for each to match the solar panel capacities.

Yes, ever since the game came out on Steam, I've been constantly on the lookout for anything that may be the cause or contribute to this, but as you said, it feels totally random, there was absolutely no pattern I could identify nor any control action that seemed to make it happen more or less often.

The frequency of occurence is also random, sometimes I hardly get it at all over a 2 hours long play session with similar frequency of interaction as in other sessions, while other times it happens a lot, like in several interactions in a row right after another.

That's also why I didn't post about it before, non-reproduceable issues being practically impossible to track down and fix, and this one appears to be such.

I wonder if switching to another, maybe user written/improved module/plugin for the same purpose would be a viable way to test or attempt to solve this. In a rather complex Unity game I have followed the development of, they had to do that a few times to address issues they couldnt fix by sticking to what they've been using until then (mostly being stock Unity modules, as I recall), even tho it meant an extensive rewrite of a lot of related code to accomodate the new module they switched to.