TL;DRTrains can have two modes of operation: The already known hopping from stop to stop by name (which isn't touched here) and a new mode, that searches a possible stop by a condition.
What ?This new mode works like so:
Instead of a train stop name which is the next target of a train you can set up "conditions", which must either be present at one or more train stops or at the current train. Only if a condition evaluates completly to true that train stop is a candidate for the target of a train.
Conditions are looking like so (examples):
- Is there at any stop more than 2000 iron ore?
- Is my own fuel below 200 MW AND is there a "Refuel"-signal at any stop?
- Is there an "Unload"-signal AND any iron-ore signal?
For more complex logistics this can be simplified:
- Am I empty AND Is there a positive number of iron-ore (a provision)?
- Am I not-empty AND loaded with iron-ore and is there a stop with negative number of iron-ore (a request)?
So in general this works so:
Like now there are "entries of schedules" for a train. And the train goes from one entry to the next. But instead of train-stop-names the entries are conditions. So when train leaves a stop he jumps to the next entry (=condition), and then he will search through all train stops for this current condition. All candidates, that evaluate to true with this condition are then put into a list of possible train-stop-candidates.
By default the list is sorted by distance. But there could be other sorting criterias like
- Order descending by WAITING TRAINS * 5 and by number of TARGETING TRAINS * 3.
- Order ascending by distance * 0.1 and ascending by requested iron-ore (from train stop).
Result should be a very flexible much more logistic-like transport.
This new mode can be part of a research (kind of useful to have already trains fully researched and combinators also).
Why ?This is some kind of counter-suggestion to those suggestions, which want to mix the current usage of train-stop-names in combination with conditions. In my eyes the concept of train-stop-names in Factorio is really nice (and as said this isn't touched with this suggestion), but when used in combination with conditions, it gets soon very illogical and misunderstanding because of many small reasons, so I want to avoid this possible direction. Instead I want to introduce, that the schedule can be automated by setting signals on train stops and having some kind of program (the scheduling of conditions) in the train.
Names as part of a condition (which it is, when you look at the current system like so) is a dead end, when you see it from this direction, cause as long as the train-stop-name is part of the schedule any possible condition is pre-filtered.
Names are just names!