Skip to content
This repository has been archived by the owner on Jan 6, 2022. It is now read-only.

On the topic of power (and O2/H2) distribution #580

Open
PyroVortex opened this issue Mar 17, 2017 · 4 comments
Open

On the topic of power (and O2/H2) distribution #580

PyroVortex opened this issue Mar 17, 2017 · 4 comments

Comments

@PyroVortex
Copy link

PyroVortex commented Mar 17, 2017

Current Algorithm

The current power distribution algorithm works as follows (more or less; this is somewhat simplified):

  1. Add up available power from all sources
  2. Assign available power to sinks in decreasing priority until we run out of power or sinks
  3. If we have power left over, (in theory), reduce load on sources according to priority.

This algorithm prevents a number of desirable behaviors (though they may be accomplished in theory via programmable blocks or mods):

  • Have some set of machinery that will only run on solar power, never battery or reactor
  • Have batteries only provide power to other batteries when very specifically requested, e.g. for quick charging a vehicle from base power

Proposed Algorithm (breaking change)

Rather than having power sources have a priority (where higher are used first), they should instead have a cost representing how important a sink has to be to draw power from them. Sample reference costs:

  • Solar: 0 (it's free, and we should therefore always endeavor to use all of it)
  • Battery: 100 (charge/discharge has a tax, and it is in finite supply at any given time)
  • Reactor: 200 (battery power is cheaper, provided that it came from solar)

We then assign a value to any given sink, indicating whether or not it is worth powering from any given source, as well as its priority relative to other sinks. This is very similar to the existing priority for sinks, but on the same scale as the source costs. Sample reference costs:

  • Occupied cryo pods: 250 (we want them to never lose power)
  • Refineries: 150 (may not be worth running the reactors for, but probably worth drawing on the batteries to run overnight)
  • Charging a battery: 90 (not worth using battery or reactor power for, but probably worth more than most things that only run on solar power)

Algorithm

  1. For each discrete source cost, compute the total power available at that cost. Using the sample numbers above, this would mean that:
    • 0: solar
    • 100: solar + battery
    • 200: solar + battery + reactor
  2. Iterate over sinks by decreasing priority and attempt to power each one, adding its needs to the current total. If the current total power consumption equals or exceeds the power that is available in the current cost bracket, then all lower priority sinks get no power. This means that, for example, if your refineries exceed the total solar power output, but not the battery output, anything of lower priority than 100 still receives no power, since the solar output is being allocated to higher priority items (the refineries and anything above them).
  3. Allocate the total power consumption computed in step 2 to sources according to increasing cost.

Configurability

Although we should endeavor to provide sensible default costs and priorities for sources and sinks, making the values configurable on a per-block basis (whether via programmable block scripts or the UI) would give players an extraordinary amount of control about how their power gets allocated for minimal development overhead. If you want your rover to charge from your base batteries, give its batteries a higher charge priority than the base's battery power cost. (Note that any individual battery must always have its cost exceed its charge priority). If you are operating a ship that only has reactors, your power priorities will most likely be different from a station that runs on solar and batteries and only has reactors for emergencies.

Configuration would also allow for scenarios such as a vessel that runs primarily on reactors, but uses batteries for burst power.

Other effects

Under this algorithm, "stockpiling storage" (e.g. a battery with the charging flag set) is simply storage for which the source cost has been set to Infinity. A battery with the discharging flag set has a sink priority of -Infinity.

Edit: Added "other effects" section

@Pingger
Copy link

Pingger commented Mar 17, 2017

I like that ... would simplify my base extremly
What about making power source priority also configurable by the user?

@PyroVortex
Copy link
Author

Simplest implementation would be to have source cost and sink priority be the same thing for storage devices, on the condition that power draw only occurs when priority > cost. Then there would only be one value to configure on all blocks for any given resource.

There is a single edge case I can think of where you would want to be able to configure source cost and sink priority separately, which is if you wanted to trickle charge your storage, but that can be worked around by installing a storage buffer at a lower priority in the system, then using it to charge any higher priority buffers once it has sufficient energy stored.

@Pingger
Copy link

Pingger commented Mar 19, 2017

My Idea was, that I have my main Reactor that powers my whole base, but when it runs out of power, a secondary reactor engages and only powers the MedBay (example)

@JamesK89
Copy link

I would like to see a change to a system where everything is manually connected. Maybe like a metagrid that is normally invisible but in wire edit mode you can place and remove wire connections that are inside armor blocks. Maybe to even make it more interesting basic electronic circuit symbols could be added so you can have power only travel in one direction (diode) or have power build up at any one point and then discharge (capacitor) etc...

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants