Hello,
Entry signal says: Green as long as there is one or more green exit-signal from fallowing section of track. Otherwise it shows red."
Exit signal says:"Behaves in the same way as a block signal but it is necessary to trigger the correct color on entry signals."
Unfortunately, Entry signals turns green even there is no REACHABLE exits. So Exit signal might trigger green, but function of pre-signal isn't delivered. Check the screen shot:
https://imgur.com/ePJCRPB
Train3 has NO EXIT possible from the next block, but his Entry signal say green, so he enters the block.
https://imgur.com/a/eBGdSPP
And is stuck.
The current logic only checks the block for existence of exit signals. However, Entry-exit follow up need(should) work as pre-signals checking if there is a possibility to actually LEAVE the next block. Which doesn't work.
Recommendation: Entry signal need to check if there is reachable Exit signal then turn to green. Reachable means it checks if it possible go there, includes test option for 90degree turns Off/On.
Thank you for fix the bug
///////////////////////////////////////////////////////////
2 Unfortunate behaviour of Entry Signal
Entry signal says: Green as long as there is one or more green exit-signal from fallowing section of track. Otherwise it shows red."
There is no Exit signal in the network, but Enter is green.
https://imgur.com/GHAjOd7
Recomendation: make it so, the Entry signal works EXACTLY as the description says. It will be a bit easier for beginners to get into it. I see a lot of people confused from signals. I understand them.
Thank you
Entry Signal do not recognize Exit signal
Moderator: OpenTTD Developers
Re: Entry Signal do not recognize Exit signal
This behaviour isn't going to be changed: pre-signals are block signals, and a block is a block regardless of shape or connectivity. If you want to detect paths, use path signals.
Re: Entry Signal do not recognize Exit signal
I am not talking about path detection. Paths signals has own role. Presignals has different role. Do not mix apples with piers. In current behavior, presignals are only usefully in few seldom cases. Otherwise makes havock. Which is shame.PikkaBird wrote:This behaviour isn't going to be changed: pre-signals are block signals, and a block is a block regardless of shape or connectivity. If you want to detect paths, use path signals.
Presignal need to teel if upcoming block is passable. That is role of the pre-signal.
That role doesnt work.
Re: Entry Signal do not recognize Exit signal
I agree that the addition of path signals has made presignals almost entirely useless, but I'm not sure why that's a shame, or how adding pathing to presignals would help - it would, in fact, make them even more redundant.
- planetmaker
- OpenTTD Developer
- Posts: 9432
- Joined: 07 Nov 2007 22:44
- Location: Sol d
Re: Entry Signal do not recognize Exit signal
If I understand it correctly, it's two different things:
a) there's the block signals. Considering those, the pre-signals work perfectly well in the way intended. And that's how it's stated in the description (if you disagree: please make a suggestion how to word description and tooltips to reflect it).
b) there's path signals. You don't have any pre-signals for those. Yet you usually don't need any: place the next signal after an intersection (or whatever) far enough so that a train can wait in front of it without blocking the intersection. The unoccupied path in the same "block" can already be used by other trains again.
See also
https://wiki.openttd.org/Signals
and especially
http://kokolokus.de/articles/openttd-signals-explained/
a) there's the block signals. Considering those, the pre-signals work perfectly well in the way intended. And that's how it's stated in the description (if you disagree: please make a suggestion how to word description and tooltips to reflect it).
b) there's path signals. You don't have any pre-signals for those. Yet you usually don't need any: place the next signal after an intersection (or whatever) far enough so that a train can wait in front of it without blocking the intersection. The unoccupied path in the same "block" can already be used by other trains again.
See also
https://wiki.openttd.org/Signals
and especially
http://kokolokus.de/articles/openttd-signals-explained/
OpenTTD: manual | online content | translations | Wanted contributions and patches
#openttdcoop: blog | wiki | public server | DevZone | NewGRF web translator
DevZone - home of the free NewGRFs: OpenSFX | OpenMSX | OpenGFX | Swedish Rails | OpenGFX+ Trains|RV|Industries|Airports|Landscape | NML
Re: Entry Signal do not recognize Exit signal
The existing tooltips are not wrong. They do not imply reachability, that's just a product of the human desire to find meaning and usefulness in every little detail. </philosophy> Often, the lack of expected usefulness is a good thing, it makes other uses possible. In this case, satisfying your request would destroy most of the clever things #openttdcoop do.
https://wiki.openttdcoop.org/Main_Page
https://wiki.openttdcoop.org/Logic
https://wiki.openttdcoop.org/Priority
https://wiki.openttdcoop.org/Category:A ... Networking
(I attempted to design a system to provide priorities, logic, and other things without crazy tracks and signalling. I realized it would be even harder to learn and use than what #openttdcoop do. It would also have the disadvantage of not being visible on the map.)
Edit: Here's how I look at it: train routing in OpenTTD is like programming. In programming, making sense is up to the human, not the computer. To demand the computer makes sense at the programming level is to destroy all the interesting possibilities.
Some other arguments:
Block signals have always been like this, all the way back to TTO.
In some circumstances, block signals work better than path signals. Few games have pathfinding as good as OpenTTD in the first place, so it's remarkable path signals work as well as they do. Adding pathing to block signals would make them work less well.
https://wiki.openttdcoop.org/Main_Page
https://wiki.openttdcoop.org/Logic
https://wiki.openttdcoop.org/Priority
https://wiki.openttdcoop.org/Category:A ... Networking
(I attempted to design a system to provide priorities, logic, and other things without crazy tracks and signalling. I realized it would be even harder to learn and use than what #openttdcoop do. It would also have the disadvantage of not being visible on the map.)
Edit: Here's how I look at it: train routing in OpenTTD is like programming. In programming, making sense is up to the human, not the computer. To demand the computer makes sense at the programming level is to destroy all the interesting possibilities.
Some other arguments:
Block signals have always been like this, all the way back to TTO.
In some circumstances, block signals work better than path signals. Few games have pathfinding as good as OpenTTD in the first place, so it's remarkable path signals work as well as they do. Adding pathing to block signals would make them work less well.
Extreme network builder. screenshot thread
Who is online
Users browsing this forum: No registered users and 30 guests