Trains: Chain signals should factor in the length of the train

[macdjord]

Given all the improvements to trains in 2.0 - including, if I understood some of the FFF blog post correctly, some major internal cleanups to make the system more amenable to future upgrades - it seems like a good time to revisit this idea.

To summarize things so far and address some of the predictable responses:

• The suggestion, in its current iteration, is as follows:
  • Currently, when a train is approaching a chain signal, it attempts to reserve not only the block behind the chain signal but the next block on its path after that - and if that signal is also a chain signal, it tries to reserve a 3rd block as well, and so on until it finds a block with an ordinary rail signal and reserves that. If it can't reserve all the blocks it needs, it doesn't reserve any of them and waits at the first chain signal until it can.
  • This behaviour would be changed as follows: when the train reserves the first non-chain block, it checks the length of that block and compares it to the length of the train. If the block is not long enough to accomodate the whole train, then it must reserve the next block after that as well, and so on until the combined length of the reserved non-chain blocks is enough to accomodate the entire train. Again, if it fails to reserve every block it needs, it stops and waits at the first chain signal.
  • If, while reserving additional blocks to accommodate the train, another chain signal is encountered, the train must reserve all the chain blocks as usual - and then reserve enough space on the other side, starting from scratch
  • If, while reserving blocks, the train reaches the the train stop it is heading to, it reserves the blocks and proceeds, ignoring the length check
• The biggest unanswered question of the proposal is how the chain signal should indicate when it is blocked because of a lack of room on the other side
• This suggestion isn't about 'eliminating gameplay' or 'enabling bad track design'. It's about taking something tedious and manual - checking every possible exit from a chain block to ensure the next block is large enough for every possible train - and making it automated. Isn't that what Factorio is all about? 2.0 is already giving us the ability to skip assigning specific trains to specific cargo routes; why should we still be worried about measuring block lengths by hand?

[Illiander42]

This would create an optimal design of "fit as many non-chain-signals into your straights as possible."

[macdjord]

This would create an optimal design of "fit as many non-chain-signals into your straights as possible."

That is already optimal everywhere except the block immediately after a chain signal.

[computeraddict]

[*]The biggest unanswered question of the proposal is how the chain signal should indicate when it is blocked because of a lack of room on the other side
[*]This suggestion isn't about 'eliminating gameplay' or 'enabling bad track design'. It's about taking something tedious and manual - checking every possible exit from a chain block to ensure the next block is large enough for every possible train - and making it automated. Isn't that what Factorio is all about? 2.0 is already giving us the ability to skip assigning specific trains to specific cargo routes; why should we still be worried about measuring block lengths by hand?
[/list]

Block length is only a meaningful measure for trivial blocks that have a single entrance and exit that take a single path between them. What about blocks that have branches and convergences? What about blocks with inaccessible track that cuts across the direction you're interested in? What about a block with several paths between each entrance and exit? What about dead end blocks with stations in them?

I'm agreeing with the team here that it's a lot of work for almost no gain. Especially now that we're slated to get elevated rails in 2.0 which can obviate most of the issues involved with intersections.

[macdjord]

[*]The biggest unanswered question of the proposal is how the chain signal should indicate when it is blocked because of a lack of room on the other side
[*]This suggestion isn't about 'eliminating gameplay' or 'enabling bad track design'. It's about taking something tedious and manual - checking every possible exit from a chain block to ensure the next block is large enough for every possible train - and making it automated. Isn't that what Factorio is all about? 2.0 is already giving us the ability to skip assigning specific trains to specific cargo routes; why should we still be worried about measuring block lengths by hand?
[/list]

Block length is only a meaningful measure for trivial blocks that have a single entrance and exit that take a single path between them. What about blocks that have branches and convergences? What about blocks with inaccessible track that cuts across the direction you're interested in? What about a block with several paths between each entrance and exit? What about dead end blocks with stations in them?

I'm agreeing with the team here that it's a lot of work for almost no gain. Especially now that we're slated to get elevated rails in 2.0 which can obviate most of the issues involved with intersections.

Yes, there can be many different paths through a block, all with different lengths, but the only one that matters is the one the train is actually taking.

[FuryoftheStars]

The one thing about this idea that I'm unsure on, if you have a long train trying to pass through multiple busy intersections of smaller trains that don't have enough room between them for the larger one, you could end up with the larger train being deadlocked unable to proceed. In contrast, with signals as they are now, it only needs to wait for a break in the immediate intersection instead of multiple simultaneously.

[macdjord]

The one thing about this idea that I'm unsure on, if you have a long train trying to pass through multiple busy intersections of smaller trains that don't have enough room between them for the larger one, you could end up with the larger train being deadlocked unable to proceed. In contrast, with signals as they are now, it only needs to wait for a break in the immediate intersection instead of multiple simultaneously.

Having a single train be unable to proceed because there's never enough room for it isn't deadlock; it's an overloaded system, and the only possible remedy is to build more capacity. And having a single long train that never proceeds is better than the current system, where said long train is likely to try to proceed, get stopped somewhere such that it blocks an intersection, and then create a real deadlock situation where it cannot proceed because it is waiting for another tain to move and that other train is waiting on it to move.

[mmmPI]

And having a single long train that never proceeds is better than the current system, where said long train is likely to try to proceed, get stopped somewhere such that it blocks an intersection, and then create a real deadlock situation where it cannot proceed because it is waiting for another tain to move and that other train is waiting on it to move.

If you properly signal the current system for it to be SAFE, you do not risk having a train "trying to proceed and getting stopped somewhere blocking an intersection". That's the whole point of making the block after the junction the size of the train, so that it can never stop somewhere and block a junction. "safe exit block".

If you do not use "safe exit block", then the current system is not fool-proof, but the current system allow train to follow each other closely in a junction if you signal for it, whereas with the proposition it will no longer be possible and all train will have an increased distance between them, for the sake of making it fool-proof. It removes player's ability to make more efficient system i think.

[macdjord]

If you do not use "safe exit block", then the current system is not fool-proof, but the current system allow train to follow each other closely in a junction if you signal for it, whereas with the proposition it will no longer be possible and all train will have an increased distance between them, for the sake of making it fool-proof. It removes player's ability to make more efficient system i think.

Fair enough. On the other hand, with the current system, the only way to make a 'safe exit block' is to make it long enough for the longest train you will ever run through the system. That means that in the scenario you proposed, where the long train has to reserve multiple intersections in order to proceed, you'd have to put chain signals between those intersections, meaning now every train that want to take that path needs to reserve every intersection before it enters the first one, even if the train in question is short enough it could safely stop between the intersections.

[FuryoftheStars]

And having a single long train that never proceeds is better than the current system, where said long train is likely to try to proceed, get stopped somewhere such that it blocks an intersection, and then create a real deadlock situation where it cannot proceed because it is waiting for another tain to move and that other train is waiting on it to move.

Hmm, to me I consider that to be just as bad, tbh. The better solution, to me, I suppose, would be to never let that larger train run through the smaller train network / intersections in the first place. Run a separate line that's strictly for the larger train. Or have a separate station where the larger train can offload its cargo to smaller ones. That's where my mind goes, anyway.

[mmmPI]

Fair enough. On the other hand, with the current system, the only way to make a 'safe exit block' is to make it long enough for the longest train you will ever run through the system.

Yes, but i do not always use "safe exit blocks"

That means that in the scenario you proposed, where the long train has to reserve multiple intersections in order to proceed, you'd have to put chain signals between those intersections, meaning now every train that want to take that path needs to reserve every intersection before it enters the first one, even if the train in question is short enough it could safely stop between the intersections.

That's a scenario i'd avoid when playing, i suppose the scale of the map and the density of trains plays a role there.

I was considering more 2 scenaris (2&3 since yours is 1 ),

2) At the exit of a multi-unload area, many trains comes from different entrance of a single "block" and all leave thru the same "exit", which is guarded by a regular signal. It is sometimes desirable to have a chain signal there just before , but not whole safe exit block afterward.

3) Some junctions far away from each other on a train world, with long straight strech of rail in between them enough to fit 10 trains. I do not use safe exit block there, if my network is a tree and not a grid there is no risk of deadlock, and if it was a grid it would require like 40 trains at least all at the same time around the same "block" for a "safe exit block" to be required.

The case you mention would be 2 junctions separated by enough room for 0 1 2 3 trains, depending on which particular train the LCCCCCCCCC or the LC is attempting to go thru the 2 junctions in a row, this is going to be "sub-optimal" in both case imo, with the current system, because you either signal safe and the LC is behaving like the LCCCCCCCCCC and they both reserve both junctions, or you don't signal safe and you risk deadlock with "few" trains ( 1 big). But with the proposal, it will lead to LCCCCCCC train ALWAYS reserving both junctions. Even when it is not stricly necessary. Although in such case it is for safety, in other case i think the throughput will be (forcibly) reduced compared to what it is now (without safe exit).

[macdjord]

But with the proposal, it will lead to LCCCCCCC train ALWAYS reserving both junctions. Even when it is not stricly necessary. Although in such case it is for safety, in other case i think the throughput will be (forcibly) reduced compared to what it is now (without safe exit).

Er, no, it'll only reserve both junctions if it actually needs them.

[Murklak]

I'd like to see a dynamic signal that can do two things:
1. Act as a rail signal to trains at or below a set length, and as a rail chain signal otherwise.
2. Block trains at or above a set length from entering.

[mmmPI]

But with the proposal, it will lead to LCCCCCCC train ALWAYS reserving both junctions. Even when it is not stricly necessary. Although in such case it is for safety, in other case i think the throughput will be (forcibly) reduced compared to what it is now (without safe exit).

Er, no, it'll only reserve both junctions if it actually needs them.

No you misunderstood me otherwise there would be no difference with current system.

I meant that all the time the train will want to reserve some exit blocks even if they are not needed. And the second train is only allowed to go when the exit block of the previous is cleared, which is not necessary, as in many case you are fine with 2 train following each other separated by a distance between them that is LESS than a full train.

The proposition will prevent the most efficient solution to be used in favor of sub-optimal reservations to me.

[computeraddict]

Yes, there can be many different paths through a block, all with different lengths, but the only one that matters is the one the train is actually taking.

My point was that even just finding that value is not trivial.

Add to the complications now that you could wind up with a train insisting on paths it can't reserve due to length blockages while it ignores longer paths that it could at least get closer to its destination by reserving.

Just too many challenges to solve for very little payoff. If you're going to build code to measure the branches in a block I'd rather it just be presented to the player during previewing signal placement, as that solves the problem of "it's tedious to measure blocks" without any breaking changes to train logic.

[macdjord]

My point was that even just finding that value is not trivial.

That code already exists. It's part of the train pathing algorithm.