Power system discussion

Been a long day for me as well. Also, I've been trying to help Danice with a particularly nasty stack overflow problem, but the trace becomes so labyrinthine that it becomes hard to tell up from down, much less which part is the logic bug. At this point I'm thinking it might be easier to start from scratch and represent the power grid as your standard graph model rather than try and stick with Notch's cellular automata deal.

I'll work out some pseudo code for tomorrow.

Pseudo code I can understand. If you need to post technical information, please write it in pseudo code. I understand more pseudo code than jargon.

"The first text book on graph theory was written by Denes Konig, but this book was very hard to understand."
Thank you wikipedia...
If your thinking about starting from scratch with the system, then you should just point me in the right direction and then let me do it . I mean, this is my project, and I don't want to distract you from your other very important work.

Well the idea is that each device is a node on the graph, and each edge is some string of wire, who's weight is the length of the string. Then it becomes much easier to manage everything passing between them all without re-tracing the wires every tick. The only times you would ever have to work on the block level is building the power net the first time and monitoring any breaks or additions on the existing wires.
It's a little tricky because you'd need to account for forks and loops in the wire, but I can give you pointers on how you might do it. In any case it should be much faster and easier to maintain.

Almost couldn't find this post again. Maybe we should use Danice's dev thread for discussion about his work rather than spamming it with silliness.

But whatever. I drafted a few plans for how a power net would work, but it turns out the methodology changes a lot depending on how it's set up. For instance, you can't assume that power is only going to flow in one direction, or that a device is getting power from one source. So that brings up some important questions:
Are we still doing power tiers? If so, how do we step up and down the current? Do we wire it realistically like with series and parallel changing the voltage and resistance, or is it simplified and if so, how? Do components simply act as endpoints, or do they allow pass-through of power to other lines connected to them? What about batteries? Do they simply keep the voltage in the system constant or will they work some other way? We need to talk more about balance in power plants, too, though that's a separate issue.

I'm realizing this is all more complicated than I first suspected. We could pretty easily emulate the way industrial craft does it with packets, but the whole packet system really doesn't make a lot of sense. I have no idea how blutricity's version does it (guessing more realistic power simulation). Stuff to decide.

I moves this into a seperate topic! Yay for being a moderator! ahah

Unfortunately I have had no experience with graph theory up to this point, so I'm a still a little confused as to how this would work, but I think I see what you getting at. I think most of this depends on our definition of a 'power system'. Is this simulating real electricity or is it something else? This is minecraft, so it doesn't have to be real to life. It may just come down to what is simplest to use within minecraft, you don't want to have people struggling to figure out your power system.

Ok I've thought up some semi-pseudo code, is this along the lines of what you were thinking?

Code:

    public void onBlockAdded(World world, int i, int j, int k)
    {
    int adj = 0;
    for(int a = 0; a < 4; a++)
        {
            int x = i;
            int z = k;
            if(a == 0)
            {
                x--;
            }
            if(a == 1)
            {
                x++;
            }
            if(a == 2)
            {
                z--;
            }
            if(a == 3)
            {
                z++;
            }
            if (blockID == world.getBlockId(x, j, z)) {
               adj++;
            }
        }
    if (adj > 1) {
       getNetwork(world, i, j, k, i, j, k, 0);
    }
    }

   public void onBlockRemoval(World world, int i, int j, int k)
    {   
    for(int a = 0; a < 4; a++)
    {
        int x = i;
        int z = k;
        if(a == 0)
        {
            x--;
        }
        if(a == 1)
        {
            x++;
        }
        if(a == 2)
        {
            z--;
        }
        if(a == 3)
        {
            z++;
        }
        if (blockID == world.getBlockId(x, j, z)) {
           getNetwork(world, x, j, z, x, j, z, 0);
        }
    }
    }
   
    private void getNetwork(World world, int i, int j, int k, int i2, int j2, int k2, int p) {
       p += checkPower(world, i, j, k); //checks input/output and changes power level
       for(int a = 0; a < 4; a++)
        {
            int x = i;
            int z = k;
            if(a == 0)
            {
                x--;
            }
            if(a == 1)
            {
                x++;
            }
            if(a == 2)
            {
                z--;
            }
            if(a == 3)
            {
                z++;
            }
            if (blockID == world.getBlockId(x, j, z)) {
            if (x != i2 || j != j2 || z != k2)
            {
               getNetwork(world, x, j, z, i, j, k, p);
            }
            }
        }
   }

basically at the end of this you would find some way to store the power value... no wait, different strings would end at different times with different values... shoot, well maybe something similar to this would work.

I was thinking something a little more pseudo than code.
First, lets go with the simplest power version: You have sources which produce power and devices which consume it. Everything along power line is accessible from anywhere else on the line.

Code:

PowerGrid:
List sources
List devices
netPower

calculateNetPower()
{
netPower = 0
for all source in sources
   if source.active == true   
      netPower += source.output
for all device in devices
   if device.active == true
      netPower -= device.cost
}

activateDevice(device)
{
if devices.contains(device) AND (device.active==false) AND (device.cost < netPower)
   device.active = true
   calculateNetPower()
}

registerDevice(device)
{
if devices.contains(device) == false
   for all block in device.neighbors
      if block == PowerGrid.wire
         devices.append(device)
         return
}

This is more what I was talking about. Really simple, focusing on description rather than a specific language. But lets go over this:
Here there is only one power grid, with the wire blockID registered under it. So long as a device is touching a wire it is connected to the grid even if the wire itself is not connected to anything else.
You can only activate a device if there is enough net power left in the system to support it.

It's very simple and very flawed, but it's a starting point. From here we need to address the features and shortcomings of the system, and then propose, one element at a time, what should be changed and how it will affect everything. So lets do that now.

Here are the immediate problems:
1) The wire system is too simple. We need a way to register every piece of wire with a specific power grid, and do so efficiently. (this will probably be the next part I talk about)
2) Devices are limited. You can't activate a device at all if the power is not there. How do we want to handle insufficient power? Perhaps some devices fail to operate while others run at reduced output. Perhaps when the grid is overloaded everything on that grid shuts down until you amend the situation, devices shut down in ranked by importance.

Here are problems in the foreseeable future:
3) Wasted power. There are no batteries or capacitors, so everything not spent is simply lost.
4) Varying power levels. Some devices will require more power than others. Are the power lines all superconductors, or is there a limit to how much current can pass through any single line. If so, how does divided power behave?
5) Level of realism. A well-wired ship will have multiple power sources and redundancy in power delivery. Should we be calculating the flow through all of those wires, or is "on-the-grid-therefore-powered" good enough? (I can show you how to do that if we want to go that route).


1 and 2 should be addressed first, but the answers to 3, 4, and 5 may affect how we go about that.

I created my system basically how yours works above... without having seen it lol. But instead of one huge network, the wire basically creates its own and writes the value to each piece of wire's tile entity.

1. my network creating code is:

Code:

OnCreated
{
power = createNetwork(self)
}

createNetwork(object)
{
power = getGeneratorOutputAdjacent
power += createNetwork(adjacentWires)
return power
}

On destroyed, the block activates each adjacent wire separatly, which allows for multiple networks to form. This code is also activated when a generator is placed next to wire of course.

2. If the power isn't there, the power isn't there. My system will block the newest machine added when overloading the system, and idk what would happen when a generator is removed. EDIT: Just added this, it will turn off the closest machine to where the break happened that goes over the limit.

3. batteries are simple, a block that receives power in one end and outputs it in another. It stores energy and outputs it only if you tell it to. Also backup batteries could have the same input and output, but only transmit if there is no input. Consider the value of the wire network as power per tick.

Ohh and I fixed the loop problem. just set the metadata to one when a block is checked and reset it when it was set.

*edit*
Looks like Danice posted something while I was writing this. I'll leave it, but we'll go over your stuff first.


Changed my mind. Gonna talk about how blutricity works first. Asked around on IRC and took some notes.

Blutricity, as far as I can tell, does the power balancing deal, in which power flow is optimized over every single path, but instead of calculating it all at once, I think it use the less efficient balance power across every wire block method. To avoid lag spikes it only does one balancing pass per tick, getting the power levels evened out over time. Devices themselves have internal batteries which are charged from the power grid. As their battery power dies down, devices may become less productive and draw less power from the grid. Also, there are batteries which hook directly into the grid and act as a buffer. They can collect energy at 100V and output at 80V, so you have to make sure you have sufficient bandwidth there.

That's a decent way of doing it, but I would change a few things. First, if the system is block based I would change it to graph-based. This makes calculations far more efficient, as well as being less complicated to modify since you aren't actually passing any messages along blocks or making them store intermediary data. Second, there should be a way to prioritize or divert power to specific systems. For instance you don't want life support going down because you have too many furnaces running.

Just thought I'd put that out there. Blutricity is a decent system, and intuitive to set up, but I think we should take advantage of our supposedly fancy technology and step it up a notch.

I had a decent idea for electricity, but I can't provide any code samples because I don't know java.

Heres the idea: we model power, as pressure. Generators are 'compressors' (they create pressure), wires(pipes) 'leak', and devices are like a hole in the 'pipes'. Devices have a 'valve', and pressure can be prioritized by expanding and contracting the valve.

This achieves a few things. It is significantly different from BC's, IC's, and RP's electrical systems, it solves the issue of prioritizing, and theres plenty of room for optimization. Downsides? It could be a pain in the out-hole to code.

@Danice
The way your wires can join or split up a network is a good start. We can do more with power transfer in a bit.

First of all, the stuff below is a description of how I think we should do power. It's not necessary to do it this way but it does have some advantages. The important thing is just that you understand how it works and why it was designed that way...

First thing's first. If we made the network graph-based, then the wires determine the structure of the graph, but are not actually used afterward to calculate power flow. They are symbolic. This makes it fast and (relatively) simple to modify the corresponding power algorithms. But lets talk about graphs a bit, since you said you haven't used them before.

At its simplest, a graph is a collection of points called nodes or vertices connected to one another by lines called edges. Depending on the problem, either the nodes, the edges, or both hold additional information. For a flow network, which describes how power flows over a network of nodes, all work is done on the edges, which will hold two values: flow and capacity. Flow is how much power is traveling through that edge, while capacity is the maximum amount of power than can be sent through. More on that in a moment.

For our purposes an edge in the flow network is defined as a single uninterrupted, undivided length of wire. When a wire forks off in two directions, that is a node with 3 edges. Up to 6 edges are possible, but 3 will be the most common. I mentioned capacity before. If we are doing infinite power through every wire, the capacity is infinity, and this approach is pointless. But if wires can only carry a specific amount of power, then this is really useful.

I'm going to skip ahead a little bit to show the final result.

This is a flow network representing a simple power setup. Here the (1) nodes are power generators and (2) are powered devices. (0) is called the source and (3) is called the sink. The reason for these is that the max-flow algorithm requires a single start node and a single end node. For us that just means that all power sources connect to (0) with the edge capacity being however much that source produces. Same for the sink side. In this example, both generators have a capacity of 10, and both devices have a draw of 10. However, because one of the wires only has a transfer capacity of 4, the upper device is under powered. But because of that, the lower generator does not have to run at full throttle, which saves you fuel. This is just one possible configuration. The bottom generator could produce up to 9 units of power while the top just produces 5. Deciding what to do in the cases where this is a surplus or deficit of power is another matter which should be discussed at some point.

I won't discuss the algorithm that built this yet. I'm actually still researching it. But I will talk about wires, which is the more immediate element anyway.

When adding new wires to a powered network, there are 3 (nonexclusive) possibilities:
1) You are appending a wire to a single network. If you are adding to a loose end which doesn't go anywhere else, nothing in the flow network changes. If adding the wire piece creates a fork, then in the graph you create a new split the corresponding edge and create a new node, and append your new edge (wire) to that node. Alternatively if you are adding the wire to an existing fork base (3+ wires branching off instead of 2) then you just add a new edge to that node.

2) You are bridging two wires within the same network. Connecting edge A to B results in a single edge C which is shared by the node A and B are connected to, respectively.

3) You are bridging two wires between separate power networks. Same as 2, only you additionally merge the two source and sink nodes, resulting in one giant network.

Because edges are straight pieces of wire and nodes are forks (or devices), to determine which edge(s) you are connecting to, it's as simple as tracing the wire back to the nearest connected fork/device. A hashmap would then associate a node with that particular location.


So, thoughts? Again I'm just putting this out here to see if folks are interested. We can certainly do infinite wire capacity a whole lot easier.

Maybe that could play into my idea, idk im tired to understand that its nearly 3:30 am. What did you think of my idea?

Your idea is very close to what I wrote, albeit more abstract.

Asking: Fr0stbyte, you did see my most recent post on *classified*, didn't you?

Dr. Mackeroth wrote:

Asking: Fr0stbyte, you did see my most recent post on *classified*, didn't you?

Yes, I did. It satisfied my curiosity for the time being, but this is just the start.

So basically with this you add the functionality of allowing machines to run under powered and generators to conserve fuel, plus the limits of how much power passes through a wire. My only question is that what happens when a wire forks without a fork? And the problem of keeping track of what machines are connected to what and where comes up. And if capacity comes in to play, are there going to be different types of wires then?

Danice123 wrote:

what happens when a wire forks without a fork?

I have no idea what that means. A thought just occurred to me, though. Dead-end wires wouldn't actually be edges in the network graph, since an edge requires precisely two endpoints. They would only become an edge once there is an additional fork or a device is attached. Otherwise same rules as before.

Quote :

And the problem of keeping track of what machines are connected to what and where comes up.

That's actually one of the advantages. Since they are symbolically linked, it doesn't matter where they are physically. And if you need to know which a particular device is, you can access it from both the network node and the hashmap. Remember that all devices are 1 step from the sink node, and all power sources are one step from the source node. Those are essentially your two lists right there.

Quote :

And if capacity comes in to play, are there going to be different types of wires then?

There doesn't have to be but the system will support it if it is. All that would happen is a new node is made where the two wires join and either edge has a different capacity.

That first question didn't make sense lol nvm. Okay I finally see what your getting at. The problem is... I don't even know where to start with this haha

Yeah I was afraid of that. If it's going to give you a hard time it's not worth it. A shame though, if you were taking Data Structures II in college this would have made for an fantastic course project.

For now, lets just assume infinite wire capacity, and therefore connectivity = power delivery. I don't like the idea of making every piece of wire a tile entity, though; they are much less efficient than normal blocks. How about devices count as additional wires, and every device and wire in a connected power grid gets their position stored to a hashmap. Then when you add a new device or wire, you just check the neighbors to see which grid those belong to. If it is multiple grids, then you merge the two hashmaps into one (easy to do).

Splitting would then require rebuilding the two hashmaps, though there is the possibility it rejoins elsewhere, in which case you can abort the split.

Power distribution is still a problem if there is not enough to go around, but then again it was in the other system too...
Does that sound more manageable?

You could put a bottleneck in your wiring design to save power, like I did in Industrialcraft. It worked fine, but the machines were constantly flickering on and off and made loud annoying noises constantly. That seems like the only issue. I can't see a problem with adding a slider that controls power flow from 0% to 100%.

Wouldn't work in the revised system, because power is not actually flowing through wires. However it should be possible to manually throttle devices to use less than maximum power.

Umm here's the problem. As I'm still in high school, I know very little, as I have taken no formal classes in anything programming related. So when you say 'hashmap' I draw a blank. I understand the concepts of what your saying, but I lack the knowledge to implement most of it. But on the other hand... I'm a fast learner. Googleing hashmap right now!

Ok, googling finished. So you are saying to have a hashmap for each block? Or one for the entire system?

One hashmap for every self-contained power grid. In this case the key will be a 3-integer position, and the data will be either a wire object or a device object (they'll both have to inherit a base class for this to work). Then to check if a block is in that hash map, you use get(position) and if the object returned it not null, it's in there.