With greater reliance on auxiliary power level settings for science skills, the lack of a “science mode” power preset is more noticeable. For mouse-averse captains, this bind statement provides functionality similar to the existing presets:
/bind F12 “Genbuttonclick Powerlevel_preset_3$$GenSliderSetNotch Powerlevel_Auxiliary_Slider 1”
Pressing F12 will invoke the “Balanced” power preset, then increase auxiliary power to 100%; other subsystems will each have about 33% power. The power management control must be fully expanded for this to work.
Hopefully Cryptic will add a fifth power preset now that auxiliary power levels are so important to science captains. Until then, I hope this helps other keyboard jockeys manage their power levels better.
Why does this statement invoke the Balanced preset?
It should be possible to explicitly set power levels in a single bind statement, but GetSliderSetNotch doesn’t work as expected; it moves the slider incrementally and appears to interfere with multiple invocations in a single statement, locked sliders or not. This might be an anti-exploit added by Cryptic because, as an article on sto-advanced.com [Power Settings, other than the defaults] shows, it’s possible to do a great many things in a single statement.
This article has been cross-posted to the STO forums; please add to the discussion there.
Unfortunately the above only works if the Balanced preset is truly balanced. STO power distribution has some problems: It’s slow enough to watch different subsystems change in real-time and the balancing algorithm is n-pass iterative if any subsystem hits a min/max cap while rebalancing. Macros with multiple power changes fire off too quickly for the rebalancing, and the algorithm causes different results for the same change based on the relative levels of other subsystems.
I’d like to see Cryptic do two things: Provide a power distribution command that takes all four levels as parameters; the code to make this work must already exist for presets to work. Rewrite the balancing algorithm to order the three subsystems before attempting to rebalance them. If decreasing the target subsystem, order the other three from highest to lowest. Reverse if increasing the target subsystem. This puts the subsystems likely to hit a min/max cap first and assures the last subsystem can handle any slack caused by hitting that cap.