User:Folix/DeltaPowerNetwork

This wiki page is about the PowerNet replacement being designed by folix.

History:

2015: Folix found the old code in November of 2015. Due to the number of changes, the framework is being simplified and reapplied across the code base.
2014: Folix worked on this replacing the powernets in 2014 and was nearly finished in October of 2014. Due to a RAID failure and data loss the effort was put on hold.

Terms:

PowerNode - Anything needing to use power will have an object called a PowerNode. It is configured to produce / consume power.
PowerNetwork - Contains a collection of PowerNodes. Is responsible for turning on and off PowerNodes based on Supply and Load.
PowerDefines - Contains functions to interact with PowerNode and PowerNetwork so that future changes to the base system will only require updating a function instead of every machine that accesses the PowerNode directly.
Dynamic Generator: A special PowerNode that will adjust its output based on the PowerNetwork's demand.

Key note: It is very important that machines don't change PowerNode and PowerNetwork values directly because it will mess up the delta math.

Why replace power nets?

Machines currently each process their own power per each tick when the machine is processed. Some machines are only in this processing loop because they need to process power and to check if they are still on. By replacing powernets with a more set it and forget it approach, the machine sets the power it wishes to use, and then is notified by events that its power has changed. This event driven approach eliminates the need for many machines to be processed each loop.

Old vs New

O: Machines remove or add power to the powernet per each tick.
N: Machines set their power they wish to use. Manual add and remove power procs have been removed except for some objects like cells. For cells, an adapter is used to manage them.

O: Every powernet is processed via the machine processing loop.
N: Once a PowerNetwork reaches a state where every one of its machines is on and the power coming in is not changing, it is automatically removed from the PowerNetwork processing loop.

Centralized behavior:

Each machine interacts with its PowerNode object for power processing. This means that all power calculations are performed within a subset of files. If a machine needs to directly interact with its powernode, then Functions are used to describe that behavior. This allows for updates to be made to the powernetwork later without having to edit every machine because only the function calls need to be updated.
Machines mostly don't interact with their power node after they set their power demand.

Code behavior changes:

Cables no longer have several connect "some direction" for linking wires. This has been replaced with an auto wire call that does all the linking automatically.
Shocking wont remove power from the PowerNetwork. I started out by creating creating a PowerNode so that it could remove power, but all this would do is isolate the PowerNetwork and cause all the machines on the network to have to start back up. One per tick. A joke was made that throwing an assistant into grills to be able to crow bar doors open would be the new meta. Instead of removing power, damage will be calculated based on the current supply to the PowerNetwork.
Shocking from a cell will drain the cell.

Machines:

Machine will draw power from the area's PowerNetwork. An aditional PR is needed to change machine parts to have a "WiressPowerReceiver" part. I want it to be possible for a machine to have multiple sources of power, like, being able to grab from the wire if it is directly connected, or from the area if it has the wireless receiver. Making these modular would add additional game play opportunities, like putting in a wireless receiver into a NPC or PC robot so it can draw from the area it is in. Further discussion will be needed before I modify machine part lists, so this will be left to a later PR.

Solar:

With the new system there are several different ways to manage solars. I'm not sure what way is the best so I'll list the options.
- (Most CPU intensive, mimic old way) Have the solars process each tick, updating their generated value.
- Let the solar tracker be the generator where it multiplies its output based on solars connected.
- (Least CPU) Solars becomes a non changing output. Ignoring sun position. This means we wouldn't need a solar tracker. they can be attached to a sms or main power grid without causing additional CPU load
- Change solar so they produce a static power. Change the concept so adding a solar tracker will improve the efficiency.
I expect the solar behavior will be an area requiring discussion, so I will start out with option one to mimic the old behavior. After that, another PR can be made to update solars to a new system.

SMES:

SMES will no longer manage their own power the way they do now. Currently they act like a cell. With the new system, each cell in the SMES is in an internal PowerNetwork and will actually be used to store and retrieve power. (SMES logic isn't finalized yet)

APC:

APCs no longer will be the power source for the machines in the room, however the APC will still maintain configurations for those machines.
Each area will have a PowerNetwork. The APC will act like a dynamic generator to the area's PowerNetwork. Each machine using "Wireless Power" will have a consumer on this network.
Two APCs in a room would provide double capacity to the area's network.

PowerSink:

PowerSinks will use a special PowerNode that consumes the entire PowerNetwork's supply. It does this by requesting the full supply and telling the PowerNetwork that it should be the next browned out device that needs to be restored. The network will turn off all other machines in order to turn the PowerSink on. In the back end, two power nodes are used. The dynamic generators will attempt to output more power to meet demand. The PowerSink will increase its draw to match the new supply.

Static vs Dynamic Power:

Machines that remove random power will be change to static. The goal here is to let the PowerNetwork hit a non changing state so it can automatically be removed from the power processing loop.

Shield Generators:

They currently get power from adjacent. This complicates the system. I'm thinking that maybe i should create a virtual internal network... In this case, the old system was so based on random numbers to hold in the singularity... if they run like normal machines, then wiring them up directly would work, but this machine is only powered indirectly. I will need to think on this. Maybe change it so each one is truly running on a battery as that is the old system and batteries are old style of logic.
- Shield Gen: rand(50,200) -> 125

Areas of Risk (Areas that require more testing)

I need to do testing around cutting Wires. When a wire is cut, each path should generate a new PowerNetwork.
When two wires are connected, the wire lead with more PowerNodes within its PowerNetwork will consume the smaller one.
When a machine is dismantled, it needs to clean up it's PowerNode