Train station skipping conditions

[ssilk]

Ah, well, that "Leave-condition" is very different to a "Next-Target-condition".

Leaving a station is not critical. It doesn't matter much, when a train leaves a station (seen from game-logic), if I compare that with the implications you have, if the train just doesn't come.

My point was, that it is no good idea, if the train itself can change the schedule targets; that is - seen from many aspects - very different from just when should it leave a station. The problems won't appear, if the schedules are changed from outside of the train, cause from outside you have easier control over the rest of the environment.

[sparr]

Train Driver: "Where are we going next?"

Train Navigator: "Well, the schedule says we go to station X next. But it also says we should leave station X when we are empty, and we're empty now, so I know we'll just keep going through X to Y. How about we go straight to Y and save time?"

Train Driver: "Y, here we come!"

[ssilk]

The wait is no functionality of the schedule.
It works currently so:

Train: Next?
Scheduler: Station X. Wait there 30 seconds.
Train: I'm now at X. Next?
Scheduler: Station Y. Wait there until full.
Train: There is no Y (*). Next?
Scheduler: Station Z. Wait there until empty.
...

(*) That train stop has been temporally turned off.

The logic of the trains and the scheduler is simply stupid, because of many reasons.

[TheUnknown007]

Train: Next?
Scheduler: Station X. Wait there 30 seconds.
Train: I'm now at X. Next?
Scheduler: Station Y. Wait there until full.
Train: There is no Y (*). Next?
Scheduler: Station Z. Wait there until empty.

How about this:
Train: Next?
Scheduler: Station X. Wait there 30 seconds.
Train: I'm now at X. Next?
Scheduler: Station Y. Wait there until full or skip if you are already full. Are you already full?
Train: Yes.
Scheduler: Station Z. Wait there until empty. Are you currently empty?
Train: you for real here? I just said I'm full.
Scheduler: Station A. Wait for 10 seconds.

See? You can even keep the stupidity of the train scheduler.

My point was, that it is no good idea, if the train itself can change the schedule targets; that is - seen from many aspects - very different from just when should it leave a station. The problems won't appear, if the schedules are changed from outside of the train, cause from outside you have easier control over the rest of the environment.

Of course disabling the station and changing the schedule have different implications, that's the point. They can both be useful, and they both have their use cases (which partially overlap).
Also, I don't see why it would be a problem when a train decides to skip a station "by itself" (without that station being turned off, but because the schedule for this specific train said so) if the train system was build for it (or maybe even, if the train system was not build specifically so that this would NOT work)

[BenSeidel]

+1 for this idea.

Trains need the ability to make decisions by themselves, just like robots. Having the settings inside/outside of the train is more related to a global schedule system, not the stops and conditions of the schedule.

I have done up a good example GUI that should make it more clear what a GUI could look like. The Enabled Condition should be reasonably clear to anyone that has played with the signal network.

goto condition.jpg (65.16 KiB) Viewed 24867 times

In this way you could set up a stop to be enabled when it needs or has goods and a train to go to the appropriate stations when it can supply or pick up the goods. It would also be possible to set up the network to dispatch trains by using "command codes" (items in their wagons).

Many of the other solutions I have seen really don't sit well with me. I think that having to micro the train system is a good trade-off when compared to the throughput you get from it and this method gives you the most expressive power for the least number of mechanisms.

[ssilk]

Trains need the ability to make decisions by themselves, just like robots.

Sorry, but robots don't make decissions on themselves. They are ordered by the logistic network.

But that is a conditon of the station and not the schedule nor train.

Don't get me wrong: I'm jumping on the logical issues, that such a suggestion includes, as long, as they are fixed.

[TheUnknown007]

No, that is a condition for the schedule: if the train meets those conditions, it will go to that station, if not it will check the next station.

[ssilk]

If train contains X then goto station, otherwise next station which is itself? Hm. What is the difference to a wait-condition with the same condition: Leave if train cargo is more than X?

[TheUnknown007]

I think this is just a (bad) example: (why would a copper train check for circuits?) it would be more useful if there are two copper mines, and you can skip the second if the cargo is already full after the first.
Or, something that I would like: check fuel, only go to fueling station if you have less than 50 kJ fuel left (for example, I don't know how far you can get on 50 kJ)
Or a train that picks up all the stuff required for an item (like modules): don't go to the green circuit pickup if there are no more slots to be filled (or if you still have more than 50% of the capacity)

[BenSeidel]

Yeah, "bad" example, but really just there to illustrate the interface, not the reasoning behind the user's logic. I didn't even look at the station's name.

Trains need the ability to make decisions by themselves, just like robots.

Sorry, but robots don't make decisions on themselves. They are ordered by the logistic network.

Yes robots make decisions, it's just not something you can control directly (I wish you could), but indirectly through the type of chests you use. You don't ever see a robot moving back and forth between two chests carrying nothing do you?

The main issue with trains is that there is no mechanism to say "collect here when" and "drop off here when". If you compare it with the logistics network, that logic "built in". "Collect here when there are goods to collect", "drop off here when there is less that is being requested". You can also do some really intricate setups when you mix in the circuit network.

Also, everything in the tab marked "Schedule" is part of the schedule, including all stops and wait conditions and any other logic that would alter the trains behaviour.

[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.