Smart Train Deliveries with Combinator Magick [0.13/0.14]

[siggboy]

Update 19/08/2016: I've uploaded a new demo map (simpler) with a new depot circuit that runs a lot better than the beta version. Please upgrade if you use it. viewtopic.php?f=8&t=25311&start=140#p191133

Use the version linked above. Do not use any older version in 0.13 (it won't work). For 0.12 maps you can still use the published version 2.
The information below is outdated but I'll leave it here for the moment since it's still valuable for those who want to learn how to make such a system.

What does it do?

Your trains will dynamically react to supply and demand and mostly do "the right thing" by themselves. Rail capacity is used efficiently and management is made easy.

It's a Logistic Network of Trains. Trains are sent from a central depot (roboport), go to outposts to pick up resources (providers), drop them off where they are needed (requesters), then return to the depot. There's only one train line (logistic network), and the trains can go anywhere, like robots.

• Only one supply line: Run all trains on a single logical line, out of a single train depot (hub). Adding trains to the network is trivial: just plop down the train anywhere, preferably in the correct driving direction, assign it to the supply line, and start it. Done.
• Dynamic train assignment: Trains don't have to be assigned to certain outposts or certain resources. Every train on the line can service any outpost. It's not necessary anymore to figure out how many trains to assign to each outpost, and you won't have to reassign trains all the time when outposts run dry or new ones are opened.
• Supply detection: Outposts are not visited unless they're offering enough resources. No more half empty trains clogging up your railway. Use your own combinator logic to set the resource condition (it can be as simple as "> 1k ore" or as complex as you want).
• No more train monkey business! While an outpost is being serviced, i.e. has a train en route to pick up resources, no other trains will visit that outpost. The common problem of two trains arriving at an outpost in short succession is completely avoided!
• Demand detection: Demand from your factory is taken into consideration. A resource is not even eligible for pickup unless your factory requests it. For example, while your coal bunkers are full, your trains won't waste time making roundtrips to your coal mines. You also won't have trains full of coal sitting around at the coal unload.
• Easy refueling, since all trains run through the same hub (Smart Trains does have a great refueling solution, but you won't even need it).
• Flexible: the system is not limited to ore, it can be used to ferry intermediate products, too, even on the same logical line with the ore trains.
• Practical, easy setup: no rewiring shenanigans necessary, combinator knowledge is not required. Two values need to be changed at each new outpost, and you're good to go. The station number can be taken verbatim from the Smart Trains UI, no desktop calculator required.
• No outpost limit: the circuit handles as many outposts as you need (no limit at 31 bits or anything like that).

Major Update (30.05.2016): The new and improved version with actual requesters (like requester chests) is finished. The new demo map and blueprints are here. This post will be updated in time with the new version and documentation, after more testing.

My smart train controller requires the "Smart Train" mod by Choumiko; no other mods are needed, but FARL is a practical requirement because you need signal wire to connect all your outposts with the main depot.

Here's an animation that shows off some trains running:

Smart train controller in action

The indicator lamp by the buffer chests is on when an outpost has material. The other lamp is one while a train is on the way.

Observe how an outpost will never be visited by two trains at once, and how the trains at the depot will wait until an outpost is ready.

http://i.imgur.com/yfUhv36.gifv
(Not inlined because it's a fairly large image.)

Screen shots of combinator setups are boring, but "no pix, no clix", so here you go:

Here's how the depot looks in game:

Screen shot of depot

This is an outpost:

Screen shot of outpost

(Diagrams of the circuits are found in the explanations below, so I have not annotated these screen shots.)

How does it work?

The system requires a combinator setup at the depot and at each outpost. It also requires red signal wire to connect all outposts and the depot.

All train stations need to be "smart train stations" as provided by the Smart Trains mod.

I'm now going in great detail over the workings of the outpost circuit and the depot circuit. Keep in mind that most of the signals that are processed are exactly 1 tick wide. Some of the contraptions only work because of this.

Before I go on, let me thank users Lupoviridae and XKnight for giving me various ideas in their forum postings. I could not have come up with some of that stuff on my own...

You should know how combinators and signals work and you should be familiar with the Smart Trains mod.

The outpost circuit

The outpost circuit is the easier part. It is self contained and only "communicates" with the main depot, i.e. outposts don't "talk to eachother".

The outpost circuit takes receives two signals from the depot: "Yellow" (polling signal) and "Diesel Locomotive", which is used to signal to the outpost that a train is on the way.

Each outpost has a station number, identical to the station number in Smart Trains.

Here's the circuit diagram:



Ore Detector: this is a circuit that you may provide (in my blueprint it's a simple decider combinator that you would connect to the buffer chests). It must output a "Resource = 1" signal to indicate that the resource is available at the outpost.

For example, you could output "Coal = 1" when you have at least 1500 coal in the buffer chests.

This signal is not a pulsed value; it is a "hold" signal that must be "1" for as long as you want to indicate the condition.

Circuit #1: this is a triggerable "tri-gate" that can be in two states (both of them stable). Think of it like a flip-switch that either lets all input through or not. If "E=1", the value from the ore detector will be blocked. This means the outpost won't be able to report "ready for pickup" to the main bus. This mechanism is used to avoid more than one train being on the way to the outpost at the same time.

The flip switch is triggered from circuits #3 (the depot side) and #4 (the local side).

The "-> *IC" means "Output everything (input count)". It's used in many other places as well.

Usually the only output from this circuit is the supply flag from the ore detector, which is a single signal with value "1".

Circuit #2: the output from #1 is passed through here, along with the output from circuit #5 (station number). Circuit #2 only outputs while the station number of the outpost is in the Yellow signal on the main bus -- so this is a polling driver that outputs nothing at all unless the outpost is being polled for data by the depot.

Because our polling signal (Yellow) is 1 tick wide, the responses will be 1 tick wide as well.

The signal "Here" is the station number, in the game you set this value in a constant combinator when you build a new outpost. This signal is compared to "Yellow" on the red bus, and if both match we respond with data.

Basically your run-off-the-mill polling protocol seen in many designs.

Circuit #3: this decider will disable the tri-gate (circuit #1) when the "Destination" signal from the red bus matches the station number (= train inbound). In my implementation "Destination" is the "Diesel Locomotive" item signal. The depot circuit pulses this signal when a train leaves the depot.

This is the mechanism that effectively removes our station from the network until the train that is now on the way has been processed. As a result, no more than one train will visit an outpost at the same time (unless forced by other means).

Circuit #4: the reverse of #3. The circuit will pulse "E = -1" into the tri-gate as soon as a train leaves the station. This re-enables polling responses.

"Train" is the "train at station" output from the Smart Train Station. It is delayed by 1 tick as signal "D", and as soon as the train leaves, the calculation of the arithmetic combinator will yield "E = -1" for exactly 1 tick. Basically an edge trigger; the depot side uses a similar contraption.

As a special case you can feed "D=1" (or a larger value) directly into the upper combinator of #4 (from the red bus) in order to reset the flip-switch. This connection is actually in my blueprint, but not shown in the above diagram. It's useful if you want to force delivery from all outposts, even if some of them might have trains inbound. It's also a way to reset this part of the circuit in all outposts, as some tri-gates (#1) might be in the wrong state after manual intervention on the train network.

Circuit #5: this is simply an arithmetic combinator that re-colors the "Here" signal into the "Outpost" signal. We can't use the "Here" signal directly because that would lead to a collision in the circuit. The "Outpost" signal is sent back to the depot as part of our response.

Responding with our own station number makes things on the depot end a lot simpler, even though the depot "knows" our station number already as it has just polled us for data.

This concludes the explanation of the outpost circuit.

When setting up an outpost, two values have to be changed in the above circuit:

• The value "Here" in the constant combinator has to be set to the correct station number.
  [*]The signal type in the ore detector has to be set to the correct value ("Iron", "Copper", ...).
• Unless you provide your own detector logic, you can set a constant that tells the circuit the desired resource limit (usually 1 train load of resources).

Other than that, no setup is necessary, assuming your ore detector circuit is correctly set up.

The depot circuit

The depot circuit does most of the heavy-lifting, and it's responsible for directing trains to the correct outposts.

In the depot, signals are taken from two ends: the outposts (red bus) and the factory or unloading area. The factory will report resource requirements, i.e. provide flags that tell the depot which resource it should consider for pickup from the outposts.

The logic that determines resource needs is not part of the depot proper. You can make anything you like, for example add up the resource amounts in your buffer chests.

Like the outpost circuit, the depot expects a signal of "Resource = 1" to indicate demand. If you don't want demand calculations at all, you could simply set up a constant combinator and have it output something like "Iron 1; Coal 1; Copper 1". I don't recommend this, but it's useful to get things going.

The depot circuit needs no setup at all; put down the blueprint, connect to the red bus, and you're good to go.

This is what the depot circuit does on a high level:

• Poll the outposts until we have found one that offers a resource that we want.
• Send the train currently at the station to that outpost (the Smart Trains mod allows a train to be sent to a specific station by signal value).
• Report on the main bus that we've just sent a train to that outpost (the outpost will use this information and will stop replying for the time being).
• Suspend polling for data until the next train enters the depot.

Here's the circuit:



Circuit #1: an arithmetic combinator that multiplies all of the ore demand flags by 2^31-1 (the highest possible 32-bit signed integer).

Here's why we do this curious multiplication:

In the depot, we need to check if both of the following conditions are true:

• The resource is currently in demand by the factory AND
• The same resource is currently in supply somewhere

When we poll the outposts, they will reply with "Resource = 1" if they have it.

We can add this value "1" to the value "2^31-1" from combinator #1 and check if the result is "-2^31" (values greater than 2^31-1 are negative integers).

This way, we can check for all the resources simultaneously, because only corresponding signal types are added (e.g. "Coal = 1" will be added to "Coal = 2^31-1" but not to "Iron = 2^31-1"). Adding signals can be done by combining them on the same wire/input, so we don't even need an extra combinator.

This simple trick allows us to check for both conditions above and it allows for arbitrarily many resource types without having to make a complex iteration circuit.

(BTW it would also work with other large numbers, but by using MAXINT and MININT it is made very explicit that we're dealing with magic numbers and are not interested in the actual values. I prefer that to, say, adding "100.000" and checking for "100.001". It also makes false positives from bogus values on the red bus less likely.)

Circuit #2: simply passes the values from the red bus if the condition from circuit #1 is met.

The following signals will be output by combinator #2 at this point (not considering foreign values on the red bus):

• "Ore = -2^31", which we ignore; we already know that we want this resource or the combinator would not output anything
• "Green = 1", which is an artifact of the calculations done at the outpost; we ignore this.
• "Yellow = x", from ongoing data polling; ignored.
• "Rail Signal = <station number>", which is the signal that we are interested in. This is the station number of a valid outpost, and it is where we'll be sending the train.

"Rail Signal" is called "Outpost" in the diagram.

So, now we have a single tick long signal of "Outpost = <station number>", and we already know that this is where we want to send the train.

Let's feed it to the Smart Train station, and off we go, right?

Unfortunately, the Smart Train station does not handle single tick signals correctly. Other considerations aside, for this reason alone we have to store the "Outpost" number until all processing is finished, and our train has left the station.

We also want to ignore all further polling results until the next train is ready.

Which leads us to...

Circuits #3-#7:

This contraption is a special purpose register that stores the first "Outpost" value read and then accepts no further values until reset.

Update: This "write-once" register can be implemented with 3 decider combinators. The implementation shown (and used in the current version) works correctly but is more complex than necessary.

#3 and #4 are required because we might receive several Outpost numbers in succession, but we can only handle one (we pick the first one). To understand the mechanism, look at circuit #4: the signal "Red" from #3 will be "1" if "Outpost" was "0" in the previous tick, since all combinators require 1 tick to calculate results. Therefore, #4 will output the "Outpost" signal for exactly 1 tick if the previous "Outpost" signal was "0".

Consider the following sequence of "Outpost" signals on the input (one signal per game tick):

Code: Select all

Tick:        1 2 3 4 5 6 7 8 9
Input:       0-0-0-4-5-0-7-8-0    (value of "Outpost")
Output #3:   ?-R-R-R-0-0-R-0-0    (Red = 1?)
Output #4:   ?-0-0-0-4-0-0-7-0    (result of "Outpost * Red")

Update 1: this was not correct, and the reason for a bug in this circuit
As you can see, we'll get the first outpost number, and then at least two ticks of silence. This is good enough for anything that follows.

(The example does not show it, but an input such as "0-0-4-0-6-0-0" will show up as "4-0-6" on the output, leaving only one tick of silence between outpost numbers.)

Update 1: the updated circuit has a red connection between the inputs of #5 and #6, and a dummy/identity combinator between #6 and #5 that will extend Yellow by one more tick. In the current version, the Yellow signal -- which blocks writes to the register -- appears 1 tick earlier. This is because in the worst case we only have 1 tick of "space" in between write attempts, and we need to block write access to the register quickly enough to avoid bogus values to appear. (I might rewrite this section and provide an updated circuit diagram.)

Now we need to store the value ("4" in the example above) until we do not need it anymore.
This is done in combinator #7, which will hold any single-tick signal indefinitely, until the erase signal ("Destination" in this case) is applied, or another input appears.
More complex register implementations exist, but if you only have single-tick inputs, combinator #7 is as good as it gets for storing values.
Combinators #5 and #6 make sure that we won't overwrite #7 until it is explicitely erased (by applying the "Destination" signal).
The mechanism works because #3 & #4 buy us at least two ticks of time until the next input appears, and by that time #5 will already be blocking further input to #7.

Phew.

OK, so now we have a value of "Outpost = x" in combinator #7 and we won't have to worry about timings.

We apply the "Outpost" signal directly to the Smart Train station, so the train will now leave (according to my experiments it takes the station about 10 ticks on average until the train has actually left).

Circuit #12 will pulse "Red 1" when a train leaves. This will then gate the "Outpost" value onto the red bus. Circuit #13 will recolor it to "Destination" (the "Diesel Locomotive" item in my implementation) before it's actually put on the bus.

The "Destination" signal from #13 will also reset the register #7, so the depot is now ready to process the next train.

Using the "Destination" signal -- that we've just put on the red bus -- as the erase signal for the register ensures that we won't delete our "Outpost" value until we're 100% done with the current train and it has actually left the depot. This makes the circuit completely deterministic and independent of any timing considerations.

So what's left is the device that generates the polling signal ("Yellow").

Circuits #8 - #11: Circuit #8 will count up "Yellow" as long as circuit #11 outputs "Blue = 1". Circuit #9 ensures that the counter will not count past 100 (it resets to 0).

The Yellow signal is put directly on the red bus. Any outpost whose station number matches the value of "Yellow" will respond (with a few ticks delay from the outpost circuit).

Since we increase Yellow each tick, we can, theoretically, poll 60 outposts per second. On average we will find a candidate outpost halfway through the search, so even a gigabase with an inconceivable amount of active outposts (100?) will take less than 1 second to complete a search, on average.

The polling protocol will certainly not be the bottleneck in actual games...

The last circuit to be explained is #11: "Train" is the "train at station" signal from the smart train station. This signal can be either "0" or "1". The "Outpost" signal can be "0" or positive (usually greater than "2"). Therefore, circuit #11 will only output "Blue = 1" if no "Outpost" is in circuit #7 (meaning we're still polling/searching) and there's also a train waiting at the station ("Train = 1"). In all other cases "Blue" will be different from "1" and circuit #8 will reset to "0" and stop counting -- polling will be suspended.

This concludes the description of the depot circuit.

How to set up Smart Trains

Here's the setup from the demo map:

The values marked red are mandatory. Smart Trains will ignore the "go to station #" column and the "signal value" check box unless you also have "leave when signal" active. "Wait forever" is mandatory as well, to force the signal check. You have to set it up this way. Choumiko has promised to fix some of these quirks after 0.13, so we'll have to see.

After the unload stations (2, 3, 4) you always want to go to the depot (1). Mandatory.

After the outposts (5, 6, 7), you usually want to go to the respective unload (2, 3, 4), but this might be different on your map if you have a single unload (robot based) or other special setup. Just make sure these numbers are correct for your case.

When you add a new outpost, you also have to make sure you set the correct unload station for the outpost. The circuit setup will not direct the trains at the outposts, only at the depot.

"Leave when empty" and "leave when full" is where you are flexible. If you use either of these, you can set the signal value to "always true" (at the outposts and unload facilities). The trains will then leave when they're full/empty.

Obviously, if you let only "full" trains leave your outposts, you should set the resource threshold close to the capacity of the train, e.g. set it to something like 1400 ore for single wagon trains, or else the train might waste time at the outpost waiting to be filled. Keep in mind that all trains are shared, so any time a train sits idle without reason it's not available to service other outposts.

In the demo map I've set some arbitrary value at the outpost signals, to make for a more interesting scenario. Therefore the "full" check is not used here.

The outpost blueprint does have a "catch all" signal on the train station; so your trains will leave without cargo unless you check the "leave when full" column or change the signal condition.

Here are the blueprint strings:

Blueprint for the smart depot

Code: Select all

H4sIAAAAAAAA/8VY226kOBD9lYjHHRhhoG+aZZ72L0arlgNOtyWwkTFJWoh/XwM9HdrYYLuT2aeoQ1XZPlWnTtk5fSpoBounY9oiwjHHqE7blsASpV5GSc0h
4UFGy2dMIKfM8ytaCytK0vY9DZLvG/+SBvH3Tee/4IIj1nvX+ERgkbb8Uokor5jxBhaePwYdPwYXVBT0zev8jDaEp0l0SA7bbXTY+pjk6D0FnW8U559bCHD1
jLpO+I5Gz/gUoAJlnOEsqGiBpP3H/e6TPgIhwkr8W+z/lwe8f9OWoVycZQDlcsR5GoGum4QuUY6bcil6/AHOzavmDOLTmQfiTyFtZttbR52fYzbuRRzFxC9x
9Ivc/EI3N8fVlg63Xp+bMQVhX58mOQaRn2GWNZgPv4Z86+oac1T+LkbMKAkoQ4pilMt46pbRqkJM6RhPSi1HGc6FnfaYfRkPZ/xAaWtc0/6JIUQWYBgI9cuL
lAHCOWBi4Rxf171uPW1fMKv50YTRkFz4GZPTAMmYYFEBINkl+3ib7MU/ywqyHoXUSz2fNrxqzCKjV8QmsavLccD8+MJoecREhEk9zhqRjA/sIcP8XCIuGL4I
fyDhH5nVWzjBVpEHsIzux+ZsAEYwO0/BvWG786koRzjs3/vLDtoh5gS3dW6GttxMzLlppDnAUmqeiwZJgrWLDhuF7KwRNnTlK4jFGhP2xRJPVVxO7m30/mCJ
55pGocjJg/S/oXytzvAPE74uIeNBL0gkqDmt5ioWakRMcgwqRt8vkvtKzc8RjvbLCF8/qhGeak0vrcH4WQ/vzyUkxgMFGWQnen8sYH8sC6FV53bYxhs8iXX0
pAST40wBUM1pMiGtJSByUYCZgCpYdm+zKMfbrxAMsYqAuEZ9JOMKM5ASrbPt7AOctBfoGyM46BqjogfObC16oDVD7RrgmDlN53uBRX3X+tavNMHI9MhYs6UB
xjcVpvtfe7n+reaz0JmbBwN53d1vdWesqLJ2fwpVx24NuWjYA/ke4u03q1obhdtyCjJirsncoYNZtvS1IjRPgcP0Mhkxr/QFoSyx9qAaM3i1W44PNpoXD4Xy
bD5LeRywlO8pj+B4i2U0AxqJTuLUUmSYVHIvt50F8YmWyvuRlDiMjjb5mPDkkyq7T0nsNAccFnRoswBvsq4OFvx5ZIow7kV3Gfv7y+9SJgqQuNyDY3kiVmEf
6XMXz56ttHlZuX855MVUo5dHOtc82o2EhuNV7PT4uDMYr7Yrk6Dlg4WcTn+x79pNZPqWaZ1ey8tTjlGNiqCgIkeU41e7OWxonZvH1UxDQ62azaLJbwKr0YB5
s55fIdy0UAH1//dWZdJfNybUVABtfpGZWX5Fh9Ro2FdchzsfZ8PO2+sj0u8g8sugMP3BEG8YeTr+QCT/D3odvc9NHQAA

Update 24.05.2016: Made the smart outpost a little easier to setup (logic unchanged), added picture with explanations. The demo map does not use this version of the blueprint yet.

Blueprint for the smart outpost

Code: Select all

H4sIAAAAAAAA/8VYXW+jOhD9KxWPd3EFzkcXddmn9ldUV5ELTmLJ2MiY3kYo//0OJGmAgGOTbLcvVevMjGfOnDPjpPKBy4Twh1VcUaGZZrSIq0qQjMZeoRVh
m61G8It7fi4LOJcirj5jtPR3McJ7P2WKJs1/4Q8Lu/lEOzzNLphmNjGaMbmMKI2SLS10L7XF4wLsgsfF3k+kEAdLQOHNC71/40rRFBBpwNmtWBqHMz9hKimZ
bv7a1z+tIJwjTrK8X3ZzjI2iVBii4CYIWKbsaHg8jKs1U4VeFWwjCI8rvcvhGh9M6ZJAcY63ag4RETu9ZWLjNZ4KTYQGfBKZ5UQRLVXs/fZauRDF9DajmiUI
PvPORP2ZXlqzuuBNVueSL20zrJPy3zw8WOTgosid9M+XG64A0zQ7pV/3i0CFlnk3c5lTyLu+svfD82Wp89Lkpm43dDj29hPq1CsTtmq2qNsFfrtEhjMc9rtn
tNChwWn3DOPbMBnuSkqSLeBS0NqVlUXTSmDSwu+fEfxMIVsQZjRlZYYoBzgU4JhLTnsIho4iERiA+9nRjFNHjndP0MRGDuphQLEvX9boDzByzbimqh5Y1uwr
gXpzHM2j5ROOFj4TKf1sIo17eCcFYJIxAdqFUsU4//IUzqPo6AO3SprShKVUjVY0mErHJ4jhqGRdKoaDDn5ecOmYwb2IZFHO9hRwJxM4yHerBpTVWslsxQQ4
iL014QX1uhMSxnCrKS7mfmCa32dDlCv5ueuZXyHKBUuXf2GuDieCEqI2sptO6JrOYrC7sGFhaQ+1TuxZK3Zrtn8ZvrONSS/rTSy0vHX3Rte428zS0GblcNHk
C3Vzpfm1hWUCoXeUc/mfDaV7GntuvNiJyqfBastlK6jwJKgiRzgGun5+AyDt4qbwJKOw1EtIU2r2Qb8Rkdd7onGQEzzlldMjy0Vpv5EVr22ZDTu1/eU2uD6o
agn3YJG1Kqnrmyg4lfnc9PNJ+mSj5f7o2W3smLbLH7qeaGj8ZjF32+tfujs9cmWKywJoosKA1CyvPIQMhb7yaJrAgIEqjxDCTWxe7i39synS39+Xx4VnhCHY
dsobt/Y+P4YiLe6uZ/218U/NitHvqQ7EmNm/NC8guX2fNih8fGA5Sxrf1fH16I88LSDd49uw84nDd4Dg51lRXSrxsHqmIv0f+Br4MIoVAAA=

This is a blueprint for an outpost. It includes a smart train station and all necessary power poles. The red bus should be connected to the large power pole after you are done setting up the outpost.
The smart chest in the blueprint is only for reference (typically this would be the last chest in a row of buffer chests). The chest is already connected to the decider combinator that signals the station if enough resources are available for a pick-up. Connect your entire buffer array to this decider (simply connect all smart chests that make up the buffer together). You can also use green wire instead, it makes no difference.

The resource type ("Iron", "Coal", ...) does not need to be configured, unless the station will provide mixed ores, in which case you might have to provide your own logic (if you use the blueprint with mixed ores, then the station will not signal "ready" until each of the ores exceeds the limit; this might work for you or it might not).

The picture below explains the important elements. The only settings that you need to change are (1) the station number and (2) how many resources the station should collect before it asks the depot for a train. Both of these values are set in the constant combinator (the blue arrows in the picture).

The station number must match the number that this station has in the Smart Trains configuration, where you set your main supply line. If you set this to "0" while the circuit is powered on, the station will go into the "locked" state. To fix this, put a "D=1" signal on the red bus, or disconnect/reconnect the red wire on the lower left combinator (the one that outputs "E=1").

You can avoid this from happening at all by setting the value of this constant directly (mark the contents of the text box, then input the desired value).

The amount of resources can be set freely, a useful value is the amount that one train can carry (e.g. 1500 for a single wagon train, or 6000 for a 4-wagon train).

After you have set the two values you can connect the station to the red bus.

smart-outpost-annotated.png (487.76 KiB) Viewed 45964 times

Update 23.05.2016: Improved the demo map, demand from the unload is now calculated and used as input for the depot circuit. The dummy demand combinator has been removed. I've also streamlined the loading and unloading a little.

A demo map is attached to this post, and a collection of mods (only Smart Trains and Test Mode are required for the demo map, the others are for convenience).

The demand flags from the unload are transmitted with green wire and used as input for the depot circuit. The lights at the unload indicate if the unload is running low (the threshold is set to 7k ore, you can change this value as you see fit).
The combinator at the depot powerpole (north of the rail) can be used to suppress polling and reset the flags at the outposts (it will practically suspend all delivery and the trains will return to the depot). If you want to activate it, just connect it with red wire to the power pole right next to it.

Update: There's a new version here. It's much better than this one, but might still contain bugs. Edit: The new version seems to work fine, if you use the latest pre-release of SmartTrains (don't use the version from the mod pack). I've found no issues so far and I'm currently using it in a real game.

The stuff below is OBSOLETE. Only here for archival purposes. It will work in 0.12 though with the provided mods.

[NoriSilverrage]

This looks/sounds amazing and it's essentially what I've been trying to do. Yours looks better though. Thanks for sharing and the very detailed post.

~edit: One question though. It's looking like you can only have 1 unload location at once. Granted you can put the same name on multiple stations though that may not balance the resources.

[siggboy]

This looks/sounds amazing and it's essentially what I've been trying to do. Yours looks better though. Thanks for sharing and the very detailed post.

~edit: One question though. It's looking like you can only have 1 unload location at once. Granted you can put the same name on multiple stations though that may not balance the resources.

You can have as many unload stations as you want. You have to configure SmartTrains so that it sends the train from the outpost to the correct unload station (look at the example SmartTrains configuration at the bottom of the article and you see how it's done correctly). If you want multiple unload stations for the same resource, and balance those, you have to do that manually (e.g. assign Iron 1 and Iron 2 to Iron Unload A, assign Iron 3 and Iron 4 to Iron Unload B, etc.).

In fact, this is a limitation of the current design. The system would actually be a Logistic Network with trains if the unload stations were chosen dynamically as well. In fact, this is going to be the next version, because I'm pretty sure my system can be expanded that way. Somebody in the SmartTrains thread gave me the idea.

A Logistic Network for trains. Depot = Roboport, Unload Stations = Requester Chests, Outposts = Passive Provider Chests, Trains = Robots. We're almost there .

[ssilk]

I stickied this, cause it's worth reading.

Maybe not forever, but the ideas go into the right direction and will be helpful with v0.13.

[siggboy]

Thanks for the sticky, much appreciated

It was a lot of work writing this up, and making the diagrams (yEd is great for this, BTW, somebody on these forums recommended it, I forgot who it was). I hope that I can make the design truly complete and we have a real logistic network (the current design is already pretty close, though).

[ratchetfreak]

To be able to select the unload you would need to send the requesting station to the loading station as well.

[siggboy]

Yes, that's the plan. Probably we'll turn the "toggle register" in the outpost circuit into a general purpose register and store the value there. That way we'll still have the toggle flag and can also use it to send the train to the correct unload.

We'll also need to make a circuit to put at the unloading stations. A second polling signal will be necessary, so we can poll the unloading stations for requests/demand. It's not sufficient anymore that we know about demand for something, we also need to know where to bring it.

The trickiest part is on a higher level, though:

Let's say we have 1 coal outpost and plenty of demand for coal. So we poll for demand and get "coal", we then send a train to the outpost. Now the coal route is locked down until that train has finished loading, let's say for 1 minute. We poll for demand, and again get "coal". Nothing will happen until the coal outpost is ready again, we've blocked the supply route.

So I think we need to poll the provider side (outposts) first, using a resource filter as in the current version. We'll somehow have to build that filter from all the resources that are requested at any given time. When we found our provider, we then poll the requesters to find one that wants the resource.

The protocol gets a lot more complicated with that change.

[jcaferjr]

Demand detection: Demand from your factory is taken into consideration. A resource is not even eligible for pickup unless your factory requests it. For example, while your coal bunkers are full, your trains won't waste time making roundtrips to your coal mines. You also won't have trains full of coal sitting around at the coal unload.

First off thank you for this amazing creation! I'm testing the on-demand factory requesting and cannot get it to work. I've downloaded your demo and have the mods installed. I run the game and everything works fine, then I fill the "copper Unload" chests full and cut off the belt system. The trains still come and wait.

Am I doing something wrong or perhaps didn't understand the comment above?

Thanks

My first post ;o)

[siggboy]

First off thank you for this amazing creation! I'm testing the on-demand factory requesting and cannot get it to work. I've downloaded your demo and have the mods installed. I run the game and everything works fine, then I fill the "copper Unload" chests full and cut off the belt system. The trains still come and wait.

Am I doing something wrong or perhaps didn't understand the comment above?

In the demo map the "demand detection" is only a dummy, it's coming straight from a constant combinator (the one right next to the depot). If you look into the combinator you will see that it does have "Iron 1; Coal 1; Copper 1" signals. This indicates to the depot that all three resources are "in demand".

If you want to simulate actual demand detection on the demo map, you have to create your own little circuit that will output, for example, "Iron 1" when the iron level in the respective unload station is below a certain number. This is very easy, just connect all the smart chests with a decider combinator and set that to something like "If Iron < 10k -> Output Iron = 1" and connect it to the depot. You also need to remove the dummy output from the constant combinator.

Then you can run a more realistic test by filling chests at the unload and observe what happens.

Of course if you only want to simulate a saturated unload there's no need to build an actual circuit for it. Simply remove one of the constants (e.g. Iron 1) from the combinator and then you'll see that the iron "outposts" get skipped, until you set the "Iron 1" constant again.

It's important that in the current implementation these values need to be either "1" or "0" (no signal). So if you have two iron unloads it's not going to work if they both output "Iron 1", because that would get summed up to "Iron 2" and the depot won't handle it correctly. In that case (with multiple unload stations for the same resource) you need to consolidate these into a single signal that can be either "1" or "0" -- which is really not a problem and very easy to do, but I'm mentioning it just in case.
(OK, strictly speaking "Iron 2" is a permitted value, but it would be equivalent to "Iron 0"; any value other than "Resource = 1" disables that resource).

[jcaferjr]

First off thank you for this amazing creation! I'm testing the on-demand factory requesting and cannot get it to work. I've downloaded your demo and have the mods installed. I run the game and everything works fine, then I fill the "copper Unload" chests full and cut off the belt system. The trains still come and wait.

Am I doing something wrong or perhaps didn't understand the comment above?

In the demo map the "demand detection" is only a dummy, it's coming straight from a constant combinator (the one right next to the depot). If you look into the combinator you will see that it does have "Iron 1; Coal 1; Copper 1" signals. This indicates to the depot that all three resources are "in demand".

If you want to simulate actual demand detection on the demo map, you have to create your own little circuit that will output, for example, "Iron 1" when the iron level in the respective unload station is below a certain number. This is very easy, just connect all the smart chests with a decider combinator and set that to something like "If Iron < 10k -> Output Iron = 1" and connect it to the depot. You also need to remove the dummy output from the constant combinator.

Then you can run a more realistic test by filling chests at the unload and observe what happens.

Of course if you only want to simulate a saturated unload there's no need to build an actual circuit for it. Simply remove one of the constants (e.g. Iron 1) from the combinator and then you'll see that the iron "outposts" get skipped, until you set the "Iron 1" constant again.

It's important that in the current implementation these values need to be either "1" or "0" (no signal). So if you have two iron unloads it's not going to work if they both output "Iron 1", because that would get summed up to "Iron 2" and the depot won't handle it correctly. In that case (with multiple unload stations for the same resource) you need to consolidate these into a single signal that can be either "1" or "0" -- which is really not a problem and very easy to do, but I'm mentioning it just in case.
(OK, strictly speaking "Iron 2" is a permitted value, but it would be equivalent to "Iron 0"; any value other than "Resource = 1" disables that resource).

Ah, ok. I thought you figured out a way to demand resources without running the wires from each "factory." Sounds like your an electrical engineer. We did all the gates and flip-flops stuff. ;o)

[siggboy]

Ah, ok. I thought you figured out a way to demand resources without running the wires from each "factory."

Yeah, I have: set the flags manually in the combinator .

But seriously, it's not possible until we get wireless transmission for the combinator network.

Sounds like your an electrical engineer. We did all the gates and flip-flops stuff. ;o)

I'm a software developer. The combinators work quite differently from discrete electronic circuits (not least due to the fact that there is no current and no voltages). It's a strange mixture of digital computer and basic electronic circuit.

One of my first naive attempts to build a flip-flop started by me looking at an electronics book and imitating a flip-flop made from transistors in Factorio. Of course that's not the best way to do it, but in order to understand that you have to first figure out how feedback-loops work. I think it's arcane, and conventional electrical engineering knowledge hurts more that it helps (BTW I know next to nothing about EE).

[kann_]

That looks cool. I will have a deeper look how you did it.
I don't want to steal the show or anything. But I recently posted something similar on reddit, which might be interesting for you as-well: https://www.reddit.com/r/factorio/comme ... _provider/

Our setups are insanely similar. Did you know about mine?
That is really interesting.
I have difficulties to read your diagrams, but I will have a look at the demo map later.
My system has some problems/issues, maybe you can help me on those. Or we can put some work together.
I think there are a few things that are better in my system, for example my train counter at the outpost allows more throughput.
Also the requesting stations are on the multiplexing bus in my system. So it is possible to request resources from everywhere, but currently it only supports only one request station per resources same as in your setup.
But yours seem to be much more compact, which is a problem with mine.
To match requested resources and outpost resources I just add negative requests with positive supply of 1 and ignore every channel with positive result. I like your 2^31 approach, which seems much more compact.

How do you handle Oil? Can the system work with different trains?
You plan to have dynamic routing from loading station to different unloading stations?
How does your system chooses an outpost? In mine it just picks the first that satisfies the request, which prefers the first channels. Initially I used random numbers to looks for channels, but I dropped that idea.

I think with some extra work there could be a fully dynamic request/supply network with trains. With multiple request stations per resource.

[siggboy]

That looks cool. I will have a deeper look how you did it.
I don't want to steal the show or anything. But I recently posted something similar on reddit, which might be interesting for you as-well: https://www.reddit.com/r/factorio/comme ... _provider/

Our setups are insanely similar. Did you know about mine?
That is really interesting.

I did not know about your setup but I'm excited that somebody else did have the same idea. We should work together to improve the project. I need to make some changes to make it more flexible and behave more like a real logistic network.

Xeteth has mentioned his own project (he also made a video) in the SmartTrains thread, here: viewtopic.php?f=97&t=14432&start=300#p159944

I'll look at your stuff and then probably reply some more.

[NoriSilverrage]

I downloaded your demo and watched the trains for a while and I'm quite impressed by the setup. It's really nice. I'm also amazed that you are able to do all that with so few combinators.
Got a question for you though. You have the depot (dispatcher) which waits for a station to signal it is ready to receive a train. But what happens if more than 1 station is ready at the same time?

[siggboy]

I downloaded your demo and watched the trains for a while and I'm quite impressed by the setup. It's really nice. I'm also amazed that you are able to do all that with so few combinators.

I've done the same thing after I was done: watching the trains being quite impressed by myself. And I hate myself for it, but only a little . It took me quite long to arrive at this design, somebody with real talent could have done it in an afternoon.

It doesn't require more combinators because I spent a LOT of effort making it as compact and efficient as possible. My earlier designs weren't as compact.

Also, don't forget that this circuit does no train counting (beyond the locking of stations) and no resource counting. The designs by kann_ and Xeteth are more advanced in that area, but they also require way more combinators.

This design needs to become more similar to kann_'s, I don't want to do train counting but probably some resource bookkeeping, and most importantly, select the unloading stations dynamically, you won't have to set that up in SmartTrains and it'll be more like a logistic network with robots (so the "requesters" will actually be requesters with an active role on the network).

Got a question for you though. You have the depot (dispatcher) which waits for a station to signal it is ready to receive a train. But what happens if more than 1 station is ready at the same time?

That does not matter. Every train that arrives at the depot (the actual station, the front of the row of trains) starts a new polling process and then some (arbitrary) station with resources will be selected for that train, as long as the resource is requested.

[kann_]

Maybe we can setup a "creative" server just to combine some of the ideas.
Although, with the next version coming up it might be worth of delaying it a bit.
With the deactivate function of train stations there will be some interesting possibilities.
If all outposts of the same resource have the same name we can just deactivate every outpost without resources. The same with unloading stations. There could be easily several unloading stations of the same resource that deactivate them self when full.

The new problems will be that the closest outpost will get crowded and it will be impossible to "reserve resources" since we don't know where the train ends up exactly.

[NoriSilverrage]

I downloaded your demo and watched the trains for a while and I'm quite impressed by the setup. It's really nice. I'm also amazed that you are able to do all that with so few combinators.

I've done the same thing after I was done: watching the trains being quite impressed by myself. And I hate myself for it, but only a little . It took me quite long to arrive at this design, somebody with real talent could have done it in an afternoon.

It doesn't require more combinators because I spent a LOT of effort making it as compact and efficient as possible. My earlier designs weren't as compact.

Also, don't forget that this circuit does no train counting (beyond the locking of stations) and no resource counting. The designs by kann_ and Xeteth are more advanced in that area, but they also require way more combinators.

This design needs to become more similar to kann_'s, I don't want to do train counting but probably some resource bookkeeping, and most importantly, select the unloading stations dynamically, you won't have to set that up in SmartTrains and it'll be more like a logistic network with robots (so the "requesters" will actually be requesters with an active role on the network).

Got a question for you though. You have the depot (dispatcher) which waits for a station to signal it is ready to receive a train. But what happens if more than 1 station is ready at the same time?

That does not matter. Every train that arrives at the depot (the actual station, the front of the row of trains) starts a new polling process and then some (arbitrary) station with resources will be selected for that train, as long as the resource is requested.

Well I setup a system that selects a station to unload based on which one is least full. I ended up having to compare each station individually to get it to work right. And then I had to compare the go to station signals because otherwise a train might double up on a station. I believe I have about 15 combinators. I've no doubt there is a better way to do this which is partly why I asked the question about the train signal.

So theoretically, if you were running with 1 train, it could go to the same outpost over and over assuming it continues to broadcast as needing a pickup?

[siggboy]

Maybe we can setup a "creative" server just to combine some of the ideas.

Not a problem, I have a dedicated server where I can run a Factorio instance.

Although, with the next version coming up it might be worth of delaying it a bit.

Yes, I agree. Choumiko also has to update SmartTrains for 0.13.

With the deactivate function of train stations there will be some interesting possibilities.
If all outposts of the same resource have the same name we can just deactivate every outpost without resources. The same with unloading stations. There could be easily several unloading stations of the same resource that deactivate them self when full.
The new problems will be that the closest outpost will get crowded and it will be impossible to "reserve resources" since we don't know where the train ends up exactly.

I don't think that this new function will have any impact at all for our projects. We use SmartTrains to send trains from depot -> outpost and from outpost -> unload, and the trains always go from unload -> depot. Deactivating stations does not change anything, and it won't make any of the circuits any simpler. I really don't care much about these changes.

What we need is a vastly improved train UI and a good chunk of the functionality of SmartTrains, FARL and FatController in the base game. Anything short of that really doesn't make much difference in my opinion.

[siggboy]

Well I setup a system that selects a station to unload based on which one is least full. I ended up having to compare each station individually to get it to work right. And then I had to compare the go to station signals because otherwise a train might double up on a station. I believe I have about 15 combinators. I've no doubt there is a better way to do this which is partly why I asked the question about the train signal.

My circuit does not distinguish between unload stations. The trains don't get directed from outpost (loading) to unloading by the circuit, the SmartTrains mod does that.

I wouldn't try to make a circuit that sends the train to the "least full" unload. That does not solve an actual problem. In a good setup the unload, which are your requester stations, should be able to request their resource and then a train should service that request ASAP (best effort). After a couple of deliveries (ideally only one), the requester will be "satisfied" or "saturated" and stop requesting resources for a while.

It's really not necessary to "balance unloading" among stations and count resources and all of this. As long as your requesters have resources to work with (i.e. not "running dry"), you're in an acceptable state. The entire setup should work towards that acceptable state, but not more than that.

So theoretically, if you were running with 1 train, it could go to the same outpost over and over assuming it continues to broadcast as needing a pickup?

OK, first of all the stations don't really "broadcast" that they need pickup. Each outpost (provider) may signal that it does have at least "X" of its resource ready for pickup (I like to put the threshold close to the capacity of a train; so while I'm using single-wagon trains a station will signal "ready" when it does have at least 1500 resources in the buffer).

Now, when a train arrives at the depot, the depot will immediate go through the list of all outposts and ask them, in turn, if they are "ready", that is, if they have "enough" of their resource to fill a train. They will reply "yes" if they do. Now we will compare this "yes" answer to the list of resources that are currently in demand, and we will simply ignore it if we're not interested in the resource. So, for example, if an iron outpost answers "yes", but we currently have no demand for iron, we'll just proceed to the next outpost -- and so on, until we've found an outpost that offers a resource that we want.

Then we go to that outpost.

Now, to answer your question: yes, if we only have 1 train and a constant need for, say, coal, and there's a coal outpost that offers a lot of coal, we'll send that train there over and over again. We will skip the other outposts. In this regard, the system is completely arbitrary, it will send the trains to the first acceptable station it finds.

In your example with 1 train the system is probably not going to be able to meet the demand of the factory. The system needs more trains. But if you were to schedule the train manually you'd have the same problem. The system isn't "broken" it just doesn't have enough trains to work with. It's not possible to design a circuit that meets impossible throughput requirements.

You can't fix a lack of trains with a circuit network, no matter how clever your setup. Focus on realistic scenarios, that are (a) not starved for resources (b) not overprovisioned with trains (c) not underprovisioned and (d) have a healthy, balanced, demand from your factory. And don't assume outlandish scenarios such as "my trains need to travel 5 minutes to reach an outpost, but they only carry 1 wagon each".

Or else you'll solve problems that don't exist and you'll end up with 50-combinator circuits that are impossible to debug.

[NoriSilverrage]

Cool. Thanks for the pointers and explanation.
Reading over your post I feel like my station balancing setup is very clunky and like you said, doesn't really solve the specific problem. I was actually going to need to redo it anyway as I changed from 3 to 4 stations so once again I shall dive into logic systems..