Assign Trains to Schedules (Train Routes)

[5thHorseman]

Before this topic came up, I wasn't even aware that you could rename trains.

There isn't. And I've wanted it since I started using them.

[5thHorseman]

Did anyone tell you that you can name 2 stations the same so trains would pick a station?

Me specifically, no. But I learned it from watching a Let's Play, and doubt I'd have ever stumbled upon it on my own.

[mrvn]

Did anyone tell you that you can name 2 stations the same so trains would pick a station?

Me specifically, no. But I learned it from watching a Let's Play, and doubt I'd have ever stumbled upon it on my own.

So this needs to be in a tutorial. But after you saw it once it became second nature, right?

[5thHorseman]

Did anyone tell you that you can name 2 stations the same so trains would pick a station?

Me specifically, no. But I learned it from watching a Let's Play, and doubt I'd have ever stumbled upon it on my own.

So this needs to be in a tutorial. But after you saw it once it became second nature, right?

Oh yes. I don't think I'd like trains nearly as much if I didn't use that trick in almost every station in my network. Similarly, I'd quickly adopt dropping a train and naming it to instantly set its schedule.

[Longbolt]

Assign Trains to schedules instead of creating schedules for Trains over and over again.

At the Moment we have to create schedules for every Train or copy them over. A more simlplier and intuitive Way would be to create a Schedule and assign Trains to it.
This would maybe also allow it to rename Trains as a nice side effect.

One could also add one Train into multible schedules which opens up a lot of new possibilities to effectivly manage masses of Trains (like on a Train World).

Pretty sure the devs are working on something of this nature: https://www.factorio.com/blog/post/fff-212

[mrvn]

Assign Trains to schedules instead of creating schedules for Trains over and over again.

At the Moment we have to create schedules for every Train or copy them over. A more simlplier and intuitive Way would be to create a Schedule and assign Trains to it.
This would maybe also allow it to rename Trains as a nice side effect.

One could also add one Train into multible schedules which opens up a lot of new possibilities to effectivly manage masses of Trains (like on a Train World).

Pretty sure the devs are working on something of this nature: https://www.factorio.com/blog/post/fff-212

No, that was about a new UI for the existing train schedule.

[rldml]

Another solition would be something like this:

viewtopic.php?f=6&t=53792&p=315599#p315599

The train-stop need a way to send a defined signal of it's own id to the circuit network, similar to the train id it can read and send to network (e.g. "Send your ID to network, use signal 'S'")

Additionally, trains need a option to drive to a station it get signalized via train-stop ("e.g. next Station: Read Signal 'S' from actual train-stop and drive to train-stop with corresponding id").

With these change you would have the ability to design a dynamic schedule, based on circuit network signals. There would no further need for separated schedules, because the schedule looks the same between the trains and you just add train stops per id.

With your example with three mining outposts: You build a circuit network logic, which tells the next train in the stacker to which train stop it has to drive. If you add more trains, you simply add them at your stacker and copy the existing schedule-logic to the new trains.

[mrvn]

Another solition would be something like this:

viewtopic.php?f=6&t=53792&p=315599#p315599

The train-stop need a way to send a defined signal of it's own id to the circuit network, similar to the train id it can read and send to network (e.g. "Send your ID to network, use signal 'S'")

Additionally, trains need a option to drive to a station it get signalized via train-stop ("e.g. next Station: Read Signal 'S' from actual train-stop and drive to train-stop with corresponding id").

With these change you would have the ability to design a dynamic schedule, based on circuit network signals. There would no further need for separated schedules, because the schedule looks the same between the trains and you just add train stops per id.

With your example with three mining outposts: You build a circuit network logic, which tells the next train in the stacker to which train stop it has to drive. If you add more trains, you simply add them at your stacker and copy the existing schedule-logic to the new trains.

So for a fully dynamic setup you would have just one station in the schedule: "Read Signal 'S': Wait for Condition G=1". Then at each station you send S for the next station and G=1 when you want the train to leave. I like it.

[rldml]

So for a fully dynamic setup you would have just one station in the schedule: "Read Signal 'S': Wait for Condition G=1". Then at each station you send S for the next station and G=1 when you want the train to leave. I like it.

Exactly. Simplify the schedule, make the circuit network logic more important and more valuable for the game. The possibilities to autmoate even the complex stuff in vanilla would greatly increase...

In german we describe that with the phrase "Passt wie Arsch auf Eimer" - an vulgar variant of "it fits perfectly"

Greetings, Ronny

[mrvn]

Very hard to implement and understand for the user though. I still prefer if you would set a fixed schedule but have a signal to select the train station from the schedule the train should go to next, e.g. S=3 makes it go to the 3rd entry in the schedule. But the two are not exclusive.

[rldml]

Very hard to implement

I feel confident, that train stops have an internal id actually and we just don't see them - like the train id you can use already. So, all what the developer have to do is to extend the ui/api of the game so we have (read)-access to this value and add a scheduling option for trains. It cannot be _that_ hard.

and understand for the user though.

Like everything else what's using circuit logic?

My suggestion has not the target to remove the existing possibilities to schedule trains, it enhance it.

I still prefer if you would set a fixed schedule but have a signal to select the train station from the schedule the train should go to next, e.g. S=3 makes it go to the 3rd entry in the schedule. But the two are not exclusive.

To use something like this, you have to rename your ore-outposts differently so a train can distinguish them, but of course it's a solution for the same basic problem we have actually...

[mrvn]

Very hard to implement

I feel confident, that train stops have an internal id actually and we just don't see them - like the train id you can use already. So, all what the developer have to do is to extend the ui/api of the game so we have (read)-access to this value and add a scheduling option for trains. It cannot be _that_ hard.

I mend for the user to implement. Lets see, this coal needs to go to the steel smelter. Was that ID 4532 or 4523?

[rldml]

I mend for the user to implement. Lets see, this coal needs to go to the steel smelter. Was that ID 4532 or 4523?

Ah ok, now i got your point.

But this problem is only how you organise your base:

Let us assume, you have three outposts, that needs coal. Then you can set up the train stations of the outposts to send their id through separate networks to a coal-stacker somewhere on your map at the moment they need more coal. Your stacker reads every network separatly through circuit logic. If there is a signal on one of the networks, it knows it has to send a train to the submitted id.

As a player, you shouldn't memorize separate ids (you don't do that with trains either). If you have to use memorized ids by yourself, work with station names like before.

[mrvn]

I mend for the user to implement. Lets see, this coal needs to go to the steel smelter. Was that ID 4532 or 4523?

Ah ok, now i got your point.

But this problem is only how you organise your base:

Let us assume, you have three outposts, that needs coal. Then you can set up the train stations of the outposts to send their id through separate networks to a coal-stacker somewhere on your map at the moment they need more coal. Your stacker reads every network separatly through circuit logic. If there is a signal on one of the networks, it knows it has to send a train to the submitted id.

As a player, you shouldn't memorize separate ids (you don't do that with trains either). If you have to use memorized ids by yourself, work with station names like before.

For that you would need separate circuit networks for every item you deliver. And wireless connections to a logistics network would be problematic. Before LTN I had 50+ stations needing fuel. That would mean getting 50 separate wires to the stacker from all over the map.

Would probably make more sense to design a protocol with collision detection on the wire. E.g. have each station try to send N=1 and S=<id> on the wire at random intervals. Only when N=1 the train will move. Otherwise there was a collision.

[Jon8RFC]

My interpretation:
1) Everything works exactly as is - you can assign individual trains routes exactly like you can now.
2) You can "save" a schedule to a universal list of named schedules.
3) You can assign a train to a named schedule. There is a check box (normally checked) that says "syncronize train settings if named schedule changes".
a. If unchecked, the train copies the settings from the named schedule, but doesn't "remember" that it belongs to that schedule.
b. If checked, the train is permanently linked to the named schedule. If the schedule changes, the train's settings change as well.
c. If you modify the train's schedule, it is no longer linked to the named schedule. However, you can modify the train's schedule and then save over the named schedule, in which case the link is maintained.
b. Named schedules can be copied and edited directly from their list.

This sounds great. I've spent a long time going through individual trains from the train gui, changing one at a time, and it takes a while when there are hundreds of trains. If the scrolling menu stayed put and in view when a train was selected, that'd certainly make manual changing easier, but a schedule/route option seems like the most elegant solution.

I'd vote against combinators being the final solution in vanilla. If it's a method people want to use for the enjoyment of complexity and difficulty for that very sake, then that's not vanilla territory. I'd vote for the occam's razor approach of a schedule/route selection for quick and simple management of hundreds of trains.

[rldml]

For that you would need separate circuit networks for every item you deliver. And wireless connections to a logistics network would be problematic. Before LTN I had 50+ stations needing fuel. That would mean getting 50 separate wires to the stacker from all over the map.

Would probably make more sense to design a protocol with collision detection on the wire. E.g. have each station try to send N=1 and S=<id> on the wire at random intervals. Only when N=1 the train will move. Otherwise there was a collision.

Sounds great, and collision detection works even now, if you know how to build the circuit logic

I'd vote against combinators being the final solution in vanilla. If it's a method people want to use for the enjoyment of complexity and difficulty for that very sake, then that's not vanilla territory. I'd vote for the occam's razor approach of a schedule/route selection for quick and simple management of hundreds of trains.

To add this functionality with the help of a mod, you need an update off the mod-api. Actually train stops don't have an unique identifier, also there is no way to define a dynamic schedule entry (target based on signal). Additionally, you can add the circuit part to vanilla without bothering other solutions. If you have to update the mod-api, you can integrate this part as an option to vanilla also...

Last, but not least - i believe you can build the functionality to assign trains to a schedule already as a mod with the existing mod-api. There exist some addons, which do similar things:

https://mods.factorio.com/mods/aaargha/ ... Deployment
https://mods.factorio.com/mods/Choumiko/SmartTrains

[FalcoGer]

+ 1 for OP.
- Having schedules saved separate from trains allows to easy add and remove trains from a line.
- If your train blows up or you disassemble it for some reason, you can just swiftly reassign it to the same schedule.
- It makes reusing trains and adapting the network easier.
- Complicated (or simple) setups with many conditions don't need to be manually entered or copied (which is only possible after finding the train that has it already) each time.
- Plus making a change to the schedule doesn't mean that you have to redo the schedule for each and every train on the line.
- If you have a naming convention you could possibly even carry the schedules over from a different save, popping up as the stations with the relevant names appear on the map.
- No drawbacks, the effort that is put into managing the schedules is removed from managing the schedules on a per train basis. It might get somewhat cluttered if you have schedules that you certainly don't want to change and/or only need a single train on it.
-> This can be mitigated by including a 'Hide' button that hides the schedule in the list, along with a 'show hidden' button to unhide them.
- As a bonus, this could include some statistics as to how the route is doing. are trains driving around mostly empty? are they mostly just sitting on red signals/in stations without doing anything? are they only loaded with 1 item per minute? Are they sitting at the target station, unable to be unloaded? this could determine if the route needs more or less trains or indicate trouble with the network.

In short:
It's a very sound idea to separate the two.

[factoriouzr]

Can we have proper train schedules that are managed in a dedicated GUI and then assigned to trains.

A schedule would contain all the stops and conditions for each stop.

Then when a schedule is changed, all trains on that schedule would automatically update with all the changes.

[Koub]

[Koub] Merged into older topic with same suggestion

[Tekky]

The game OpenTTD implements this suggestion by allowing trains to use shared orders. However, if this is implemented in Factorio, I think OpenTTD's implementation should not be taken over. Rather, I think it would be better to keep the schedules and individual trains strictly separate.