The Power Grid

[alexanderson1993]

This is related to #348 and #229, focusing specifically on the power grid. As I've been working on this, I've come to realize that it's not as simple as I originally thought. Here's a proposal for how it can work. Feedback and suggestions welcome.

---

Power flows through the power grid in a directed graph, where power flows from reactors (optionally to batteries) to power nodes to systems.

Power generation starts at the reactors, which turns fuel into power. The amount of power fuel provides and the heat produced by that fuel is determined by the fuel itself, making it possible to use different kinds of fuel with different tradeoffs. So the fuel consumption rate can calculated as C = (P / F) / E, where C is fuel consumption, P is power demand, F is the power density of the fuel, and E is the efficiency percent of the reactor - lower efficiency means more fuel is consumed

So if P = 4 units of power, F = 0.5 units of fuel per unit of power, and E = 80%, then C would be 10 units of fuel.

Power demand is set on the reactor itself. The reactor has a maximum amount of power it can produce, and the crew can choose a specific amount of power that they want it to produce. See #229 for more on efficiency.

The higher the reactors load, the more fuel is consumed and the more heat is produced. Efficiency has a second-order effect here, since heat is determined by the amount of fuel consumed, not the amount of power generated. When heat is at a certain level, efficiency will begin to decrease.

Manually cooling the reactor shouldn't be necessary, but perhaps they cool automatically so long as there is coolant available. Otherwise, the only way to cool a reactor is to shut it off and let it cool down automatically.

Both fuel and coolant are supplied to the reactor by cargo transfers. Fuel and coolant stored in the same room as the reactor will be consumed by its operation.

Reactors can distribute power to batteries and power nodes. Batteries include Phaser Capacitors and Warp Dynamos. Batteries have separate rates for charging and discharging. The discharge rate is the amount of power that the battery can supply to a power node.

Power Nodes distribute power to individual systems. The number of power nodes, and the systems those power nodes supply power to, is fixed. To keep the crew's screens simple, this configuration happens in the plugin config, before the flight starts. Here's the default configuration, along with some sketches of how each system uses power and what insufficient power might cause:

Weapons:

• Phasers - Requires continuous power to phase capacitor to charge the phasers, weaker and shorter range when not enough power.
• Railguns - burst of power when fired, weaker and shorter range when not enough power
• Targeting - continuously uses a little bit of power, frame rate drops when not enough power?
• Torpedos - uses some power when fired, can't fire if not enough power.

Defense*:

• Fore/Aft/Port/Starboard Shields - uses lots of power when activated, uses more when recharging, slower recharge when not enough power
• Tractor Beam - uses lots of power when activated based on the mass and resistance of the object being towed, less strength when not enough power
• Transporters - burst of power when used, shorter range and higher risk when not enough power
• Stealth Field - uses lots of power when activated, less stealthy when not enough power

Engines:

• Warp Engines - Warp capacitor requires power to charge, needs more sustained power for each successive warp level, less power means slower speed until theres not enough power to sustain warp
• Impulse Engines - Needs more sustained power for each impulse level, less power means slower speed.
• Thrusters - Burst of power when in use based on the thruster strength, slower speed when not enough power.
• Navigation - Maybe this doesn't even need power?
• Jump Drive - Requires a charge to jump,

Intel:

• Long Range Communications - Small burst when a message is sent. Message sending slows when not enough power.
• Short Range Communications - Continuous power when communication is in progress, poor reception when not enough power (whatever that means)
• Sensors - Continuous power for the sensor grid, continuous power when a scan is active, slower framerate for sensor grid and slower scans when not enough power.
• Probes - Power isn't really needed?
• Signal Jammer - continuous power when jamming, poor jamming and less range and intensity when not enough power
• Countermeasures - continuous power when charging a countermeasure, slower countermeasure construction when not enough power

Internal:

• Life Support - Continuously on. Maybe split out into O2, Co2, temperature, and gravity. Not enough power causes O2 to drop, Co2 to increase, temperature to increase, etc.
• Main Computer - Continuous power draw. Insufficient power causes malfunctions to the crews stations?
• Internal Sensors - Continuous power draw for the sensor grid, more power use when scan is active. Not enough power causes slower scans.
• Sickbay - Increase in power use when a sickbay scan is in progress
• Security Force Fields - Continuous power draw when active, not enough power causes force fields to fail with possibility of prisoner escape.
• Turbolift/Cargo Containers - Power spikes when people are using turbolift, cargo containers always draw power when moving. Not enough power causes cargo containers and turbolifts to move slower.

Defense includes any systems that cannot be used when the shields are raised so the crew can choose between using shields or using the other systems.

To provide a bit of a challenge, power nodes can only accept two incoming power sources at once (although in practice it might be necessary to allow three). So a node could take two reactors, a reactor and a battery, run exclusively on battery power, or use a phaser capacitor and warp dynamo. This provides some degree of configuration. It should also only be possible to connect reactors or batteries to two or three power nodes/batteries.

Within each power node, the power the power node receives is distributed to each system automatically based on the amount of power each system requires at that given moment. The power node has three options for prioritizing power use:

• Evenly (fill up systems evenly until the system is full)
• Least Need First (first fill up the systems with the smallest power requirement)
• Most Need First (first fill up the systems with the largest power requirement)

Perhaps it can also be possible to deactivate a system, which makes it take 0 power. This could be a required step for certain maintenance reports.

All of this will happen on a single screen which depicts the reactors, batteries, and power nodes. Hovering over these items gives at-a-glance information about the entity, and clicking opens an overlay for updating the properties that entity.

So, in short:

• Reactors produce n units of power based on the amount of fuel provided to them.
• Reactor power is distributed evenly to all batteries and power nodes they are connected to.
• Node power is distributed to each system in the node based on how much power that system needs.

[Froginator45]

A few comments:

1. I realize that realism and gameplay don't always match-up but I have always wondered why coolant is a limited resource. I'd figure that most systems (especially in space) would be sure to use a coolant that is reusable. That way, they aren't stuck without a method for cooling.
2. Navigation. I'm not sure this specifically needs power but I could see sensors power affecting this screen. Maybe give navigation a warning that there isn't full power to the sensors and they could hit something?
3. Communications "poor reception". Maybe you implement a random character swap at varying degrees in relation to the power/efficiency level? So, with very minimal power, a message would come through as complete garbage?
4. Probes. I would say the power level for these would be the same as torpedoes. With a launching cost but free after that. Maybe have a separate probes communications? With power and efficiency levels on the ship-side probe communications? And a battery level for each probe that, when getting low, would have similar power/efficiency problems? You wouldn't normally see battery levels dropping too low but if the probes were treated like mini ships, then they could get damaged by debris and have problems that way?
5. One thing I didn't see mentioned was the ability to divert power through different conduits. Would this also be possible? Or something for a later addition?

[alexanderson1993]

Yeah, that's what I wanted to do as well. I love all of those ideas. But as I started prototyping, I came to realize that letting the crew connect power nodes to systems dramatically increases the UI complexity and makes the job miserable.

You can see it in this prototype. Note that this is interactive - if your screen is too narrow, you can scroll the systems from left to right. https://zyx6k0.csb.app

Ultimately, we're building a directed graph like so:

Reactor┌──►Battery
       │      │
       │      ▼
       └─────►Power Node───►System

The number of reactors, batteries, and power nodes is flexible, but the number of systems is not. The list I have above has 28 systems, which is a huge number to manage, especially in the heat of the moment. In the end, we couldn't figure out a simpler UI for all of that, so we just got rid of the line from "Power Node" to "System".

THAT BEING SAID! The way this is implemented in the backend gives each power node a list of systems it supplies power for. Which means if we wanted to, we could do a super big, messy UI with connections between all the things. Or someone smarter than me might come up with a better UI/UX that allows for all of those kinds of things without being overwhelming or frustrating.

All of that is still a possibility, but I'm far more confident that the proposal above will be a better user experience, and I want to focus on that for the initial release.

[Froginator45]

I see the problem. I guess I figured that you would be able to move the different boxes around to get a better organization. Because, if you were able to do that, the system side of things should clean up significantly. So, for example (using the same interconnections as in your example):

As you have said though, this still might be too complicated as there are so many systems. And this type of UI might be more complicated to implement. Maybe the systems portion is more of a drag and drop under each power nodes "bucket"? With the ability to drag a system out of a "bucket" to remove power from it?

Just some thoughts. But I see your point and I'm not sure if these ideas help them or not.

[alexanderson1993]

Ooh! I like the bucket UI a lot actually! Let's hang on to that one and add it as an advanced feature in the future. Or maybe the not so distant future? The plugin configuration needs to be in place anyway, since the ship needs a default configuration for the power grid. But maybe shortly after that's done someone can tackle this.

Thanks for taking the time to make the diagrams. I showed them to my wife who took one look and said "Oooohh, I get it and I like it!"

[Froginator45]

I'm glad that you and your wife like it. Now I just need to learn how to code better so I can help out more than just with theoretical ideas.

[alexanderson1993]

I wouldn't sweat it too much. The programming part of it won't be too bad for me, since the backend is already designed to support this. It's just a matter of when to actually implement it.

But your code contributions will always be welcome. 😁

[alexanderson1993]

This has been up for long enough, so I'm going to start breaking out the work that needs to be done into issues.

[1deejay]

It's already a part of things but to have a few systems work better with more power would be interesting to play with.

Life Support, on/off no difference.

Phasers, minimum power needed to function/ramping up power/destrucive power with %chance to damage. Plus, higher power, more over heat so it needs longer to cool down before it can be fired again.

Shields, minimum power/ramping up/overcharge which could damage the system or other systems

Each system can have it's own set of rules and risks associated with it.

[alexanderson1993]

Yep, that's exactly the idea.

How often in TV shows do they "reroute power from Life Support" (I've been watching the Orville lately, and they do this all the time)

The goal is to have the whole simulation connected, so things like that have an impact. If Life Support is deactivated, O2 levels drop and Co2 increases. Crew motivation and energy decreases, which lowers their ability to do their jobs.

This is just one example, the possibilities are endless (so long as we're able to keep the simulation processing within reasonable computational limits)

[alexanderson1993]

Coming here to say we should graph the production and consumption per reactor and per system a la Factorio.