Rename "chain signal" to "look ahead signal"

[tobsimon]

What ?

As the title says, I'd suggest to rename the "chain signal" to "look ahead signal".

Why ?

Many (inexperienced) players are struggling to grasp the concept behind chain signals and need to consult tutorials to get it. To aid players in figuring it out easier and ideally on their own, I think it would be beneficial to convey the function of the chain signal better with it's name.

The current name "chain signal" conveys (by my interpretation) mainly the possibility to link several signals (of the same type) behind each other, which then are somehow connected. But the name doesn't anything to clarify, why you'd want to do what and what functionality you get, by doing that.

The suggested name "look ahead signal" (in my opinion) is much better suited to describe the functionality, that it will only be green, if the next signal ahead is also green. Thus preventing the train to enter the next block, if it is unable to leave it. Also, I think, the suggested name makes it clearer, that this type of signal has additional functionality over the regular signal. Something, which is also misunderstood frequently in my impression, probably because the graphics of the chain signal are simpler as those for the regular signal and thus suggest a simpler use case.

[Optera]

-1
Look ahead signal not only sounds terrible, it also implies a real world Vorsignal (distant signal) which has the entirely different purpose of showing the next main signals state.

[darkfrei]

Here must be better description, the name is ok.

[Tekky]

I agree that the name "lookahead signal" implies a distant signal and not a chain signal. Therefore, I am against them being renamed.

In my opinion, the main problem with chain signals is that Factorio signalling is unrealistic and counter-intuitive.

In reality, track signals are only placed in locations where trains are supposed to wait. In Factorio, however, track signals must be placed both before and after every junction, even if trains are only supposed to wait before the junction and not immediately after the junction (because it would cause the end of the train to be waiting inside the junction). In that respect, the unrealistic Factorio signalling is equivalent to OpenTTD style block signals, whereas realistic signalling is equivalent to OpenTTD style path signals.

Therefore, chain signals would not be necessary in Factorio if the realistic OpenTTD style path signals were used instead.

Introducing the realistic OpenTTD style path signals into Factorio would also have the advantage that it would allow two trains to use the same junction block at once, provided that their paths don't cross.

[Sad_Brother]

Rename is just a decoration. I prefer one type of signals with "chain" option.

If you think "real life" signalling is british signalling, you are wrong. There are many different.

Most times in real life signalling is too complex to implement in game. Too much human controlled. Quantity of signals, signs, other apparatus types are too expansive.

I once tried to look at several different signalling systems, oh my...

[Tekky]

Most times in real life signalling is too complex to implement in game. Too much human controlled. Quantity of signals, signs, other apparatus types are too expansive.

Actually, the more realistic OpenTTD path signals that I mentioned above are also simpler to use, because you require less of them, due to the fact that you only need to place them where trains are supposed to wait.

In my opinion, the more realistic OpenTTD path signals are also more intuitive, as it is intuitive to only have to place signals in places where trains are supposed to wait.

Therefore, in this case, realistic does not mean more complex, at least not for the user. For the programmer, they are indeed more complex to implement. But it has been successfully done in the game OpenTTD, so it surely should be possible in Factorio.

Of course, I am not talking about implementing all kinds of signals that exist in reality, just the most basic signalling system. For example, there is no reason to implement distant signals in the game, as they have no gameplay value (except maybe for providing a bit of additional visual feedback).

[Optera]

I'd love to see OTTD path signals brought to Factorio.
However I'm afraid the devs feel the current signals are good enough, and they kind of are if you learn how to use them.

Distant signals may have a use scenario in warning players of incoming trains.

[Tekky]

I'd love to see OTTD path signals brought to Factorio.
However I'm afraid the devs feel the current signals are good enough, and they kind of are if you learn how to use them.

Factorio developer Kovarex actually says that he likes the idea:

You are basically requesting that signals should work as path signals in ttd: https://wiki.openttd.org/Signals#Path_signals
This is not a bad request, and it is possible that one day, we will want to do it, but I don't consider it a bug report.

Please note that the above quote contains a link to Kovarex's original post.

[Sad_Brother]

Actually, the more realistic OpenTTD path signals that I mentioned above are also simpler to use, because you require less of them, due to the fact that you only need to place them where trains are supposed to wait.

In my opinion, the more realistic OpenTTD path signals are also more intuitive, as it is intuitive to only have to place signals in places where trains are supposed to wait.

Therefore, in this case, realistic does not mean more complex, at least not for the user. For the programmer, they are indeed more complex to implement. But it has been successfully done in the game OpenTTD, so it surely should be possible in Factorio.

Of course, I am not talking about implementing all kinds of signals that exist in reality, just the most basic signalling system. For example, there is no reason to implement distant signals in the game, as they have no gameplay value (except maybe for providing a bit of additional visual feedback).

Path signal are more realistic. Just not realistic. But we are in the game here, not reality. It can n be done so after unlocking "Path signals" knowledge all Signals magically become Path Signals.
It is quite easier for players. It seems you would need no other signals. You would need no signals just to split a block. But how would behave path signals inside? How hard are to program them? How hungry would they for processing power?
From real life I would also prefer to import Signs. Sound sigh for trains to warn players, speed limiter to limit speed of passing trains etc.

[quyxkh]

But it has been successfully done in the game OpenTTD, so it surely should be possible in Factorio.

Don't lose sight of what the game engine as a whole is spending its time trying to achieve. OpenTTD repaths constantly, routing is what it does, the game's about rewarding companies that efficiently route goods magically produced in black-box factories, it spends basically zero time modeling production. So, yeah, if Factorio reallocated its resources away from simulating factory operation it would have more available to simulate the behavior of trains run by companies with central scheduling offices and an entire planning staff and intelligent engineers driving the trains—except in Factorio's world, none of that exists _anyway_.

[Tekky]

But it has been successfully done in the game OpenTTD, so it surely should be possible in Factorio.

Don't lose sight of what the game engine as a whole is spending its time trying to achieve. OpenTTD repaths constantly, routing is what it does, the game's about rewarding companies that efficiently route goods magically produced in black-box factories, it spends basically zero time modeling production. So, yeah, if Factorio reallocated its resources away from simulating factory operation it would have more available to simulate the behavior of trains run by companies with central scheduling offices and an entire planning staff and intelligent engineers driving the trains—except in Factorio's world, none of that exists _anyway_.

Path signals have existed in OpenTTD already since 2007 (ealier implementations also exist, but were discarded). Therefore, I find it hard to believe that a modern computer in 2019 should have trouble handling something that computers were already able to handle well 11 years ago.

Especially now that the Factorio devs have stated that waypoints will be introduced into Factorio (which will make pathfinding computationally a lot cheaper, since shorter distance means less graph nodes have to be explored), it should be possible for megabases to reduce pathfinding computations by utilizing waypoints more.

Of course, optimization will always remain an issue, but I see no serious problems that would - as you say - require Factorio to reallocate its resources away from simulating factory operation.

From real life I would also prefer to import Signs. Sound sigh for trains to warn players, speed limiter to limit speed of passing trains etc.

I agree that speed limits should be implemented. This has already been suggested and discussed in the following threads:

viewtopic.php?f=6&t=60525 Train speed limit signs
viewtopic.php?f=6&t=32459 Railway Speed Limits

[Jap2.0]

But it has been successfully done in the game OpenTTD, so it surely should be possible in Factorio.

Don't lose sight of what the game engine as a whole is spending its time trying to achieve. OpenTTD repaths constantly, routing is what it does, the game's about rewarding companies that efficiently route goods magically produced in black-box factories, it spends basically zero time modeling production. So, yeah, if Factorio reallocated its resources away from simulating factory operation it would have more available to simulate the behavior of trains run by companies with central scheduling offices and an entire planning staff and intelligent engineers driving the trains—except in Factorio's world, none of that exists _anyway_.

I think trains in Factorio repath more than you think.

[Optera]

I think trains in Factorio repath more than you think.

Factorio calculates the whole path to the destination and repaths only when waiting for a long time at signals or the path has been broken.

My info about OTTD is probably outdated. It used to only know the direction of the destination and select a path with short look ahead whenever a vehicle or train got to a junction.
That's why Factorio trains have no problem doing a right turn to go left while OTTD trains got lost.
On the flip side OTTD trains respond to congestions with taking detours much quicker and sort nicely into stackers.

[Jap2.0]

I think trains in Factorio repath more than you think.

Factorio calculates the whole path to the destination and repaths only when waiting for a long time at signals or the path has been broken.

My info about OTTD is probably outdated. It used to only know the direction of the destination and select a path with short look ahead whenever a vehicle or train got to a junction.
That's why Factorio trains have no problem doing a right turn to go left while OTTD trains got lost.
On the flip side OTTD trains respond to congestions with taking detours much quicker and sort nicely into stackers.

Didn't they remove the delay for that (i.e. it repaths immediately upon finding a red signal) or am I wrong on that?

[Tekky]

My info about OTTD is probably outdated. It used to only know the direction of the destination and select a path with short look ahead whenever a vehicle or train got to a junction.
That's why Factorio trains have no problem doing a right turn to go left while OTTD trains got lost.

Yes, your information is outdated by about 12 years.

What you say is only true when using very old versions of OpenTTD which used the original pathfinder from Transport Tycoon or the NTP pathfinder. Since the introduction of the NPF and the YAPF pathfinder, trains actually do calculate their entire route to their destination, so they cannot get lost.

By the way, the two of us have had this discussion already 4 months ago here.

Didn't they remove the delay for that (i.e. it repaths immediately upon finding a red signal) or am I wrong on that?

According to this post by Factorio developer Rseding91, in version 0.15, a train waiting at a chain signal will, under certain conditions, attempt to repath every 5 seconds. However, I don't know if that information is still accurate for version 0.16.

[quyxkh]

Bilka took the time to corral allll the nitty-gritty in the wiki, that's a lot of detail but I think it boils down to: interference like construction, damage and destination-stop disablement, before braking for a signal, when releasing brakes, and while waiting at a chain signal every 5 (if it could switch destination stops) or 30 (if there's only one) seconds.

So routing's solvable and very easy on the CPU, and it poses interesting and challenging design puzzles. For people who just want ploppable I think "frustrating" probably comes in to play there somewhere, but I'm very glad reaching peak potential is still a real challenge for trains.