Train station skipping conditions

[mrvn]

Plus one on this one.

As to the question about train stations making the decision: This is a decision the train makes. But one of the conditions for the train is listening to the circuit network, which is reported to the train through the station. So if you want a train to stop at a mine only when it has ore to load then connect the buffer chests to the train stop and add a condition to stop at the mine if circuit network has ore > 1000.

Note: Having the train skip stops where the leave condition is already met should be simpler and already help a lot. No GUI changes required.

[ssilk]

Having the train skip stops where the leave condition is already met should be simpler and already help a lot. No GUI changes required.

Exactly. Would be easy to be implemented. Eventually already in 0.15.

[BenSeidel]

Having the train skip stops where the leave condition is already met should be simpler and already help a lot. No GUI changes required.

Exactly. Would be easy to be implemented. Eventually already in 0.15.

Would be easy to implement, but would not have the desired outcome. How would a circuit network signal interact with the trains wait condition? Does the train automatically "know" what the values of the network are for it's targeted station? How does this interact with multiple stations with the same name? does it still find the closest station or does it find the closest station that it does not skip? What happens when the signals change at it's target station? How does the "inactivity" condition work with this system? How would you get a train to skip a station when it's 50% full? How would it interact with the possible feature of letting the train stop read the trains contents?

Many stackers will have an issue with this as they use a signal to control the type of train to be let through. If a train can find at least one station that is letting a train through then it will skip the station, and hence the stacker - not the desired outcome. While the skip station based on wait conditions may be a "simple" change, it offers many many more corner cases where you just won't be able to get the desired outcome.

An explicit function, not a bastardisation of another function is always the best way to go, and not just in this example. Unless you can prove that one function is a subset of another function, always split the functions, as you can always merge them when the proof becomes available.

[TheUnknown007]

If it is absolutely certain that the condition will be true as soon as the train arrives at the station, you can skip it. This means that the situation can not change between evaluating and arriving. The only thing which cannot change between evaluating and arrival is the content of cargo of the train, so if a part of the condition between ORs (a term) consists of only <cargo X operator Y>, cargo empty and cargo full, this will also be true when the train arrives at its next stop, and so the train can skip that stop. This can be evaluated as soon as the train leaves its current stop.

[BenSeidel]

In that case your solution is extremely limited as it's entirely incompatible with any form of network condition, time out or inactivity timer. Not to mention that you would need to have a "cargo contents" condition to enable checking for specific goods, otherwise it's not really going to be more useful than the current wire based solutions that exist already.

A common system I implement is to have trains travel from outpost to outpost picking up small-ish amounts of ore then returning to the base, waiting in a stacker, then proceeding to be unloaded when required. Your system offers no way of telling the train to skip the stacker and unload station when it's not full, nor does it allow the train to skip all the subsequent pickup locations if the train is full.

The solution this thread details is designed to allow all forms scheduling design solutions, especially when combined with the ability to enable/disable train stops via a circuit network, not just the limited subset that is your particular issue.

[TheUnknown007]

Of course this solution would not be something that I would consider done. It's just something that can be implemented quickly before we get an actual solution where we can turn off train stations or let trains skip them. And it would most probably not break when you implement the actual solution (ie. this can simply stay in the game alongside any other more complicated solution)

The cargo contents condition already exists, it's called item count.
For your example: add the following to the stacker (why exactly does this have a train stop in the first place?) and unloading station: "OR cargo X < MAX_CAPACITY", with X your ore and MAX_CAPACITY the maximum amount of ore the train can hold (50 * number of slots per wagon * number of cargo wagons). If you have multiple types of ores at random in the train, you will have to enumerate all possible combinations, which is possible, but not doable. So this system only works if you know exactly what will (not) be in the train when you want to skip something.

[BenSeidel]

The cargo contents condition already exists, it's called item count.

Haha, you're correct. I even used it in my example

The other cargo content conditions should be allowed as well - such as cargo full and cargo empty. I would just like to be able to set it so that the train skips the load station when it's more than 50% full, or skip the unload station when it's less than 75% full, but still have it completely load or unload when it arrives.

So if your solution is incomplete, why would you have the developers put in such a stop-gap measure, diverting their time away from completing other tasks?

[ssilk]

Exactly. Would be easy to be implemented. Eventually already in 0.15.

Would be easy to implement, but would not have the desired outcome. How would a circuit network signal interact with the trains wait condition?

The logical solution: If condition in train stop is false the train-stop is like "disappeared". Not available. The train would then continue, no matter what waiting condition.

Does the train automatically "know" what the values of the network are for it's targeted station?

Why did he need that?

How does this interact with multiple stations with the same name?

The station is like removed.
... rest is self-expanatory.

Many stackers will have an issue with this as they use a signal to control the type of train to be let through. If a train can find at least one station that is letting a train through then it will skip the station, and hence the stacker - not the desired outcome. While the skip station based on wait conditions may be a "simple" change, it offers many many more corner cases where you just won't be able to get the desired outcome.

EDIT:
This is hard to impossible to understand and maintain, hard to implement and takes in the end too much CPU cycles, if you have many trains, cause the conditions can change in every moment. There are nearly always more trains than stations.
I wrote that to remember what I want to say, made some search in the forum and hit accidentially Submit instead Preview before I was interrupted. See my next post!

[TheUnknown007]

Many stackers will have an issue with this as they use a signal to control the type of train to be let through. If a train can find at least one station that is letting a train through then it will skip the station, and hence the stacker - not the desired outcome. While the skip station based on wait conditions may be a "simple" change, it offers many many more corner cases where you just won't be able to get the desired outcome.

This is hard to impossible to understand and maintain, hard to implement and takes in the end too much CPU cycles, if you have many trains, cause the conditions can change in every moment. There are nearly always more trains than stations.

What does 'this' refer to?
And I have not seen a single base where there were more trains than train stations.

[ssilk]

Forgive me, I posted this by accident. Just delete this two sentences. They where written in hurry and don't reflect my real thinking in any way, just a spontaneous thought. I was about saying something, why waiting conditions in the trains is not so a good idea, then I remembered, that I have already written about the reasons and searched a bit around and then my cousins wanted to play a card game with me and it seems, so that I hit accidentally Submit instead of Preview.

Off-topic:

And I have not seen a single base where there were more trains than train stations.

Well, I have, and that explains all those complicated thinking with train-exchange-points, waiting-conditions etc. that I see the last weeks. Cause if you have more stations than trains, you need to make routing-things complex.

Think to reality: There are always more trains than stations and that makes things in most cases really easier. Cause you don't need to make complicated routing. One or two things to transport from/to two or eventually (!) three and in rare cases four stations. Plus refueling...


But well, as above we are here in personal taste. Some like it complex.

[BenSeidel]

The logical solution: If condition in train stop is false the train-stop is like "disappeared". Not available. The train would then continue, no matter what waiting condition.

The enabling and disabling of the train stop via a circuit condition is already implemented. It is also a different mechanism to the circuit condition wait condition on the train schedule. My questions was in regards to the behaviour of the schedule wait conditions that contained a circuit condition as the "skip if it can" will not work well with a circuit controlled network.

As to the complexity issue, It's not hard once you know how. I still don't understand how people have issues signalling intersections.

[TheUnknown007]

The enabling and disabling of the train stop via a circuit condition is already implemented.

It is?
If that is already implemented, this thread would be done, right?

[vipm23]

The problem with that is disabling the train stop disables it for all trains, not just one with a particular condition.

The whole point of this suggestion is to let trains skip stations without interfering with other trains going about their business.

Personally would prefer a go-to-station condition, but I can work with skipping stations.

[ssilk]

If that is already implemented, this thread would be done, right?

I left it still open, cause the original idea was to control the train or the waiting conditions instead of the stops.

The problem with that is disabling the train stop disables it for all trains, not just one with a particular condition.

The problem depends, on how you want to do things.
Using more trains makes it easier.

[TheUnknown007]

Picture of a train stop with circuit network GUI open.

FactorioNoSkipTrainStop.png (261.59 KiB) Viewed 6470 times

Where is it?
How do I disable this train stop?
You guys are talking about it like it is already implemented (version 0.14.21, no new updates found)

(it = disabling train stops)

[ssilk]

See above.

Eventually already in 0.15.

In other words: AFAIK in comes in 0.15.

[BenSeidel]

The enabling and disabling of train stops is marked as implemented in the signal pole viewtopic.php?f=9&t=30853.

The problem depends, on how you want to do things.
Using more trains makes it easier.

Exactly

[TheUnknown007]

Aha, I had not seen that yet. Nice. But alas, it is not enough. I shall not rest until we can send trains to specific stations on specific conditions!

I am personally in favor of skipping conditions, because the implementation is far more intuitive as far as I can see (as in, for pretty much every design choice, there is only one logical decision):

• When do you check these? --> we check whether we want to skip a station at the moment we would decide to go to that station if the skipping conditions were not met (by definition of skipping). We decide to go to the station when we leave the one before it, so that is the one and only moment we would have to check the skipping conditions.
• In what order do we check these conditions? --> we can simply loop through all train stops in the schedule: for each one after the current station: is the skipping condition met? --> check the next station; else --> go to this station. This takes at most one full loop through all stations, but probably far less (since most of the time, the skipping condition for the next station wil not be met, unless your rail network is crazily complicated)
• What if multiple (but not all) train stops should be skipped? --> Go to the first one that should not be skipped, as described in the point before this one (this point is here to contrast the go-to conditions).
• What if all train stops should be skipped? --> stay where you are. This might block other trains, but I argue that that's user error: you should have designed your rail system differently if that is a problem. (maybe add a dummy station where trains can always go and wait there until they can go somewhere else. Make sure there are more dummy stations than trains that want to wait there, because otherwise some trains will be waiting to get to the dummy station and are essentially blocked until they get there.)

While conditions for going to a station are a bit harder:

• First of all, this takes a bit more resources (in the form of CPU time): to check these conditions, we always have to check all stations in the schedule to see whether their go-to conditions are met.
• When do you check these conditions? Should we check them continually (when it is possible that they might change, like when the train is at a train stop)? Or only when the leaving conditions for the current stop are met? Although the second option would work much nicer for pretty much all use cases, the first one is much more intuitive: we go to a station as soon as the go-to conditions are met. The first option is also incredibly resource intensive: each tick, for every train that is parked at a station, check whether one of the go-to conditions hold.
• What if multiple go-to conditions are met? We can either go to the first station in the schedule (where the conditions are met), or we can go to the earliest station in the schedule (i.e. if we would drive the schedule normally from the current stop, what would be the first stop where the go-to conditions are met right now? This is the same as for the skipping conditions, except that we try to find the first station where the conditions are met instead of not met). The second option brings a new edge case: what if we should go to the current station? --> I think that it would be most logical to exclude the current station to avoid deadlocks, although you could argue that this is a user error: why would you make it possible for the train to go to a station and leave as soon as it arrives there? Avoiding that is the whole point of this feature)
  I think both options are pretty logical, and they both have different use cases. I would argue that maybe we should implement both functions, but that sounds suspiciously like feature creep, and it would (unnecessarily?) complicate the UI and the system (system here means the logical train system, not the implementation. The only difference between the implementations is the starting point where you start checking for the go-to conditions). The first one sounds pretty useful to me (it can be used to send trains to the stations with the highest priority), but the second one can more easily and generally be used to simulate the first one by adding the negation of each station before this one, for example:
  
  Schedule in the first option:
  
  A go to if X
  B go to if Y
  C go to if Z
  
  The behaviour should be pretty self explanatory. To simulate this behaviour with the second option:
  
  A go to if X
  B go to if Y and not X
  C go to if Z and not X and not Z
  (this is technically not entirely possible, because conditions like "cargo full" cannot be fully inverted yet (this can only be done if you know what type of cargo there will not be if it is not full, as in "Coal < 800")
  
  The first option can be used to simulate the second option, but that would be complicated. Here is a schedule in the second option:
  
  A go to if X
  B
  C
  D go to if X
  E
  F
  
  If X is met, the second option would have the train go to A if the train is at D, E or F, and to D if the train is at A, B or C.
  The way to simulate this behaviour with the first option would be to have each station give a signal so that the train knows where it is. In this example, if we change it to
  
  A go to if X and blue signal = 1
  B
  C
  D go to if X; always has blue signal set to 1
  E: always has blue signal set to 1
  F: always has blue signal set to 1
  
  We have simulated the behaviour of option 2. However, this behaviour is pretty fragile, as you have to remember these signal invariants and apply them to new stations when you add new stations. It is also a lot of work, but simulating option 1 with option 2 is also a lot of work (although a bit less).
• What if all go-to conditions hold? --> just an extreme case of the previous point. This point is here to contrast the skip conditions.

[ssilk]

That is in long form and with good examples my arguing against letting trains decide, where to go, but instead let stops decide, cause they are much closer to the things, that matter.

[TheUnknown007]

That's not true, in my base, it's the train that knows what it needs, not the station.
Example: I have train that goes to about six supply stations before returning to a factory outpost. This train sets out as soon as any of the supplies run out, but it could skip all other stations. However, each supply station is for multiple trains, so disabling the station is not an option.