Dynamic train schedule

[RubeGoldbug]

TL;DR

'Tis yet another topic mentioning the lack of dynamics in the trains' schedule. I believe a pretty clean and concise solution has been brought in several topics listed below (entry/skipping conditions), and I would quite like to have a recent devs' perspective on this.

What ?

The suggestion is to add a way for the player to have a more complete way to schedule trains, while keeping it simple and very close to the already existing system. As in the listed topics below, I think the most simple/efficient/powerful solution is to add train entry, or (equivalently) station-skipping conditions. For the moment, when a train is at a station, it checks for a set of condition to know when to leave. The suggestion is to add at this precise moment a set of conditions to know if the next station in the schedule can be skipped.

Why ?

I believe it would be a necessary feature to complete the way trains' schedule works; for the moment, I really feel like it is functional, yet not finished. Trains feel more like extremely long belts rather than trains.

I would like to anticipate future links to existing mods by saying this: it should be something the vanilla game has to offer. It is not a modification, and not nearly something as complex as stuff like TLN or Fat Controller offer. However, it could be extremely powerful and have a great impact for factories heavily based on trains. In fact, I find it quite weird to see such an asymmetry still living after such a long time in such an OCD friendly game : you can manage how a train leaves a station but not how it enters it?
In short, it is not a mod, it is a lacking feature.

Next anticipation: turning off the stations. It IS different from having the possibility to turn on/off stations. These two mechanics are distinct and offer distinct possibilities. Basically, these are equivalent if and only if you have less than or exactly one train per station, so not exactly a universal thing.

Next anticipation: "the decision should be made at the station and not in the train". I read this several times in the older threads and I think it just doesn't make sense. I can develop further on this in the next posts if someone asks, but I believe the argument is invalid.


Realted threads (in chronological order):
viewtopic.php?f=6&t=25944 Train stations skipping conditions
viewtopic.php?f=6&t=49214 Train entry conditions
viewtopic.php?f=6&t=50128 New Train-Schedule-Mode / Conditions instead of Train-Stop-Names / Remove Names from Train-Schedule
viewtopic.php?f=6&t=53792 Train-stop id and train targets a train-stop by id(a bit off-topic)
viewtopic.php?f=6&t=58057 Trains ignore stop if wait conditions are already met
viewtopic.php?f=6&t=58646 Jump on train automation
viewtopic.php?f=6&t=59378 Train-side stop disabling and a toggle for station skipping

Example picture from the Train entry conditions topic:




@mods: I allowed myself to create a new topic in this forum because I did not know where to post it, nor which topic I should have bumped in order to be seen. I sincerely wish to get some attention (from devs and the community) on this because it has been itching me for way too long, and I think it is a detail of great importance for the train system. Feel free to move/merge this topic wherever you think it should be.

[Tekky]

I agree that train entry/skipping conditions would be an important feature.

However, OpenTTD style conditional jump orders may be better, since they allow you to jump to any order in the train's schedule, thereby allowing you to skip several orders at once, instead of only one order per entry/skip condition.

Next anticipation: "the decision should be made at the station and not in the train". I read this several times in the older threads and I think it just doesn't make sense. I can develop further on this in the next posts if someone asks, but I believe the argument is invalid.

I agree that there certainly are situations for when the condition for entering a station should be determined by a train condition and not by a station condition. One such example would be a refueling station.

[Koub]

If I understand things correctly, what you're basically asking for is a programation language for train flow control.
There are indeed a lot of threads around this topic, and I don't feel like merging all of them, because I think they spread over a too wide spectrum, and I fear it would make the resulting thread unreadable.

Whatever solution is implemented in the definitive version of Factorio should at least be accessible to the newcomer who hasn't OpenTTD (or any other similar logistics simulation game) experience, and if possible, also offer advanced possibilities for experienced players to fine tune their train network. But the number one requirement should always be "you can play the game even if you're a n00b on these subjects".

[Darinth]

Whatever solution is implemented in the definitive version of Factorio should at least be accessible to the newcomer who hasn't OpenTTD (or any other similar logistics simulation game) experience, and if possible, also offer advanced possibilities for experienced players to fine tune their train network. But the number one requirement should always be "you can play the game even if you're a n00b on these subjects".

I agree and it's ultimately the problem. I expect that Wube has heard the requests and hope that they're talking internally, because I've seen this specific topic of increasing the flexibility of train scheduling come up numerous times just in the short period of time I've been paying attention to the forums. I think they know that we want enhancements to train scheduling, hopefully we'll see something to address it.

[CJ5Boss]

I agree. I also think that sometimes, the train schedule UI elements are a bit confusing (especially the Wait conditions) and I like the "Go if" change. It would make it much easier to understand the train schedule and making it.

[RubeGoldbug]

Oh wow, thanks for the quick answers!

However, OpenTTD style conditional jump orders may be better, since they allow you to jump to any order in the train's schedule, thereby allowing you to skip several orders at once, instead of only one order per entry/skip condition.

If I understand things correctly, what you're basically asking for is a programation language for train flow control.

Well, I'd say it depends on what you mean by a programming language . But yes, I guess it's what I am asking for. After all, we NEED to be able to program trains, that's the purpose of the schedule! So the programming language is already there, given by Factorio itself, right?
Don't get me wrong: I don't want to make unrealistic requests about an overhaul of the current system (which I think it works quite well, btw). To answer to Tekky, it's the main problem about the conditional orders of openTTD. It looks super powerful, but I guess it would require huge changes in Factorio's system. So what I would like is to find a compromise. The idea here is simply to use the existing tools: we have conditions for the trains to leave: "Wait until ...". All I'm saying is that maybe there's a way to use the same conditions for a "Skip if ..." or "Go if ..." function, with the usual conditions, just as illustrated in the picture. I think it would allow for a very fine tuning, since we could control both the train schedule and the stations availability.
So I am not thinking about a whole package of console plus some Lua scripting or whatever, if that's what you mean. I'm more interested in the Factorio programming language

Another argument about not going full openTTD is that it does not fit so well to the spirit of the game. I think it's more on point to have (almost) brainless trains with their fixed schedule, rather than an incredibly smart network of trains. BUT, skipping conditions simply allows to optimise a lot the way trains behave while keeping this "automation" spirit and I'd really love to see something close to it in the game.

On a side note, even though "Skip if" and "Go if" are basically the same, I think it's probably better to have "Skip if", it feels more natural for a fixed schedule. Well, that's really secondary anyway.

Whatever solution is implemented in the definitive version of Factorio should at least be accessible to the newcomer who hasn't OpenTTD (or any other similar logistics simulation game) experience, and if possible, also offer advanced possibilities for experienced players to fine tune their train network. But the number one requirement should always be "you can play the game even if you're a n00b on these subjects".

I agree, and that's where the difficulty lies. But it also should not be a reason to keep the system too simple, because it can become unpractical. Honestly, I have never played openTTD and I have an extremely small experience with logistics games other than Factorio. Yet, I just had a look at the openTTD system and it is far from cryptic. It seems very complex as in you can do a lot of specific/precise actions, yet it seems also quite easy to grasp quickly and do simple tasks.

To make an analogy with the logic modules (combinators and such), I think it's possible to play without it, to play with it at a basic level, or to do Turing machines. Well, IMO it could be the same with the train schedules! And I'm pretty sure having skipping conditions could be the way to keep the system close to what is already here, and to add flexibility without adding difficulty. In that case, the system should be able to be used at different levels of complexity, according to the player's wishes.

See also my above argument on why we need to gain flexibility without going full TTD.

Finally, it seems like a rather intuitive way to program the train, so it should not be a problem for newcomers?

I agree. I also think that sometimes, the train schedule UI elements are a bit confusing (especially the Wait conditions) and I like the "Go if" change. It would make it much easier to understand the train schedule and making it.

Yes, I had trouble with the UI as well when I first started with trains, but I don't want to make several requests and mix everything. IMO the train UI could use an overall rework but it is not a priority, more something of QoL for later.

[ThaPear]

A conditional skip isn't very complex, even if you haven't played OpenTTD.

Consider this very simple example (which doubles as use case), where I've omitted the wait conditions for brevity:
1. Goto "Ore Pickup 1"
2. If Ore >= 2000 jump to 6
3. Goto "Ore Pickup 2"
4. If Ore >= 2000 jump to 6
5. Goto "Ore Pickup 3"
6. Goto "Ore Drop"

Where (If you cannot see already) the following will happen:
1. The train goes to "Ore Pickup 1" to pick up ore.
2. If the train has a wagon full of ore, it goes to the drop off.
3. If not, it continues to "Ore Pickup 2" to pick up more ore.
4. If the train has a wagon full of ore, it goes to the drop off.
5. If not, it continues to "Ore Pickup 3" to pick up more ore.
6. Now it goes to the drop off regardless of its ore contents.

[RubeGoldbug]

A conditional skip isn't very complex, even if you haven't played OpenTTD.

Consider this very simple example (which doubles as use case), where I've omitted the wait conditions for brevity:
1. Goto "Ore Pickup 1"
2. If Ore >= 2000 jump to 6
3. Goto "Ore Pickup 2"
4. If Ore >= 2000 jump to 6
5. Goto "Ore Pickup 3"
6. Goto "Ore Drop"

Where (If you cannot see already) the following will happen:
1. The train goes to "Ore Pickup 1" to pick up ore.
2. If the train has a wagon full of ore, it goes to the drop off.
3. If not, it continues to "Ore Pickup 2" to pick up more ore.
4. If the train has a wagon full of ore, it goes to the drop off.
5. If not, it continues to "Ore Pickup 3" to pick up more ore.
6. Now it goes to the drop off regardless of its ore contents.

I agree, and that's precisely the use-case I had in mind when opening the thread, I just erased it before Submit. BUT, everything in this example can be done with skipping conditions: you basically put the same skipping condition (ore >= 2000) for your 3 pickup stations, which is why I wanted to give this example. I also think it should not be too complex for a newcomer, but some people seem to disagree.

However, when I'm talking about complexity, it's about the complexity of the changes it requires. I am not a developer, but I can imagine why it's often more complex and time-consuming to redesign your whole system instead of using what you already have (up to a certain point, for sure). So again, my goal is to find a compromise as close to what already exists for the moment as possible, while offering the most flexibility.

[Koub]

I've seen the devs redesign things even for a small improvement if they thought it would be for the best of Factorio. We, community, give them hints on what we feel needful of, and if they can make sense out of it, and feel it would make a better game, I'm confident they'll do something.

[Darinth]

As a possible alternative to doing using programming-language-esque goto statements, simply attaching a "Skip if..." condition to stations meets most people's requirements and keeps the system operating mostly as it currently does while meeting most operating parameters. Combining that functionality with the ability to limit the number of inbound trains to a station generally seems to do a good job of meeting everybody's requirements. Both of these have shown up in previous suggestions.

[rldml]

i want to remind, that this suggestion (viewtopic.php?f=6&t=53792 Train-stop id and train targets a train-stop by id(a bit off-topic)) is in fact a little bit offtopic (most people demands a direct skip-condition).

But to say it clearly: With that little change you get far more control at train logic. You could build the skip-if-condition with circuit logic. To be fair, it would not be an easy one, but it will be possible. And in comparison to the other suggestions, you just have to add only one option in the train-sceduling-ui: "drive to train stop with id x".

So, the train network would work like now for beginners (with exactly the same user experience), but expert gamers would have all options in their hands to make the train network as complex and intelligent as they need it.

[AntiBlueQuirk]

How about this? It's basically exactly the same as a normal station entry, except that it has a target order instead of a target station.

conditional-goto.png (146.97 KiB) Viewed 14908 times

Basically when it gets to order 3, as long as it has more than 50 coal, it skips to order 1. Otherwise, it goes onto order 4, where it can get more fuel.

My only concern with this mockup is that the goto target replaces the station name, so goto orders themselves don't have names, so there's no way to use a goto order as a target. But that's a minor annoyance, and it would still be a powerful system. (There are some simple ways to fix that too.)

Goto orders could probably also be a bit more distinct from regular orders.

[McDuff]

Yeah I think "If... then goto...else" isn't a terribly hard system for people to learn, especially if it's arranged in a graphical list. I'd love to see something like this happen tbh.

And, as has also been suggested, a "line" mechanic where schedules aren't linked to single trains but trains get assigned schedules from a list, so changing conditions can change many trains at once.

[WarDaft]

I don't think I support this being in the base game.

Don't get me wrong, trains are awesome, and anything that gives you more advanced train control or more reason to use trains are also awesome...

But in the base idea of Factorio? You completely can (and in fact benefit substantially from) not actually ever overlapping any two sets of rails. No recipe in the game is complicated enough to actually justify a complex train network, you just need to move stuff from point A to point B faster and better. In the long run, you actually suffer UPS wise if your train scheduling is too complicated, and that is flat out not something that can be fixed.

If you didn't know ahead of time what you will need where and how often, then yes, you would need these kinds of tools. But you do know, exactly, how much and exactly how fast you need each item in each possible location. And the recipe tree does not even require crossing, splitting, or joining tracks, let alone advanced decision making features.

Now, as a mod I would download the hell out of this, but I am in grave danger of becoming a train nerd, and most people are not. So this would not be, I think, a good addition to the game.

[Tekky]

In the long run, you actually suffer UPS wise if your train scheduling is too complicated, and that is flat out not something that can be fixed.

What makes trains expensive in terms of UPS is mainly train pathfinding. Processing train orders, even if these are conditional train orders, is computationally very inexpensive compared to that.

[rldml]

But in the base idea of Factorio?

I have strong feelings that you simply doesn't understand the meaning of the words "automate everything". Actually you simply can't because the lack of scheduling options.

You completely can (and in fact benefit substantially from) not actually ever overlapping any two sets of rails. No recipe in the game is complicated enough to actually justify a complex train network, you just need to move stuff from point A to point B faster and better. In the long run, you actually suffer UPS wise if your train scheduling is too complicated, and that is flat out not something that can be fixed.

BULLSHIT.

You have x iron ore patches in different distances with the same name. You have y trains, where y is a count of trains you need to satisfy your iron ore needs. You define every ore patch to only activate if it has at least enough ore to fill a train (That is the maximum in optimizing train network today). You will experience that the trains will congregate at the nearest enabled station. They will not distribute equally to all ore patches. Instead of x trains filled at the same time, you will have only one train filled and all other trains wait patiently blocking the complete train network point.

The ONLY(!) one way to prevent this behavior is to name every iron ore patch differently and set up trains for every iron ore patch separately.

That is really far away from "automate everything"!

If you didn't know ahead of time what you will need where and how often, then yes, you would need these kinds of tools. But you do know, exactly, how much and exactly how fast you need each item in each possible location. And the recipe tree does not even require crossing, splitting, or joining tracks, let alone advanced decision making features.

That's simply not true. You can calculate, how much ressources a part of your factory need in a defined part of the time. That's it. There's nothing more you can do before it start working. The only thing you can do after that and in a long term is to prepare your factory to have enough ressources all the time.

And even if you really know every detail of your factory that you really could archieve which amounts of ressources you need at which parts of your factory in which moments, that is far more complicated for a beginner than simply tell your train "to skip station x, because you're full of ore".

Now, as a mod I would download the hell out of this, but I am in grave danger of becoming a train nerd, and most people are not. So this would not be, I think, a good addition to the game.

Actually there is no way to mod this in an efficient manner: The API only support "calculate path to train stop with name". The existing mods like LTN doesn't resolve this problem, they just work around it (and yes, that cost much more UPS than a native API-support of "calculate path to train stop with id" or "check skip conditions, if true, skip to next schedule entry in array") or simply ignore my problem i described earlier.

[Trebor]

The ONLY(!) one way

There is no "only one way", there is only optimal and sub-optimal.

you will have only one train filled and all other trains wait patiently blocking the complete train network point.

If you have one train blocking another train it's only because you didn't lay track to bypass the block.

When all your trains rush to a station, after the first one arrives if the others have a path to another station they should reroute at the next signal.

[AngledLuffa]

When all your trains rush to a station, after the first one arrives if the others have a path to another station they should reroute at the next signal.

This doesn't always happen unless you disable the station. If the station is still active, other trains will wait if the next station is far enough. If you have three mines and two trains, and all three are producing fast enough to support two trains, the two trains might both wait at the first station and the other two stations starve. Then because the loading time is slow enough, you wind up not shipping enough iron and your base starves for iron. The easiest solution is to name the three iron mines something different and assign different trains to each one.

[rldml]

you will have only one train filled and all other trains wait patiently blocking the complete train network point.

If you have one train blocking another train it's only because you didn't lay track to bypass the block.

Yeah, you could build a stacker at every ore patch, but this isn't what you want. You need trains that distribute equally, even if some ore patches are far away. Trains in a ore patch stacker makes absolutely no sense if another ore patch could fill the train instantly.

When all your trains rush to a station, after the first one arrives if the others have a path to another station they should reroute at the next signal.

That doesn't help, unless all ore stations are in the same direction. In most factorio games i played are ore patches distributed in all directions.

[rldml]

At least, skipping stations is now moddable:

https://lua-api.factorio.com/latest/Lua ... to_station

Go to the station specified by the index in the train's schedule.

viewtopic.php?f=3&t=65070

Greetings, Ronny