Page 2 of 2

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

Posted: Thu Sep 12, 2019 5:37 pm
by mrvn
Please stay on topic. If you want something else make a new suggestion or add to the existing ones for other signal types.

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

Posted: Fri Sep 13, 2019 5:11 am
by JimBarracus
mrvn wrote:
Thu Sep 12, 2019 11:51 am
It's not about fixing design mistakes.
It is. Its not that hard to rework at least the part of the track which this larger train would usually take.
Anyway its extra bad design, when a train has to wait on the first block after a junction.
mrvn wrote:
Thu Sep 12, 2019 11:51 am
The suggestion is about having the train network just become inefficient for trains larger than it was build for rather than grid lock. You don't want to have to rebuild your whole factory because later in the game you need longer trains for only some goods like ores or plates. It's about keeping the train network expandable.
I think thats what the game is about. You can scale your design to a certain size but then it becomes inefficient.
Maybe it would be a better idea to use two trains in the first place.

Adding no-brainer elements doesnt make the game better. It just benefits lazyness to rework or build a suited rail system for your needs.

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

Posted: Fri Sep 13, 2019 8:18 am
by planetmaker
JimBarracus wrote:
Fri Sep 13, 2019 5:11 am
I think thats what the game is about. You can scale your design to a certain size but then it becomes inefficient.
Maybe it would be a better idea to use two trains in the first place.

Adding no-brainer elements doesnt make the game better. It just benefits lazyness to rework or build a suited rail system for your needs.
Well said!

(And I don't understand why I cannot build my (initial) rail system such that it can be expanded to fit my future needs, too - without complete deconstruction.)

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

Posted: Fri Sep 13, 2019 11:29 pm
by ssilk
Then I would say: Try to understand why it is not.

Hint: Any system - a railway, a telephone system, a webserver, whatever - can only be scaled up to a certain point. If you reach that point you need a new system.

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

Posted: Sat Sep 14, 2019 5:44 am
by planetmaker
ssilk wrote:
Fri Sep 13, 2019 11:29 pm
Then I would say: Try to understand why it is not.

Hint: Any system - a railway, a telephone system, a webserver, whatever - can only be scaled up to a certain point. If you reach that point you need a new system.
Thanks, that's exactly the point I tried to make. But I notice that I phrased my reply such that my intent is conveyed badly.

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

Posted: Sat Sep 14, 2019 6:49 am
by mrvn
ssilk wrote:
Fri Sep 13, 2019 11:29 pm
Then I would say: Try to understand why it is not.

Hint: Any system - a railway, a telephone system, a webserver, whatever - can only be scaled up to a certain point. If you reach that point you need a new system.
I know why it's not.

Point is that as is it is impossible to build a system that's efficient for both long and short trains.

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

Posted: Mon Sep 16, 2019 5:09 pm
by ssilk
mrvn wrote:
Sat Sep 14, 2019 6:49 am
I know why it's not.

Point is that as is it is impossible to build a system that's efficient for both long and short trains.
:)

I would say: It's really easy to drive a small train on a system that's made for long trains. But it's hard (and sometimes impossible) to drive many long trains on a system designed for short trains.

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

Posted: Thu Sep 19, 2019 10:38 am
by mrvn
ssilk wrote:
Mon Sep 16, 2019 5:09 pm
mrvn wrote:
Sat Sep 14, 2019 6:49 am
I know why it's not.

Point is that as is it is impossible to build a system that's efficient for both long and short trains.
:)

I would say: It's really easy to drive a small train on a system that's made for long trains. But it's hard (and sometimes impossible) to drive many long trains on a system designed for short trains.
Sure, the small train just behaves like a long train with some invisible and weightless train cars. And having a LC train behave like LLLLLLLCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC is really inefficient.

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

Posted: Thu Oct 29, 2020 1:55 am
by macdjord
I was about to make this exact same suggestion. I shouldn't be surprised someone else beat me to it; it's an obvious improvement.

Things that are not reasons to not do this:
  • "The current system is fine!"
    No it's not. The current system is janky, error-prone, and requires a lot of pointless manual checking to do something that could be handled better if it were automated. You have to manually check the usable length on every exit from every interchange; depending on how things are arranged, this may require temporarily removing other signals (and hoping you remember to put them all back). Making simple drop-in blueprints for T-junctions or interchanges in impossible. A single stray signal from another blueprint can invalidate your work. If you decide to switch to longer trains, you need to recheck your whole network.
  • "If you build it right the current system can do everything this one can."
    No it can't. In the current system, you have to build every main-line interchange to handle the largest train which might pass through, which reduces throughput for smaller trains. Also, in the current system, you have to make sure that every possible path a train might take after exiting a chain block is long enough to handle your max-length train; if some of the paths are long enough but some are not, there is no way to take advantage of that for trains going the long ways while ensuring those going other ways wait in a safe place.
  • "It makes signaling logic harder to understand."
    No it doesn't. If anything, it makes it simpler to understand. The colloquial explanation of how chain signals work is that 'a train is unable to enter a block protected by a chain signal unless it knows it will also be able to leave'; with this change that is actually true rather than having an unspoken caveat that it only really guarantees that the front of the train will make it out and the non-chain block it exits into has to have enough room for the rest of the train too or else you risk deadlock.
    Additionally, this change reduces how much of the network a player has to consider when designing interchanges and junctions. Normal blocks with plain rail signals are very easy to understand; it's only when you start getting chain signals involved that things get complicated. As it is, when designing an interchange, one needs not only to consider the interchange itself, but every exit block - and if there's another interchange nearby, one needs to consider also the interactions between the two. This change would eliminate that need, allowing any given interchange to be studied and understood in isolation.
  • "Not making your exit blocks long enough for your trains is bad rail planning! If you don't do that, the consequences are on you."
    Yes, congratulations, you have accurately summarized the current state of the game. The point of this suggestion is to improve the game by changing that. That's why it's in 'Ideas and Suggestions', not 'Bug Reports'.
Things that are problems with this idea:
  • "How would you decide what colour a chain signal should display if some of its exits have enough room for trains of a certain length and others do not?"
    Good question! There are a few options:
    • No change:
      • Pros: Very simple
      • Cons: You end up with trains waiting at a green signal because their desired exit is clear but the path beyond is not
    • Take the length of the longest train on the network; if all exits are open but some cannot support a train of that length, display blue
      • Pros: No connection required between a given signal and the trains near it
      • Cons:
        • One long train causes blue signals everywhere.
        • Potentially computationally expensive since it has to check the free length of every possible path beyond each exit.
    • When a train approaches a chain signal, if it tries to reserve a path but fails because the exit itself is free but there isn't enough room beyond it, the chain signal it is approaching turns blue if it wasn't already. (Optionally, so do any other chain signals it attempted but failed to reserve; this looks prettier but might be more complicated to implement.)
      Another option is to add a new colour besides blue which can be used to indicate this state.
      • Pros:
        • Trains never wait at a green signal
        • It's not like signal colours don't already depend on the paths and plans of approaching trains. Contrary to popular misconception, a signal doesn't turn yellow when the block behind it is reserved; it turns yellow if the train which has reserved that block is planning to pass through that particular signal, while all other signals entering that block turn red.
      • Cons:
        • Seeing a chain signal showing blue when all the exits are green might be confusing to players already familiar with the old behaviour. (Using a colour besides blue would mitigate this.)
        • You'd have formerly green signals suddenly turning blue just as a train arrives, which might be frustrating to players not familiar with the mechanics. (Again, mitigated by using a new colour rather than blue.)
        • This would be somewhat more complicated to implement than the yellow signal logic. With yellow, a signal can only ever be reserved by a single approaching train at a time, whereas multiple trains might want to pass a particular rail signal but be waiting on exit space.

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

Posted: Thu Oct 29, 2020 7:24 am
by ssilk
That’s a very nice summary of this discussion.

My personal opinion is mixed. On one hand I think this failed pre-reservations feature would be useful. I would signal that with a yellow blinking signal. On the other hand: who does say, that the current system is unusable? Is very useful and it follows the idea to steadily improve your factory. Finding bottlenecks, errors etc. is a steady source of fun of this game. And I think this is one of that category. I know that many players would disagree. :) But what has been said already: you cannot mix two train lengths without having problems.

Besides that I think about the gameplay value. I think it is low, because not so many players will run into that problem, it is only so obvious if you use trains with very different length.

And I think the effort to program that is astonishing high. The modifications for the route-planner can not be estimated, because there are so many edge cases.

So I think the chances to be implemented are very low.

Other subject:
Also pointed out here is, that build the right block length is sometimes difficult. That is a different suggestion, already made here and I fully support it.

What I currently ask me: is it possible to built some circuits to do that kind of forward check? Aka put outgoing signal to red, when train is a long train and more blocks behind that signals are still occupied.
For me this sounds like a simple logic, and so it can be rebuilt by circuits.

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

Posted: Thu Oct 29, 2020 7:31 am
by Laramy65
JimBarracus wrote:
Thu Sep 12, 2019 10:41 am
mrvn wrote:
Mon Sep 09, 2019 12:06 pm
Chain signals should let a train pass when it can clear the next full signal instead of when it can cross the next full signal.
simple rule: the largest train has to fit in every block

everything else is just bad track design
i take great issue with your statement. there are many decisions to make building traintrack, as the player has lot of control on where the train goes. your rule is decent approach, if you want to be safe about it, but why do that. it's the simplest way to ensure trains dont jam (although not always effective - consider gridlocks), but why build simple. there are more complicated(fun) ways to do the same. but worry not it is already decided

you and OP seem to be motivated by absolutely the same. to remove gameplay from game. calling things bad track design just seems like blaming player for engaging in gameplay.

OPs idea isn't flawed because he plays the game wrong. it is flawed because it removes what is to be played. thuus it is the wrong approach to suggest that it is what ought to be done.

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

Posted: Thu Oct 29, 2020 7:57 am
by boskid
I was thinking about this idea independently (not knowing about this topic) so it already gives this idea a little higher chances.

Implementation should not be too complex (famous last words). When a train is following the path it has list of all the signals on its path with their distances, so knowing what is the total train length (including some extra margin of 3 because of arrival distance of 2 and back margin of 1) train could be made to require more signals on the path to be reserved after a chain signal so after the chain signal section they would reserve as much regular rail signals as it would be required for given train length (+margin of 3).

There are unfortunately some issues:
- trains pathfinder would have to be adjusted for that because it is also responsible for chain signal escaping when repath happens while a train is within chain signal section. Because of that there would be some cpu+memory penalties in a trains pathfinder because every node would have to also keep track of distance from last visited chain signal as this value would be required for cases when a train is within chain signal section: this would be to prevent changing a path into one that cannot be immediately reserved in a way that would allow the train to leave entirely. Without this if train would have a reservation for all chain signals in intersection and some rail signals after it with enough distance reserved, when a repath would happen the train pathfinder could find another path that also leaves the intersection but there would be not enough rail signals that can be immediately reserved and the train would not leave intersection entirely.
- trains could stop on the green chain signal. Signals state depends mostly on rail block state, adding an extra logic to make the signal red or blue as soon as train braking distance hits that signal in theory is possible but this would make them behave in a weird way: you see a green chain signal and when a train arrives it immediately turns red or blue with no other trains involved at the intersection guarded by that chain signal.
- it would not be able to cover cases where a train stop is within a train length (+margin of 3) from the intersection's exit rail signal. Train in that case could end partially on the intersection. Trying to fix this on the pathfinder level would mean it could happen that path goes through destination train stop without stopping at it only because there is a loop that goes around and arrives at the destination train stop again but with longer distance from last intersection exit. This immedaitely means some pathfinder nodes would have to be able to be visited multiple times and i am not going to do that just for this feature.

Currently i am in a "wont implement" state but feel free to discuss.

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

Posted: Thu Oct 29, 2020 8:00 am
by JimBarracus
Laramy65 wrote:
Thu Oct 29, 2020 7:31 am
you and OP seem to be motivated by absolutely the same. to remove gameplay from game. calling things bad track design just seems like blaming player for engaging in gameplay.

OPs idea isn't flawed because he plays the game wrong. it is flawed because it removes what is to be played. thuus it is the wrong approach to suggest that it is what ought to be done.
Well it is bad track design when a train is not able to clear an intersection.
Chain signals are meant for that special case and if you dont make sure, that the train fits within the block after the chain signal it is you, who made this block not big enough.
There is a given set of rules and if you ignore these rules, you end up with a bad track design, which will sooner or later fail.

Feel free to build a wonky signalled track.
But dont be surprized, when everything is seized up to a point of no return.

Edit: I dont think is is good to add logic to prevent player mistakes. This is what makes the so called "gameplay".
Remember when pipes had no "no-mixing" feature?
Sure it was annoying when fluids mixed andyou had to tear a lot down, but you had to be carefull when setting it up.
Errors were punished.

But thris would derail the discussion and track design (pun intended).

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

Posted: Thu Oct 29, 2020 8:53 am
by Laramy65
JimBarracus wrote:
Thu Oct 29, 2020 8:00 am
Laramy65 wrote:
Thu Oct 29, 2020 7:31 am
you and OP seem to be motivated by absolutely the same. to remove gameplay from game. calling things bad track design just seems like blaming player for engaging in gameplay.

OPs idea isn't flawed because he plays the game wrong. it is flawed because it removes what is to be played. thuus it is the wrong approach to suggest that it is what ought to be done.
Well it is bad track design when a train is not able to clear an intersection.

This may seem like an awfully pedantic thing to say, but I'll shoot. It is actually bad track design when it causes a jam. Not being able to clear a signal is just one of the ways that can happen. There is simply more principles involved. Consider all the trains that will go through a specific intersection, and what must happen for them to seize. One may make sure that all trains can clear all intersections in all cases ever. Or just consider that it cannot happen in the intersections it actually goes through in combination with all the trains that also go there.

Then consider that those are only two of all the approaches, and yours is too broad and limiting isay. as long as you really did mean all intersections and all trains over the whole system must be compatible always

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

Posted: Thu Oct 29, 2020 5:50 pm
by macdjord
ssilk wrote:
Thu Oct 29, 2020 7:24 am
What I currently ask me: is it possible to built some circuits to do that kind of forward check? Aka put outgoing signal to red, when train is a long train and more blocks behind that signals are still occupied.
For me this sounds like a simple logic, and so it can be rebuilt by circuits.
I don't see any way to do that; there's no way I know of for a circuit to know where the train in a given block is going.

boskid wrote:
Thu Oct 29, 2020 7:57 am
- it would not be able to cover cases where a train stop is within a train length (+margin of 3) from the intersection's exit rail signal. Train in that case could end partially on the intersection. Trying to fix this on the pathfinder level would mean it could happen that path goes through destination train stop without stopping at it only because there is a loop that goes around and arrives at the destination train stop again but with longer distance from last intersection exit. This immedaitely means some pathfinder nodes would have to be able to be visited multiple times and i am not going to do that just for this feature.
That's fine; I never expected it to handle that case. Designing your stops to account for train length so they don't jam is a lot more reasonable an ask than having to worry about every interchange on the main line; for one thing, no matter how many different train lengths you use globally, it's very rare to have multiple trains of different lengths visiting the same stop.

JimBarracus wrote:
Thu Oct 29, 2020 8:00 am
Laramy65 wrote:
Thu Oct 29, 2020 7:31 am
you and OP seem to be motivated by absolutely the same. to remove gameplay from game. calling things bad track design just seems like blaming player for engaging in gameplay.

OPs idea isn't flawed because he plays the game wrong. it is flawed because it removes what is to be played. thuus it is the wrong approach to suggest that it is what ought to be done.
Well it is bad track design when a train is not able to clear an intersection.
Chain signals are meant for that special case and if you dont make sure, that the train fits within the block after the chain signal it is you, who made this block not big enough.
There is a given set of rules and if you ignore these rules, you end up with a bad track design, which will sooner or later fail.

Feel free to build a wonky signalled track.
But dont be surprized, when everything is seized up to a point of no return.

Edit: I dont think is is good to add logic to prevent player mistakes. This is what makes the so called "gameplay".
Remember when pipes had no "no-mixing" feature?
Sure it was annoying when fluids mixed andyou had to tear a lot down, but you had to be carefull when setting it up.
Errors were punished.

But thris would derail the discussion and track design (pun intended).
Again: Congratulations on accurately describing the game as it is now. The point of this suggestion is that the game would be better if it didn't work that way. This isn't 'preventing player mistakes'. This is 'requiring the player to worry about this isn't fun, so let's not'.

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

Posted: Thu Oct 29, 2020 5:53 pm
by NotRexButCaesar
This suggestion sounds nice, I'd like it if it were implemented.

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

Posted: Fri Oct 30, 2020 6:44 am
by JimBarracus
macdjord wrote:
Thu Oct 29, 2020 5:50 pm
This is 'requiring the player to worry about this isn't fun, so let's not'.
@devs can we please remove train signals because they seem not to be fun to deal with?

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

Posted: Fri Oct 30, 2020 8:17 am
by ssilk
I thought about this and what I currently think is this:

This happens, when a player builds tracks and signals so, that the end of a train can lay in the crossing that was “protected” by the chain signals.

That is either a failure when building or later when adding trains that are longer.

But I think recognition of that cannot be automated, because it can get really complicated. Boskid made some explanations and I think I found more issues, but that is to complicated to explain here and it doesn’t matter much.

I have a simple example that shows, that this suggestion would prevent other players to develop their own ideas: I use trains with the same length. I have a cascade of crossings. Chain signals, the space for one train, then chain signals, another space for a train. Under normal circumstances such a construction can be a real blocker. But instead that I reserve a block after the chain signal, I place two blocks.

Fail? No! The train waits in front of a chain signal and it occupies both blocks, so that the chain behind is also red. In the moment when the train gets green and begins to drive it leaves the first block, chain before gets green and the train before begins to drive and so on. This little trick increases the speed of such bottlenecks more than 100%.

There have been said, that the block after a crossing needs to be block for the longest train. But if you use trains of the same length, you can make some abbreviations. :)


And there are other tricks like that. An automatism will not be able to find such a solution, because it cannot only watch about the static situation cases, it needs to simulate it.

Together with boskids answer I have currently this picture:
- happens only when mixing trains with different length
- or when player is (yet) not aware of that

For the first issue:

I created an own suggestion: How about a train filter sign?

And for the case that the player hasn’t learned that yet, we have tutorials, or the display where you can place signals shows kind of recommendations. But I leave that to others, that they can work out that suggestion.

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

Posted: Fri Oct 30, 2020 6:23 pm
by macdjord
ssilk wrote:
Fri Oct 30, 2020 8:17 am
But I think recognition of that cannot be automated, because it can get really complicated.
No, it isn't. We already have a workable design in the first post that solves this problem. The implementation in code may be complicated, since it requires changes to the pathfinding system and the handling of chain signal colours, but the problem of recognizing whether there's enough space for a train to exit a chain signal is quite simple.
ssilk wrote:
Fri Oct 30, 2020 8:17 am
I have a simple example that shows, that this suggestion would prevent other players to develop their own ideas: I use trains with the same length. I have a cascade of crossings. Chain signals, the space for one train, then chain signals, another space for a train. Under normal circumstances such a construction can be a real blocker. But instead that I reserve a block after the chain signal, I place two blocks.

Fail? No! The train waits in front of a chain signal and it occupies both blocks, so that the chain behind is also red. In the moment when the train gets green and begins to drive it leaves the first block, chain before gets green and the train before begins to drive and so on. This little trick increases the speed of such bottlenecks more than 100%.
That's a neat trick, but it's completely irrelevant to this ides; that plan only works if you have enough room between the crossings for any train.

ssilk wrote:
Fri Oct 30, 2020 8:17 am
I created an own suggestion: How about a train filter sign?
An interesting idea, but not a replacement for this. Filtering trains by length would let you keep long trains out of sections of track designed for short ones, but you'd still have to make sure that the shared main lines are able to handle the longest trains.

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

Posted: Sat Oct 31, 2020 7:06 am
by ssilk
Well, you negated all (not only mine) arguments and stated, that this is still a relevant suggestion.

But it is still

- very unclear, how to implement this (boskid said no)

- a source of possible problems. Like: what if the train cannot reserve enough space after the chain signal, because there is another chain in between? I can think of many ways to solve that. Like going further after that next chain and trying to reserve that also. But in some rail layouts this would lead to a complete chaos, deadlocks, and more, because such a long train would reserve half of the map and take a minute to drive through that.

- possible to use the current behavior to your advantage. It will destroy some already existing tricks (my example was to show that you can plan forward to use such tricks)

- unclear, if this mixing of train length is a preferable gameplay (see begin of discussion), if it adds that much gameplay compared to the number of users, that might need this.

- not upward compatible. I can think about many situations, where this feature will break existing maps. New features needs to be a bit more upward compatible.

- too specific. It works not in any case, like when the trains get really long, hundred wagons or more. It solves one small problem for a small minority of players. I don’t want to discuss their problems away, but it is just a fact, that proper planing of a rail network solves such problems. It is not impossible and can be seen as part of the game. In doubt a player needs to destroy parts of a rail network to make them work for mixed trains. But that is still part of the gameplay.

But the discussion about it was important and it is a very good example that shows, that one idea leads to other ideas. :)