Okay, so I've implemented a half second delay before datapad navigation/submit inputs are allowed after any input that would trigger the datapad to come up. So this prevents UI elements from getting pressed before you can see them on screen (that's basically what was happening). The half second is effectively the same amount of time it takes the datapad to be visible, so it shouldn't feel like a delay at all. Will be in a patch soon.

Somehow the LMB click was still enabled during the time fast forward transition and this appeared to be the linchpin of the issue. I've fixed that and now I believe the resulting weirdness cannot be triggered. Will have the fix out soon.

It's not so much queuing the inputs as it is just screwing with the order of operations by clicking quickly like that. Something I don't experience much because I don't often use the LMB as a submit input. I can put in accommodations to prevent this. I'll try to get in a fix before I leave to visit family for Thanksgiving.

To clarify, you still cannot charge from any connected solar panels from other modules if the electrical module is turned off (since all power routes through it), but the electrical module will no longer be considered turned off when there is less than 1% of reserve power.

Okay, good catch. I've made the following change. The electrical module will now be able to charge from its own solar panels so long as the power switch to the unit is on and its required components are operational. It will no longer require a reserve charge since that doesn't make much sense. No requirements for the other units have been changed. Fix will be out soon.

I left this functioning on purpose with the thought that you could leave the portable panel outside the tent with a cord of some kind. That's reasonable right?

I had erroneously enabled a checkbox labeled "Mouse Input Supported" for the input system that I'm using, thinking it would be necessary if I had actions assigned to mouse buttons, but what is actually happening is that it is interpreting the mouse location and thinking that it is not over a button when it is pressed and so you are effectively not clicking on the button. Disabling that checkbox seems to still allow the mouse button to act as an input without using the mouse pointer location and has fixed this issue. Thanks. I'll get the fix out soon.

I've made a couple other fixes before I checked on this one and now I can't recreate it. You'll have to let me know if the next update fixes it for you or if there is something else that might be triggering the issue.

Oh boy. The Law Of Unintended Consequences. Guess I never caught this because I'm just trained to not even try moving while interacting with elements that would normally limit your movement. Caught the issue though and I should have a fix soon.

Took another look at this thread and you're right. I marked this as fixed even though I fixed an issue that wasn't actually part of the OP report. I haven't been able to reproduce the OP issue however. I'll open it back up and see if we can find a way to more reliably reproduce it.