Re: Assign Trains to Schedules
Posted: Thu Nov 23, 2017 6:40 pm
There isn't. And I've wanted it since I started using them.Zavian wrote:Before this topic came up, I wasn't even aware that you could rename trains.
www.factorio.com
https://forums.factorio.com/
There isn't. And I've wanted it since I started using them.Zavian wrote:Before this topic came up, I wasn't even aware that you could rename trains.
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 wrote:Did anyone tell you that you can name 2 stations the same so trains would pick a station?
So this needs to be in a tutorial. But after you saw it once it became second nature, right?5thHorseman wrote: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 wrote:Did anyone tell you that you can name 2 stations the same so trains would pick a station?
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.mrvn wrote:So this needs to be in a tutorial. But after you saw it once it became second nature, right?5thHorseman wrote: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 wrote:Did anyone tell you that you can name 2 stations the same so trains would pick a station?
Pretty sure the devs are working on something of this nature: https://www.factorio.com/blog/post/fff-212Yokmp wrote: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).
No, that was about a new UI for the existing train schedule.Longbolt wrote:Pretty sure the devs are working on something of this nature: https://www.factorio.com/blog/post/fff-212Yokmp wrote: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).
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.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").
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 wrote:Another solition would be something like this:
viewtopic.php?f=6&t=53792&p=315599#p315599
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.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 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.
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...mrvn wrote: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.
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.mrvn wrote:Very hard to implement
Like everything else what's using circuit logic?and understand for the user though.
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...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.
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 wrote: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.mrvn wrote:Very hard to implement
Ah ok, now i got your point.mrvn wrote:I mend for the user to implement. Lets see, this coal needs to go to the steel smelter. Was that ID 4532 or 4523?
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.rldml wrote:Ah ok, now i got your point.mrvn wrote:I mend for the user to implement. Lets see, this coal needs to go to the steel smelter. Was that ID 4532 or 4523?
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.
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.Selvek wrote: 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.
Sounds great, and collision detection works even now, if you know how to build the circuit logicmrvn wrote: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.
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...Jon8RFC wrote: 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.