## Height fields

This board is to show, discuss and archive useful combinator- and logic-creations.
Smart triggering, counters and sensors, useful circuitry, switching as an art , computers.
Qon
Smart Inserter
Posts: 1632
Joined: Thu Mar 17, 2016 6:27 am
Contact:

### Height fields

I made simple "height fields". A height field here is simply a value that spreads with local interactions and decreases by one for each step. So I set something like green chips to 5 in one cell and all the neighbors will compute their value for green chips to be 4, and so on, lowering the value the further you get from the source.

The purpose is for local routing of items (or maybe signals). If a cell needs a specific item it can output that item as a value and the neighbors will learn about that and pass on the message to their neighbors. At each border you can now measure the relative need for an item and decide in which direction items of that type should flow.
• All combinators use "each" signals only so you can have a height field for every signal type all at once.
• You can have multiple signal sources in your network of cells for every signal type.
• The network has no memory, if you increase or decrease the input values dynamically then those values will propagate correctly through the network.
The blueprint contains nixie tube displays from Lovely santas mod, for visualisation purposes (they are configured to show the electronic circuit value here). But those are not necessary.

The constant combinator closest to the center is used to input values to the network. The power pole has the signals for all values of the network at that cell location if you want to mouse over and see the values.

The combinator that subtracts 1 on each signal gets as input the highest value that any neighbor (for each signal type) has, so you can see if an item is needed (1 or higher) outside the cell even if the need is 0 at this location. Eg. if the neighbor has a value of 1 for electronic circuits needed and we can produce electronic circuits then that can be used to decide when to craft more electronic circuits, instead of checking the value at our own location. So a "max of all neighbor values" that is used before we subtract 1 to compute the need at our own location.

The top 4 multiply combinators gets the neighbors values as inputs, these signals are what I will use and compare with the current cell values to decide when to route things from a neighbor cell to my own.

My computer broke so I can't access my other savefiles atm so decided on a miniproject. I was inspired by a simpler "cells of producers" design where items flowed on circular belts and moved from cells with filter inserters. But that one needed manual configuration of everything and could only send items to direct neighbors. My system should work at range, over unrelated cells. And it should generalize to cells of separate logistics networks as well instead of belts.

Attachments
Screenshot from 2021-06-01 11-57-48.png (3.07 MiB) Viewed 606 times
Screenshot from 2021-06-01 11-57-05.png (4.62 MiB) Viewed 606 times
Last edited by Qon on Tue Jun 01, 2021 10:39 am, edited 1 time in total.

Qon
Smart Inserter
Posts: 1632
Joined: Thu Mar 17, 2016 6:27 am
Contact:

### Re: Height fields

This was my inpiration. Don't know where from, but it was downloaded in 2016.
Attachments
XcY7LWT.jpg (886.46 KiB) Viewed 605 times

Qon
Smart Inserter
Posts: 1632
Joined: Thu Mar 17, 2016 6:27 am
Contact:

### Re: Height fields

Sneak peak of what this was developed for here:
All you need to do is set the recipe for a cell (in a specific constant combinator).
The 3x3 cell image has completed making filter inserters (just enough to fill the output belt since they are not requested anywhere) and iron sticks from plates and recalled all excess material.
• The filter inserters between the cells will route items where they are needed the most, so it doesn't really matter which cell is where, they will automatically be routed to the right cell.
• The height/need values will be set automatically for the ingredients (with the help of Crafting Combinator mod).
• When the input buffers fills up the cell will stop requesting that specific ingredient.
• When the output of the cell is not requested anywhere outside the output will be blocked.
• When the output of the cell is not requested anywhere outside the excess produce will be routed back to the production cells to clear the belts and will be collected and buffered for release later when needed.
Next step is to automatically set the recipe for each cell, computed from the final complex requested product. So I want the network to have the ability to just get a signal for filter inserters and it will output it automatically with no other interaction needed as long as it gets plate inputs.
I also want smelting of ores and mining to be done automatically, right now plates are hacked in with infinity chests.
After that liquids is a big step, I will have to barrel and belt those.
But with that the game will almost play itself (extremely slowly) with a single cell blueprint that can be made into a network that configures itself to solve the game with no player interaction.

No effort at all has been spent on making this efficient, small, pretty, fast etc. That can come even later.

Single cell
Attachments
Screenshot from 2021-06-03 21-38-23.png (4.34 MiB) Viewed 523 times
Screenshot from 2021-06-03 21-38-54.png (3.82 MiB) Viewed 523 times

farcast
Inserter
Posts: 36
Joined: Fri Jul 06, 2018 8:25 am
Contact:

### Re: Height fields

So it's called a height field, that's good to know. I've been using a height field as a way to control train routes entirely with combinators. Stations would output a large value to a particular signal, which then propagates through rail junctions. Trains are assigned a particular signal to follow when released, and the junctions open the exit with the highest value for that signal to guide the train to its destination. Hopefully one day I'll make a proper post about it as I skipped a lot of details, but I want to finish a real base that actually uses this system first. I'm also really lazy.

One potential problem is that when a signal source disappears, the nodes start passing the old values between each other acting sort of like a memory cell. The values will eventually decrease to zero, but that can take a while if the source value was really big. Here are a few ways to make sure this behavior isn't a problem:

-Keep signal sources static during operation.
-Make sure there is always a source when something is following a signal.
-Have a global override that disables propagation of a particular signal when it doesn't have a source.

You only need one of these to be true, or maybe you can think of another method.

Efficient inefficient design.

Qon
Smart Inserter
Posts: 1632
Joined: Thu Mar 17, 2016 6:27 am
Contact:

### Re: Height fields

farcast wrote:
Thu Jun 03, 2021 11:39 pm
So it's called a height field, that's good to know.
I just invented a name for it because it seemed fitting
farcast wrote:
Thu Jun 03, 2021 11:39 pm
I've been using a height field as a way to control train routes entirely with combinators. Stations would output a large value to a particular signal, which then propagates through rail junctions. Trains are assigned a particular signal to follow when released, and the junctions open the exit with the highest value for that signal to guide the train to its destination. Hopefully one day I'll make a proper post about it as I skipped a lot of details, but I want to finish a real base that actually uses this system first. I'm also really lazy.
This sounds really interesting. I really want to know more about it. I don't quite understand the full system and what it is capable of though. Are all stations named the same or something so that you can force them to any other station via signals?
farcast wrote:
Thu Jun 03, 2021 11:39 pm
One potential problem is that when a signal source disappears, the nodes start passing the old values between each other acting sort of like a memory cell. The values will eventually decrease to zero, but that can take a while if the source value was really big. Here are a few ways to make sure this behavior isn't a problem:

-Keep signal sources static during operation.
-Make sure there is always a source when something is following a signal.
-Have a global override that disables propagation of a particular signal when it doesn't have a source.

You only need one of these to be true, or maybe you can think of another method.
I decrease the value as the buffers fill up, so there's no real sharp drop in output value. And even if there is, the distances are still fairly small so the values don't have to be very big to propagate through the entire network.
I also send out a value (half of what requesters output) from the item source to request the item it produces to clean up any unwanted items from the belts. So I always want signals for all items to propagate as it is now.
The cells have small buffers for their input items so even if requests are routed there slightly past the signal output anything on the outside belt in the cell will be just buffered up a bit more (the request will stop before the buffers are completely full to the set limit since sources also request items back at a lower value).

If there's no source for a particular item (no items of type in system at all) then the signal for that item will have no effect so it doesn't matter. And if there's no producer at the moment (because they are starved for inputs or something) then the signal is still useful to route existing items on the belts towards where they are needed.

Amarula
Filter Inserter
Posts: 384
Joined: Fri Apr 27, 2018 1:29 pm
Contact:

### Re: Height fields

Thank you for sharing another cool and useful tool.
Qon wrote:
Fri Jun 04, 2021 7:50 am
farcast wrote:
Thu Jun 03, 2021 11:39 pm
So it's called a height field, that's good to know.
I just invented a name for it because it seemed fitting
Names are important for remembering, analyzing, and applying concepts.
So it shall forever more be recognized as Qon's height field.
Luck is not a robust control.

Qon
Smart Inserter
Posts: 1632
Joined: Thu Mar 17, 2016 6:27 am
Contact:

### Re: Height fields

Amarula wrote:
Fri Jun 04, 2021 12:31 pm
Thank you for sharing another cool and useful tool.
If you find a use for this useful tool then please share I'd love to see this actually used by others.
Amarula wrote:
Fri Jun 04, 2021 12:31 pm
Names are important for remembering, analyzing, and applying concepts.
So it shall forever more be recognized as Qon's height field.
Especially if my name is on it, now it has to succeed or it be weird to be forever associated with a failure

farcast
Inserter
Posts: 36
Joined: Fri Jul 06, 2018 8:25 am
Contact:

### Re: Height fields

Qon wrote:
Fri Jun 04, 2021 7:50 am
This sounds really interesting. I really want to know more about it. I don't quite understand the full system and what it is capable of though. Are all stations named the same or something so that you can force them to any other station via signals?
Yes, every station has the same name, and every train has the same schedule. The gist of how trains move around is that every junction exit has a train stop with the name of the destination. When a train approaches, the train stop on the exit that the train needs is enabled, while the other is disabled. When the nose of the train reaches the exit block, the train stop is disabled, forcing the train to re-path to the next junction or it's actual destination. You can read more about this technique here and here.

Here's the junction in all its horrific spaghetti glory.
junction.jpg (1.71 MiB) Viewed 409 times
I'll add the blueprint book if you want to poke around. This junction is the product of ~3 years of on and off work, adding whatever features I could think of, optimizing for combinator count, and fixing any bugs I found to the best of my ability. It's completely undocumented, filled with black magic, and I've had to rebuild it by hand several times, so forgive me for not talking about the details despite me really wanting to. There are currently no known bugs that are worth fixing, and I think 2 bugs that aren't. I can't think of anything else to add, so it can be considered feature complete.

The actual height field part of the circuit is all of the arithmetic combinators in the center and the row of deciders below them. The output is the subtractor by each entrance. Your implementation is more efficient for propagation, but it doesn't seem to be easy to extract exactly which input had the highest value.

I'm currently in desperate need of a way to describe combinator circuits with text in a way that's unambiguous, not entirely incomprehensible, and not a wall of text. I'm working on an idea that seems promising, hopefully it works.

Combinator Guidance System:
Efficient inefficient design.

Qon
Smart Inserter
Posts: 1632
Joined: Thu Mar 17, 2016 6:27 am
Contact:

### Re: Height fields

That looks awesome! Do you have any videos of trains going from item source to destination?
farcast wrote:
Fri Jun 04, 2021 11:34 pm
Your implementation is more efficient for propagation, but it doesn't seem to be easy to extract exactly which input had the highest value.
The circuit has as inputs the heights of the neighbors. And if you know the neighbor value and compare it to the local value (multiply one by *1 and add by wire combine and then decider > 0, with each on everything) you can see what values are higher than this location. So I don't really know what direction is highest, but instead I know for each direction if it is higher. And at those places I open the flow. While the values aren't changing, if the top is to the north-east, then both north and east will be +1 compared to the local cell. So it doesn't matter which one we pick and decide (in the production cells posted above) on both borders that the flow of those items should go there.

For trains it could work the same, if both exits have higher value then assume they are the same higher value and open both and let the train decide, either way works because it's going up regardless. In a grid both options will lead to equal path lengths to the final destination. And if it's not a grid then if the height field combinators are on a grid with the invalid parts removed (so a network like a grid with holes) then the longer path will be longer for the height signal and only one exit will have a higher value. And that will be the shortest path for trains also. This assumes no long diagonal paths since signals only propagate horizontally and vertically (for now).

So direction of highest value doesn't really matter.
farcast wrote:
Fri Jun 04, 2021 11:34 pm
I'm currently in desperate need of a way to describe combinator circuits with text in a way that's unambiguous, not entirely incomprehensible, and not a wall of text. I'm working on an idea that seems promising, hopefully it works.
I would love that!

farcast
Inserter
Posts: 36
Joined: Fri Jul 06, 2018 8:25 am
Contact:

### Re: Height fields

Qon wrote:
Sat Jun 05, 2021 7:56 am
That looks awesome! Do you have any videos of trains going from item source to destination?
No videos, but I made a save file with a bunch of trains moving around given pseudorandom destinations. I recommend having the show-rail-paths debug option enabled to better see what's happening.
Qon wrote:
Sat Jun 05, 2021 7:56 am
The circuit has as inputs the heights of the neighbors. And if you know the neighbor value and compare it to the local value (multiply one by *1 and add by wire combine and then decider > 0, with each on everything) you can see what values are higher than this location.
I get it now, you're comparing the result to the inputs to get which is highest. I'll see if I can use that to save a few combinators.

Edit: The old save would deadlock after a while due to too many trains in too little space, I made a small change to prevent this.
Attachments
Combinator Guidance System demo.zip
Efficient inefficient design.

Qon
Smart Inserter
Posts: 1632
Joined: Thu Mar 17, 2016 6:27 am
Contact:

### Re: Height fields

The trains aren't stopped to be identified. So that's what the metadata is for, and you propagate it to the same place you force the trains. That's really clever and impressive!
##### New preview
I added some recipe calculations (that I made another thread for) to an origin cell and the ability to send out recipes on at a time to different IDs and the signals are then saved by the cells. So now you just put down one origin blueprint and some production cells and press a pushbutton with a signal for the final product that you want and everything else is done automatically.
Fluids aren't handled yet though. And raw resources are inserted with infinity chests at the moment, but those can easily be replaced with just running resources to the edge of the cells or something.
Iron plates aren't prevented from being converted to steel plates yet so remove some furnaces where that's an issue. I'll fix that when I get liquids working and improve throughput. [edit: fixed and updated blueprint] Because it is extremely slow right now since there hasn't been any effort towards efficiency and speed yet.

I might also add in the ability to reconfigure a network for another use at some point?

Just plonk it down and press a button for the thing you want and you get it... after waiting a looong time.
Attachments
Screenshot from 2021-06-06 14-42-09.png (4.62 MiB) Viewed 323 times