Why doesn't this "simple" dynamic train limit combinator setup work?
-
JoshuaJosephson
- Burner Inserter
- Posts: 11
- Joined: Thu Jul 18, 2024 8:00 am
- Contact:
Why doesn't this "simple" dynamic train limit combinator setup work?
Why doesn't this work?
It does as follows.
1)Count total number of ore in the chests, outputs it as 'O'
2) Divides 'O' by the cargo capacity from the CC (8.0K), and outputs this as L
3) Checks the limit against the Max 'M' from the CC. If L >=M, output M, and if L < M, output L. This should clip L at the Max that I have set.
4) The last arithmetic combinator is supposed to take either output of these 2 deciders, and cast that value to L depending on which one triggers.
This should make it so that the train stop only has a maximum of 4 trains assigned to it, but it dynamically goes down, and also turns off when L is not at 1 yet.
Unfortunately it does neither. everything works until step 4, but I am unable to get it to actually output L on the final combinator.
Re: Why doesn't this "simple" dynamic train limit combinator setup work?
In the last combinator, you're multiplying with signal "1", which has value 0 since it's never been set, not with value 1.
By the way, it's not best practice to disable train stations if you already arranged for train limits. Trains already on the tracks to some station will stop dead in the middle of the track if their destination will get disabled and no other station of that name has a train limit slot for them. Just use train limits alone.
By the way2, it's possible to do this limit calculation with 2 combinators instead of 5 for loading stations and with 3 combinators for unloading stations (since they additionally have to multiply by -1 to calculate the free space from station buffer size and chest content). You can do this by using 2 constants for the limit specification in the constant combinator instead of one, one for the real number and one helper.
By the way, it's not best practice to disable train stations if you already arranged for train limits. Trains already on the tracks to some station will stop dead in the middle of the track if their destination will get disabled and no other station of that name has a train limit slot for them. Just use train limits alone.
By the way2, it's possible to do this limit calculation with 2 combinators instead of 5 for loading stations and with 3 combinators for unloading stations (since they additionally have to multiply by -1 to calculate the free space from station buffer size and chest content). You can do this by using 2 constants for the limit specification in the constant combinator instead of one, one for the real number and one helper.
-
JoshuaJosephson
- Burner Inserter
- Posts: 11
- Joined: Thu Jul 18, 2024 8:00 am
- Contact:
Re: Why doesn't this "simple" dynamic train limit combinator setup work?
Wow is it really possible with just 2 combinators? By using 2 constants for limit specifications? Helper? What does this mean? I am a bit lost.By the way2, it's possible to do this limit calculation with 2 combinators instead of 5 for loading stations and with 3 combinators for unloading stations (since they additionally have to multiply by -1 to calculate the free space from station buffer size and chest content). You can do this by using 2 constants for the limit specification in the constant combinator instead of one, one for the real number and one helper.
Re: Why doesn't this "simple" dynamic train limit combinator setup work?
Look at this:
This is a loading station. We want train limit L=0 if the chests are empty, L=1 if there is one full train load of material, then L=2, up to 3 at maximum (the cutoff value).
Relevant are the 2 vertical combinators at the left. The horizontal bottom one is just for madzuri chest balancing and takes no part in train limit calculation.
The arithmetic combinator for division is dividing EACH by the blue signal, which is set to the train capacity. In this station, 16k (8 wagons * 2k=16k for ore). It's written to M and outputs 1 too much, because it also adds blue/blue=1. This is subtracted by the constant combinator with the bottom right M=-1, so M is correct again. The other values from the CC are too small and are nullified by the division.
From this M, the intended cutoff value is subtracted (M=-3 in the constant combinator).
Combined chest capacity is 48*48*50 = 115200 (for ore). So the maximum amount of trains is floor(115200/16000)=7
So instead of M=0..7, we get M=-3..4.
So we need to cutoff at 0, not 3.
If we cut off at 0, with the decider combinator at the left, we get M=-3..0. Or actually L=-3..0, because we cast the result to L.
Now add a constant L=3, and we get L := M+L = 0..3 which is conveniently exactly the limit range we want to set.
The downside is we have to set both a constant L=3 and M=-3 in the CC. For a cutoff value of 4, we need L=4 and M=-4.
About the CC:
most of its settings in my blueprint are just for notice to document train capacities and wagon amounts. The relevant values are:
L=<cutoff>
M=-<cutoff>
An additional M=-1 for correction
blue=train capacity [wagons * slots per wagon * items per slot]
The 4 constant combinators at the bottom are for demo and debug. By individually switching them on/off, you see what will happen with the train limit if the chest content increases by 1-4 train loads.
- 08-31-2024, 13-28-49.png (680.65 KiB) Viewed 485 times
This is a loading station. We want train limit L=0 if the chests are empty, L=1 if there is one full train load of material, then L=2, up to 3 at maximum (the cutoff value).
Relevant are the 2 vertical combinators at the left. The horizontal bottom one is just for madzuri chest balancing and takes no part in train limit calculation.
The arithmetic combinator for division is dividing EACH by the blue signal, which is set to the train capacity. In this station, 16k (8 wagons * 2k=16k for ore). It's written to M and outputs 1 too much, because it also adds blue/blue=1. This is subtracted by the constant combinator with the bottom right M=-1, so M is correct again. The other values from the CC are too small and are nullified by the division.
From this M, the intended cutoff value is subtracted (M=-3 in the constant combinator).
Combined chest capacity is 48*48*50 = 115200 (for ore). So the maximum amount of trains is floor(115200/16000)=7
So instead of M=0..7, we get M=-3..4.
So we need to cutoff at 0, not 3.
If we cut off at 0, with the decider combinator at the left, we get M=-3..0. Or actually L=-3..0, because we cast the result to L.
Now add a constant L=3, and we get L := M+L = 0..3 which is conveniently exactly the limit range we want to set.
The downside is we have to set both a constant L=3 and M=-3 in the CC. For a cutoff value of 4, we need L=4 and M=-4.
About the CC:
most of its settings in my blueprint are just for notice to document train capacities and wagon amounts. The relevant values are:
L=<cutoff>
M=-<cutoff>
An additional M=-1 for correction
blue=train capacity [wagons * slots per wagon * items per slot]
The 4 constant combinators at the bottom are for demo and debug. By individually switching them on/off, you see what will happen with the train limit if the chest content increases by 1-4 train loads.
Re: Why doesn't this "simple" dynamic train limit combinator setup work?
FWIW the (relatively) simple setup I came up with (though it wouldn't surprise me if it was a "reinvention") uses three arithmetic combinators (AC) and one constant combinator (CC) for belt-based item unload and load stops. In both cases, one AC is used for chest balancing, and the CC provides two item counts: B = buffer capacity, T = train capacity, which are set according to wagons per train, item stack size and desired maximum number of inbound trains.JoshuaJosephson wrote: ↑Sat Aug 31, 2024 11:09 am Wow is it really possible with just 2 combinators? By using 2 constants for limit specifications? Helper? What does this mean? I am a bit lost.
For unloading (from the train):
- AC1 (middle in blueprint below) has all buffer chests connected to its input, and computes each * -1 output B. This is the negative of the total buffered items. This combinator also serves to make the overall setup independent of the specific item type.
- AC2 (right) has AC1's output and the CC connected to its input, and computes B / T output L. Since the two B signals are summed, the output L is the number of full trains that can unload without exceeding buffer capacity. The output is connected to the train stop which is configured set the train limit according to L.
- AC3 (left) is used to control the inserters unloading the chests onto belts to ensure the chests remain balanced. It has all buffer chests connected to its input and computes each / -n output each, where n is the number of chests, ie the negative of the average items per chest. The output is connected to all the inserters, which are each connected to their respective chests (on opposite coloured wire) and enabled when everything >= 0. Again relying on summing the two item signals, this means each inserter is disabled if its respective chest contains less than the average.
Loading (to the train) is conceptually similar:
- AC1 (middle in blueprint below) has all buffer chests connected to its input, and computes each + 0 output C. This combinator serves to isolate signals and make the overall setup independent of the specific item type.
- AC2 (right) has AC1's output and the CC connected to its input, and computes C / T output L. This is the number of full trains that can be loaded from the chests, and is connected to the train stop which is configured to set the train limit according to L.
- AC3 (left) is used to control inserters loading the chests. It has the CC connected to its input, and computes B / n output C, where n is the number of chests, ie a per-chest maximum. The output is connected to all the inserters, which are each connected to their respective chests and enabled when everything < C. This means each inserter is enabled until its respective chest reaches the maximum.
AC3 is technically unnecessary for loading as it just computes a constant. I can't remember exactly why I did it this way; I think it was mainly for wiring aesthetics.
I also have a "cheat sheet" to copy the CC settings from for common stack sizes: