Better train control

[bobucles]

Children, behave. Bad ideas don't make bad people. Bad responses do.

[Deadlock989]

So I expanded my base this afternoon. Removed Deadlock's Crating Machine, burned a million crates, added Deadlock's Stacking Beltboxes to give them a proper kilobase field run. Effect of that on trains and scheduling: bugger all.

Added five new outposts (three copper, two oil), making that 21 outposts supplying 38 smelter blocks, 10 oil refinery blocks, 5 plastic factories and a uranium processor, 54 trains on the network.

Upgraded circuit production, tripled the rockets, blah blah blah blah blah. Can now fire 0.63 RPM. Bumped myself up to Mining Productivity 50 and Robot Speed 10 as well, just for the giggles. I jest: it's actually like watching paint dry.

Number of train schedules changed: zero.
Number of outpost blueprints adjusted: zero.
Number of manual interventions to fix dodgy trains: zero.
I literally just plonked outposts down and the combinator logic kept everything working.




It's become trivial. Can I expand indefinitely like this, is it a perfect system? Of course not. Why? Because I haven't learned everything there is to learn yet. I hadn't planned well enough. I don't have a good place to put down more steelworks and that's holding back research now. Also, track throughput is becoming more of a problem, a bottleneck is just starting to form when everything is running at full pelt because there's only two exits from the base and it's just a single ring of track. That's all my fault, i.e. my responsibility to fix, not Wube's. I learned something, even on my 200th game.

But it doesn't really matter, because to be frank, the game is long over and it's just copy-pasting now. I've launched 148 rockets. By the vanilla game's definition I won the frigging game 148 times already in this play session alone. Yes, trains are clearly broken and impossible to use.

... Or just maybe, we could credit the creators with an iota of common sense and realise that all the tools needed are already in place: signals, train stops, and circuit networks. Does a station not have enough ore to fill a train? Turn it off. Does a station have X trains waiting (count the red signals in the stacker bays) and you only want a maximum of Y to wait and divert any others to the another active outpost? Turn the station off, no departing trains from your depots target it any more, trains leave one by one until X <= Y, station comes back on, the rest of the trains don't leave. It's so easy I am haemorrhaging neurons just typing this out.

How wouid this magical train stop limit work, anyway? You wave your pixie wand and say, this train stop can now only summon 3 trains. Because that's how trains work: they are in frickin' telepathic communion with remote stations and with each other. Or maybe they've got onboard computers and really, really good wifi. Or perhaps there are track-side elves with semaphore flags. I mean, I don't really care if Factorio is realistic or not, but I draw the line at bleedin' Harry Potter. So you send the magic train controller a signal. What signal? A picture of a little locomotive with a value of 3? Fine, but how do the trains know? Which 3 trains "respond"? How do they choose? Roll a dice? Thumb-wrestle? Vote on it? More to the point, how does the station know that 3 and exactly 3 trains are coming, and which other trains to "tell" not to come? Gimme strength. That kind of dross is fine for mods, but will people stop trying to dumb my favourite game down, please?

It took me two and a half hours to get to work on Tuesday, on a journey that should have been 27 minutes. Guess why? One train broke down. I guess what should have happened is that all the other trains sent each other Owl Post or flew over the obstacle on a magic carpet.

[rldml]

Hey guy, there is no need to be rude. I'm just a human after all...

Not as rude as people who answer before they read. This behavior leads to pointless flood and flame. Like it happening here.
This is why this behavior must be terminated ASAP.

We can play this game, but there will be no winner. The only effect you gain with this behavior is that you look angry about others and stop talking about the interesting stuff. Please come back to the topic. Thx.

I've read your suggestion, but you want far more than i want for the base game. I strongly believe, that we only need a way to send schedules via circuit networks to trains, because everything else you want to have can already be done with the help of curcuit network logic.

I am tired to repeat this:
It is true. In theory.
But it ridiculously hard.
It like writing programs for Turing machine. In theory it can do everything but in practice it very hard to make it to do anything useful.

Please don't forget, that we are talking about very advanced ways to give the trains the last missing 10% of effectiness they are lacking right now (in vanilla).

There is no reason to make it that simple like you suggested.

I just wanted to say "thank you", because everyone else in this forum seems only to advise for LTN, which i don't want for some reason (it does simply to much, i want to regulate that stuff by myself with curcuit network).

Every single one of my suggestions is completely optional and do not affect base game if you don't use them.
Moreover they allow gradual and easy progression from basic schedule to much more sophisticated train control than LTN.

[/quote]

With the one exception (that i mentioned earlier) they are only quality-of-life-features you don't need to realize what you want to do.

Does a station have X trains waiting (count the red signals in the stacker bays) and you only want a maximum of Y to wait and divert any others to the another active outpost? Turn the station off, no departing trains from your depots target it any more, trains leave one by one until X <= Y, station comes back on, the rest of the trains don't leave.

I don't know your station design, but in the moment i turn off a train stop, all waiting trains in the stacker bay would recalculate its path and drive to other train stops or just target the next train stop in its schedule, but without the load they should get in the turned down train stop.

The only way to stop this behavior would be to make a train signal red and just turn it to green the train stop is active again. But even then i don't believe, that all trains recalculate again and respect the new turned on train stop instead of ignore it.

Vanilla has a lack of available ways to make the trains drive only to the stations where they really needed instead of "oh there is the next train stop with this name..."

[Deadlock989]

Does a station have X trains waiting (count the red signals in the stacker bays) and you only want a maximum of Y to wait and divert any others to the another active outpost? Turn the station off, no departing trains from your depots target it any more, trains leave one by one until X <= Y, station comes back on, the rest of the trains don't leave.

I don't know your station design, but in the moment i turn off a train stop, all waiting trains in the stacker bay would recalculate its path and drive to other train stops or just target the next train stop in its schedule, but without the load they should get in the turned down train stop.

The trains can only leave one at a time. As soon as one starts to leave, the exit block is reserved (just by the leaving train being in it, nothing special) so the others in the stack have to wait their turn to leave. So they are forced to leave one by one until the desired limit of trains is there, at which point the station turns back on and the remaining trains in the stack lock back on to it. I've been using that design all day, despite the OP's claims that it's "impossible". It's rare that more than one train has to leave, anyway - my outpost design has 8 bays in its stacker, but I don't know why I did that now, there's hardly ever even 2 trains waiting behind the one currently loading, even with 54 trains flying about. I suppose it's more useful in the early stages of your rail network where you have a very limited number of outposts, but then, you shouldn't be sending out too many trains in the first place. If you've got a ton of trains waiting at one station, there's something else wrong - it must mean you get large numbers of factory blocks all emptying their trains simultaneously and so they all send their trains to the exact same place, which sounds like some deeper kind of problem to be honest, their output should be balanced or cycled better - much easier now with priority splitters.

I'm not claiming my system is perfect, I'm sure it could be improved. In my next big playthrough I'll be adding an RS latch to encourage a bit more rotation of outposts, at the moment they tend to cycle back and forth too quickly between "just about enough stock to fill a train" and "not quite enough stock to fill a train", especially if they're producing a lot of ore, which does waste a bit of time re-routing trains. But this system got me to the point that I'm literally filling orbit with satellites so it must be doing something right. You don't ever get to perfection in Factorio. You approach it forever, with more and more effort required, like a singularity, an asymptote.

Trains are already very good at what they do. A train is not a logistics bot but people do keep trying to turn them into one. And some oeople get annoyed because their system didn't work so they blame the game, because they're never wrong. In fact it's the limitations that make trains interesting, same as belts, same as ... bots ... OK. maybe not bots.

[rldml]

Would you mind to post a demo save where i can inspect your station design?

It would help me a lot

Greetings, Ronny

[Deadlock989]

Would you mind to post a demo save where i can inspect your station design?

Yeah, I would mind, bit more exposure than I want, and you'd have a hassle getting the mod settings right.

This is a typical "depot". Nothing very special here. Ignore the cluster of combinators to the left, that's some massively over-engineered and nearly pointless thing I did to change fuel type in the requester chest across the whole base at once (I usually have a vertical fuel belt going through all the depots but just this once, allowed myself the luxury of logistics bot refuelling). One train only per depot. It stores exactly four train loads, vanilla's insistence on multiples of 16 chest slots baffles me. Load balanced so that every chest (and therefore the wagons) are emptied equally, I didn't invent that, plenty of tutorials on it on YouTube and here on the forums. The station is toggled off when a train is unloading, to stop other trains trying to queue at it. One depot = one blue belt (it looks like two in the picture but that's because I'm a symmetry freak). For ore, that means that a train needs to complete its fetch within 2.2 minutes to keep up with maximum demand. That doesn't always happen, especially for the depots furthest from the rail-bus during busy periods, which is why there's so much redundancy and balancing on the bus - the bus shifts balance to try and empty out the most easily restocked depots first.



This is an outpost, this one is almost tapped out. The signals with the outline are the ones you count to know how many trains in are in the stack. The station is toggled off if either (a) there are more trains than desired in the stack or (b) not all of the four chest groups have at least one wagon's worth of ore inside. This is the bit I want to add an RS latch to, so that the station deactivates when there's less than a train load, and doesn't reactivate until there's, say, three train loads.



Likesay, I'm sure there are better set-ups. In fact I've seen things on Youtube and on the forums that are definitely better for megabase-scale stuff. But you don't need sentient, telepathic train stops because you can already achieve exactly the same effect, and adding "off the shelf demand balancing" stations would just diminish the challenge for the rest of us.

[rampelstinskin]

We can play this game, but there will be no winner. The only effect you gain with this behavior is that you look angry about others and stop talking about the interesting stuff. Please come back to the topic. Thx.

It is very hard to talk when you answering to what I never said.

With the one exception (that i mentioned earlier) they are only quality-of-life-features you don't need to realize what you want to do.

Problem with your solution is: less than 1% of players have skill to use it. And less than 1% of this players will find it fun enough to actually build this system.

My job is creating new algorithms.
When you do it main questions is "what if" and "how much". Both of them must be answered for every possible event. Including highly unlikely events.
And I did exactly this for this problem before I submit my suggestions.

If you use only ability to send train to specific station all variants of this system end up very fragile, not scalable or poorly scalable and require a lot of work to setup an maintain.

For example one of problems you need to solve is limit how many trains sent to train station.
Only thing you can do is add counter to train station. But what will happen if train destroyed? If counter destroyed? This means you need ability to ask game how many trains is actually going to train station. Without it will be extremely hard to maintain.

What happen if train station destroyed? How train will know where to go? You need some kind of train side logic to solve this problem.

Next problem you need to solve is get information from train stations.
Using circuit network you can talk to fixed number of stations at same time.
And only scalable way to do it is send train station id to CN and train station will communicate only if this signal match it id.

Now you need a way to enumerate stations. Only way to do it is manually maintain list of stations. Good luck with this.
Or we need a way to ask game for this information.

Now you need enumerate all providers. Then for each provider which is ready to send train enumerate all consumers for this resource. This is quadratic algorithm which is very bad for scalability.
And on top of this to select best station you need a way to calculate distance between train stations.

Long story short, you need a lot more features to do train routing with combinators.

[Deadlock989]

Just added the RS latches so that outposts deactivate when they have less than 4 wagons' worth of stock, and don't reactivate until they have 16.

Advantages: much more cycling of outposts, the furthest outposts are now seeing much more traffic, which is good because they tend to have the most resources and highest throughput anyway (far = more). Trains are much less often re-routed while on the way to an outpost.

Disadvantages: encourages a bit more bunching of trains, more trains are going to the same outpost simultaneously, but I decreased the number of waiting trains allowed to 3 so they're just bumped to the next nearest anyway. This is inefficient if you have a small number of outposts spread far and wide, but if you have enough active outposts and have them in clusters, it doesn't really affect throughput, and this minor waste of time is offset by not having trains re-routing mid-journey anywhere near as much.

[Deadlock989]

40 minutes of an "impossible" base, timelapse at about 12x speed, doing Mining Productivity 59 to 62, with outpost cycling and a waiting limit of 3 trains per outpost. Research tanks during the last phase because of a deficiency in red circuit production, unrelated to train supply.

https://youtu.be/HUturTKuqHU

Similar story, 9x speed of ~40 rockets being launched, higher resolution/framerate and with a higher contrast background so you can follow the "impossible" trains a bit more easily.

https://youtu.be/__S-qmcQK-U

[rldml]

We can play this game, but there will be no winner. The only effect you gain with this behavior is that you look angry about others and stop talking about the interesting stuff. Please come back to the topic. Thx.

It is very hard to talk when you answering to what I never said.

Please, come back to topic now.

With the one exception (that i mentioned earlier) they are only quality-of-life-features you don't need to realize what you want to do.

Problem with your solution is: less than 1% of players have skill to use it. And less than 1% of this players will find it fun enough to actually build this system.

We talk about something you don't need to win the game (send a rocket into space) and start to be relevant only in larger scale games like building megabases. We talk about the last few percent to make a optimal transportation network.

Something like this should be complicated and shoud need a lot of skill to realize it.

My job is creating new algorithms.
When you do it main questions is "what if" and "how much". Both of them must be answered for every possible event. Including highly unlikely events.
And I did exactly this for this problem before I submit my suggestions.

You want more than that, you don't only want some information stuff, you want a way to configurate your trains to respect the information autmatically, without any more implementation of circuit networks.

If you use only ability to send train to specific station all variants of this system end up very fragile, not scalable or poorly scalable and require a lot of work to setup an maintain.

You're simply wrong.

For example one of problems you need to solve is limit how many trains sent to train station.
Only thing you can do is add counter to train station. But what will happen if train destroyed? If counter destroyed? This means you need ability to ask game how many trains is actually going to train station. Without it will be extremely hard to maintain.

I strongly believe this is the wrong view to your problem. In an optimal system you would exactly send one train to your train stop for every request it makes. You try to control how much trains drive to that train stop in a tangentially way instead of making the correct solution.

And to say it clearly, It's one of your tasks to prevent your station from being destroyed. You can build your structures to capture this incidents, but initially they should'nt happen.

What happen if train station destroyed? How train will know where to go? You need some kind of train side logic to solve this problem.

There is already a train side logic implemented for this scenario. Everyone can try it. Just make a train with a schedule and then remove one of the train stops of the schedule.

Next problem you need to solve is get information from train stations.
Using circuit network you can talk to fixed number of stations at same time.
And only scalable way to do it is send train station id to CN and train station will communicate only if this signal match it id.

Now you need a way to enumerate stations. Only way to do it is manually maintain list of stations. Good luck with this.
Or we need a way to ask game for this information.

Now you need enumerate all providers. Then for each provider which is ready to send train enumerate all consumers for this resource. This is quadratic algorithm which is very bad for scalability.
And on top of this to select best station you need a way to calculate distance between train stations.

Long story short, you need a lot more features to do train routing with combinators.

My position hasn't changed - you only need a way to send schedules over your CN. Everything else you can realize already with the help of CN.

Greetings Ronny

[rampelstinskin]

We talk about something you don't need to win the game (send a rocket into space) and start to be relevant only in larger scale games like building megabases. We talk about the last few percent to make a optimal transportation network.

Something like this should be complicated and shoud need a lot of skill to realize it.

My proposal allows hard way. You can ignore ability to limit train stop like I ignore logistic bots.
But for vast majority of player without this feature making this this system will be impossible. And they will mindlessly copy/paste blueprints. It not what I call fun.

My job is creating new algorithms.
When you do it main questions is "what if" and "how much". Both of them must be answered for every possible event. Including highly unlikely events.
And I did exactly this for this problem before I submit my suggestions.

You want more than that, you don't only want some information stuff, you want a way to configurate your trains to respect the information autmatically, without any more implementation of circuit networks.

Oh... talking with you is hard. How my quote connected to yours I can't understand.

You're simply wrong.

Very good argument. I completely defeated.

I strongly believe this is the wrong view to your problem. In an optimal system you would exactly send one train to your train stop for every request it makes. You try to control how much trains drive to that train stop in a tangentially way instead of making the correct solution.

Oh.
Limit how many trains can go to station.
Send exactly one train to your train stop for every request it makes.

It exactly same task. If you start thinking how exactly you will do it it will become obvious.

Do you understand it now? Or more explanations needed?

And to say it clearly, It's one of your tasks to prevent your station from being destroyed. You can build your structures to capture this incidents, but initially they should'nt happen.

Shit happens.
And I think about every shit that can possible happen.

[rldml]

We talk about something you don't need to win the game (send a rocket into space) and start to be relevant only in larger scale games like building megabases. We talk about the last few percent to make a optimal transportation network.

Something like this should be complicated and shoud need a lot of skill to realize it.

My proposal allows hard way. You can ignore ability to limit train stop like I ignore logistic bots.
But for vast majority of player without this feature making this this system will be impossible. And they will mindlessly copy/paste blueprints. It not what I call fun.

Copying Blueprints is something the game designers supports and many people do right now (e.g. balancers). I cannot see your problem here, because it is an accepted way to surpass complex problems in the game and you could easily ignore it, if you don't want it.

You want more than that, you don't only want some information stuff, you want a way to configurate your trains to respect the information autmatically, without any more implementation of circuit networks.

Oh... talking with you is hard. [...]

Dito. Can we just come back to topic?

You're simply wrong.

Very good argument. I completely defeated.

Yeah, we have different point of views to this thematic. Deadlock989 posted some shreenshots and talks about his base. Your suggestions are simply not needed to make a big scaled base. There exist a tons of savegames with mega- and gigabases they shoudn't exist in your reality. I just don't have the motivation to show in detail, that you're simply wrong.

I strongly believe this is the wrong view to your problem. In an optimal system you would exactly send one train to your train stop for every request it makes. You try to control how much trains drive to that train stop in a tangentially way instead of making the correct solution.

Oh.
Limit how many trains can go to station.
Send exactly one train to your train stop for every request it makes.

It exactly same task. If you start thinking how exactly you will do it it will become obvious.

Do you understand it now? Or more explanations needed?

I wrote it earlier, please try to understand: If you want to drink a glass of milk, you'll just fill some milk into a drinking glass and drink it. You'll surely not empty a complete bottle of milk above your head until you drank enough and you won't especially expect the bottle of milk to stop dumping its content by itself just because you finished!

Your suggestion isn't the same as mine. You want that a train looks by itself, i want a way to give a train specific schedule depending of circuit network conditions - which is obviously already possible with the help of a mod you thankfully mentioned.

And to say it clearly, It's one of your tasks to prevent your station from being destroyed. You can build your structures to capture this incidents, but initially they should'nt happen.

Shit happens.
And I think about every shit that can possible happen.

Yeah, building a roboport, fill with construction bots and have some yellow boxes with replacing stuff is that hard, nobody can do this, so we need extra intelligent trains that can handle every possible situation.

*sigh*

[rampelstinskin]

Copying Blueprints is something the game designers supports and many people do right now (e.g. balancers). I cannot see your problem here, because it is an accepted way to surpass complex problems in the game and you could easily ignore it, if you don't want it.

And you can ignore one checkbox in train stop options.

Dito. Can we just come back to topic?

Not until you stop talking with you imagination and start talking with me.

Yeah, we have different point of views to this thematic. Deadlock989 posted some shreenshots and talks about his base. Your suggestions are simply not needed to make a big scaled base. There exist a tons of savegames with mega- and gigabases they shoudn't exist in your reality. I just don't have the motivation to show in detail, that you're simply wrong.

The problem is both of you twist my words. You have some twisted image of what I saying and you arguing with it. Not with what I actually saying.
I never said big bases is impossible.
I said there is no good solution.
In case of Deadlock989 trains randomly going to stations where they not needed. It good way to create congestion if you start scale base. Worst case scenario if he have less mining outpost than he needs.
Outposts will be overloaded with trains and because of this empty trains will go to smelters and create congestion.

Your suggestion isn't the same as mine. You want that a train looks by itself, i want a way to give a train specific schedule depending of circuit network conditions - which is obviously already possible with the help of a mod you thankfully mentioned.

But you don't understand what I talking about.
I talk about YOUR solution.
This is you quote:

n an optimal system you would exactly send one train to your train stop for every request it makes.

In your solution you need to find a way to send exact number of trains to a station.
Now tell me how exactly you planing to do it.

You will not understand what I talking about until you do.

Yeah, building a roboport, fill with construction bots and have some yellow boxes with replacing stuff is that hard, nobody can do this, so we need extra intelligent trains that can handle every possible situation.

They will not restore value in train counting combinator.
How you going to fix it state?

*sigh*

This my line.

[rldml]

Copying Blueprints is something the game designers supports and many people do right now (e.g. balancers). I cannot see your problem here, because it is an accepted way to surpass complex problems in the game and you could easily ignore it, if you don't want it.

And you can ignore one checkbox in train stop options.

I could ignore using bots to, but why should i? It makes a huge difference in gameplay, if you try to ignore an implemented feature or if you have to visit an external website to get help for something you could build for your own.

Most of the stuff you suggested is simply not needed.

Yeah, we have different point of views to this thematic. Deadlock989 posted some shreenshots and talks about his base. Your suggestions are simply not needed to make a big scaled base. There exist a tons of savegames with mega- and gigabases they shoudn't exist in your reality. I just don't have the motivation to show in detail, that you're simply wrong.

The problem is both of you twist my words. You have some twisted image of what I saying and you arguing with it. Not with what I actually saying.
I never said big bases is impossible.
I said there is no good solution.
In case of Deadlock989 trains randomly going to stations where they not needed. It good way to create congestion if you start scale base. Worst case scenario if he have less mining outpost than he needs.
Outposts will be overloaded with trains and because of this empty trains will go to smelters and create congestion.

It is a fact that many people build giant bases (inclusive train as a part of the system) and have no scaling problems. Stop whining about something that isn't real.

Your suggestion isn't the same as mine. You want that a train looks by itself, i want a way to give a train specific schedule depending of circuit network conditions - which is obviously already possible with the help of a mod you thankfully mentioned.

But you don't understand what I talking about.
I talk about YOUR solution.
This is you quote:

n an optimal system you would exactly send one train to your train stop for every request it makes.

In your solution you need to find a way to send exact number of trains to a station.
Now tell me how exactly you planing to do it.

I told you before: You just need the option to reschedule your trains via CN: In my savegame i've made a dynamic train stacker: Outposts send a request signal and the stacker sends (exactly) one train. That works since 0.15 vanilla withoud any mods and don't need further improvements.

Our problem is, that we can't send the train to exactly that one station over there. Instead the train drives to the nearest station with the same name.

If we can give a train a new schedule via CN, we simply give every outpost a unique name (like "coal 1" or "iron smelter 2") and build a CN, that tells the train to which of the train stops it has to drive next.

The only problem left (and that's a verly little one), you have to find a way to define your schedules and send them to the trains in the stacker. One solution is to define the schedule directly at the outpost and send it to the dynamic stacker in some way. Another solution could be to define them at the stacker (Therefore you have to go to your stacker everytime you make a new outpost). At least, this is a personal design statement - some people will prefer the first solution, other the second. Other people will finde different ways to do the same.

You can even make a mixed solution. E.g. you have three coal outposts on your map, two in the east and one in the west. You could give the same name to the two outposts in the east and make only one schedule for both. To assure, the train targets the right train stop, you give the train the "east coal-schedule" and deactivate the not requesting outpost. The train will drive in the correct direction. This could make sence if your east coal outposts are small and don't request trains often.

You will not understand what I talking about until you do.

Perhaps you should accept, that we've understood very good what you want and just have another point of view as you.

Yeah, building a roboport, fill with construction bots and have some yellow boxes with replacing stuff is that hard, nobody can do this, so we need extra intelligent trains that can handle every possible situation.

They will not restore value in train counting combinator.
How you going to fix it state?

You don't need a train counting combinator, so there is nothing special to fix. And even shit is going to become real, it's your task as player to build bases secure for that. If you have some values you have to make as secure as possible, extend your base in a way you can defend them even better (more towers, mor ammunition, more walls, more everything)