Near the top, there is the following sentence:
We’ll keep track of the total power in the system by way of “power paths” (the PowerSource.paths variable), an array of map positions that begin with a power source followed by one or more power receivers.
The variable should be "PowerSystem.paths", not "PowerSource.paths".
I also have a question about the path tracing logic: why don't you pass in direction to the call to _find_neighbors_in() when you search for movers? Shouldn't power only enter a wire that is connected to a source outlet? For example, the Battery only outputs on the left side, but power still flows out no matter which side a wire is attached.
_find_neighbors_in()'s direction parameter has a default of 15 ((cellv: Vector2, collection: Dictionary, output_directions: int = 15) ), so when it is omitted in a function all, it will automatically be 15 (all directions.) Otherwise we override it when we provide a number there. :)
The order does not necessarily matter because each path starts with a source - anything after that is going to be a mover or a receiver.
As for the typo, yes, you're right. It should be PowerSystem.
Yes, it has a default value, but I'm suggesting that it's incorrect to NOT pass in the direction of the power output directions for the given power source. Because a mover or receiver that is connected to the wrong side of the source should not be part of the path, right?
When we get the receivers earlier in the _trace_path_from() method, we pass in the output directions when we call _find_neighbors_in(). I think we should do the same thing when getting the neighboring movers.
We're talking about this line, is this correct?
var movers := _find_neighbors_in(cellv, power_movers)
I'm not sure why it's a problem that electricity travels in all directions. It's possible that the power will travel towards a dead end when it reaches a point where there are no receivers who accept power in that direction, but it will not end up in the path.
Power goes from 1 >> 2, then 2 >> 3. When it gets receivers, it sees that the battery can receive power, and so goes 3 >> battery. Then it goes 2 >> 4, then it tries to do 4 >> battery, but it sees that the battery does not accept power from that direction, and so it does not end up in the path for that power source.
2 >> 4 becomes a dead-end, and we discard it (since we don't keep track of movers, just receivers.)
If I'm not addressing your concern with this, could you draw a diagram of the eventuality you're thinking about?
The above layout (where the arrows are representing power flow) should result in the following paths:
[[(0, 1)], [(1, 0)]]
But we end up with this:
[[(0, 1), (1, 0)], [(1, 0), (0, 1)]]
Passing in direction to the _find_neighbors_in() method like so:
var movers := _find_neighbors_in(cellv, power_movers, direction)
would ensure that we only trace power from sources via movers that are connected to power outputs, instead of looking in every direction.
To make that work, we need to create a new direction variable in the receiver loop instead of re-using "direction."
Okay, I see the issue now. Yes, you are right. I guess that one slipped me by in testing. Thanks for the explanation.
I'll issue a fix for it to the code.
I should have used a diagram to begin with. Sorry for all the back and forth.
No worries Erik, thanks a lot for taking the time to report the issue!