I don't know. Removing their upkeep takes away from the power management mini-game for speed builds. My recent runs were very reliant on those processors and part of the fun came from figuring out which subset of them should be on in order to maximize utility while minimizing power deficit. This could be because it is truly fun. It could also be because I have the soul of an accountant 
.
This is a good point, a comment which I've heard from several people now, actually. For some it's fun, and Decker's camp it's tedious and possibly error prone.
I'm more on the side that says this is a part of the game, proper management of your parts.
I also see decker's point of view having lost many games due to propulsion mishaps where I left some of my stuff off and this an annoying way to lose a game.
I've tried to make this as obvious as possible with the big glowing indicator in the corner, but it's still sometimes possible to miss. I think a better alternative solution here would be to require confirmation before your first move that will be slower than something like 300 (in which case you're probably accidentally overweight).
What if: when enemies are not in view and not actively chasing you (or haven't been seen for X turns), upkeep for certain items is removed so that you don't need to toggle many items in and out of fights?
This would result in some complications when enemies can see you but you can't see them, meaning a sudden change in your upkeep would give away information.
@Decker: The loop could work under a simpler system, but there are still caveats and exceptions here depending on what parts you have, including utilities. Some of them act like power sources, generating energy from matter or even heat (or even something else no one's encountered before because it's not available yet).
Probably a bigger problem that makes this complex and unintuitive is the fact that upkeep is accounted for once per turn, while movement and other actions can take anywhere from a small fraction of a turn to multiple turns.
Another complication I just came up with based on external factors: Say the system says you don't need to have all those heat sinks active because you're not generating quite enough heat to matter (whatever threshold that should be, 300?), then you're suddenly shot by a squad of Grunts and your heat spikes due to the thermal transfer and disables some of your parts. Heat dissipation is also more complex by itself because it now occurs over multiple turns.
For me, this sounds like it would make play more difficult because it reduces the transparency of the whole energy/heat/active part balance. You'll have a harder time gauging your limits with a given loadout. Overall, I think this might be doable, but probably still isn't worth the investment since it's not unquestionably better in nearly every case but would take quite a while to get right (implementation-wise).
That is another thing that would benefit from power gating -- often you move faster by deactivating parts.
Since the changes in Alpha 5, this is only true if you are simultaneously equipped with multiple forms of propulsion, in which case added management is a natural side effect. (Unless you're referring to flight/hover situations where you need to deactivate non-propulsion parts in order to active and power more propulsion, but again this is the management game.)
My preference here is to introduce meaningful reasons for keeping them activated. So as of Alpha 7 you'll get a +5% dodge bonus while hovering (if not overweight), and being overweight will also cancel the benefit of Maneuvering Thrusters.
Heh. That makes sense and I like this change. But that won't change the situation for a combat bot where you're overweight by design (it's still better to switch to treads for recoil reduction and less upkeep).
That doesn't seem relevant to this particular discussion, since it's a strategic decision you have to make manually.
... wow what a major change! I don't know what to think. It would solve the on-and-off issue of some parts. It'd also be more realistic. Targeting computer draining 8 power? My old 386 drains less power and can do 10x more work
Absolutely, that's why I've thought of making that change many times--it was introduced purely for balance purposes, and it does a good job of that. It'd be a pretty drastic change...
Note that if you don't change the upkeep for all other offensive parts (armor analyzer, particle charger, cloaking, etc.), the problem will remain -- you need to deactivate those to move and scan/map.
I'm just looking for ways to potentially mitigate the issue where possible so that it's less annoying for those who care, since it's highly unlikely there would be a perfect solution that works across the board.
-- and I finally finish typing all that and you have another post --
As Sherlockkat said, optimizing within a state is fun. It's the cross-state optimizations that are problematic.
I can see this as the case, and you are pretty much the only player I know who tries to optimally play an extreme hybrid good at everything. So it's easier to reach those limits.
1) Remove most time-based upkeeps, replace by pay-as-you-use (on attack/move/defend). Sensors are free. ECM, jammer and armor use time-based upkeep.
Multiple meanings of upkeep are best avoided.
2) Sensors / terrain scanner are considered processors to prevent the swap cheese.
But they're logically devices, and not processors, so I'd like to keep them that way. I really don't mind the swapping since there really aren't that many things that truly need to be swapped.
3) The tread bonus applies unconditionally (a well-known side effect of weightless treads).
If you mean the recoil benefit, that would be unfair because then you could carry a single one as a flier just for the bonus, and get dodge bonuses as well. I'm already annoyed that you get the benefit of coverage and integrity from those extra unrelated propulsion parts, and I've been of a mind to zero or vastly reduce the coverage of inactive propulsion to avoid that cheese. You've narrowly escaped that so far.
Analyzing further, the root issue is the frequent transitions between two states (explore/combat) which have very little in common.
This is certainly the crux of the issue, but the mechanics of the game aren't compatible with the usual solutions for something like this you might find in a game. Setting a swappable "kit" would be one of the more common approaches, but your build can change so quickly it wouldn't be worth setting up.
