Yellow signal state
Moderator: OpenTTD Developers
((Edit: I discovered that I violated the rule that forbids to build a depot in a pbs-block, but it changes nothing. I tried it out without depot, and it works nevertheless.))csuke wrote:ok, (i think) i found a problem with this patch
the pbs pre-signals (5th,6th,7th signal states) arent actually pbs, they are just normal pre-signals (i think)
Hm, seemingly not.
I don't really understand how the 5th, 6th and 7th signal states were intended to work, so I did a little bit testing this night.
I came across the stiutation you've mentioned, and it seems like at least the 5th signal state works like pbs and pre-signal.
The situation:
Train Nr. 4 wants to enter the block, but all signals behind the block are occupied, it doesn't enter the block -> pre-signal. The interesting thing is, they're not divided into entry signals and exit signal, they're all the one with the green bar.
Afterwards, I forced Nr. 4 to enter the block nevertheless, and of course it stops in front of one of the signals, which are used to be exit-signals.
After the bottom line was vacated, the bottom two-way-signal changes to yellow, and Train Nr.5 entered the block, although it is occupied -> pbs.
To cut a long story short, the 5th signal unites pbs and pre-signal.
As usual, sorry for my bad english and excess length.

Edit: I use Integrated Nightly Build R3345IN.
To cut it even shorter, PBS signals are presignals anyway. If the exits are red (as in the first picture) the next train won't enter the block. That block is behaving exactly as normal PBS signals behave.Sword wrote:o cut a long story short, the 5th signal unites pbs and pre-signal.
PGP fingerprint: E66A 9D58 AA10 E967 41A6 474E E41D 10AE 082C F3ED
It looks like there are more problems with the PBS/Pre-Signals, or i am doing something wrong. 
I attached a screenshot with somethings i have tried to make it possible that another train has to wait before it may enter a line. That works, but is also stops the wrong trains like shown in the picture.

I attached a screenshot with somethings i have tried to make it possible that another train has to wait before it may enter a line. That works, but is also stops the wrong trains like shown in the picture.
- Attachments
-
- Trains waiting for nothing
- tdd-pre-sig.png (267.15 KiB) Viewed 1787 times
I also found problems with pre-/combo-/exit-signal configurations (in the integrated nightly build R3345IN). The signal lay-out I use works well in the (ordinary) nightly build r3353.
(See screenshot 1)
I should note that there are no trains in the tunnels. This behaviour is not influenced by the setting "Use normal signals as three-state signals", i.e. I encounter this situation even if the patch is switched off.
In screenshot 2, I demolished the entrances while there were no trains near the problematic signals. Even in this situation, the signals stay red. (Again, there are no trains in the tunnels.)
It seems that there is a problem in clearing the signal blocks.
Also, when I tried to figure out what the green/red bars on the signals are (failing to do so by just observing their behaviour), I get an error with the last three signal states (!invalid string id 0 in GetString). It seems that they are not (yet) properly named.
Can someone please explain what they (should) do?
(See screenshot 1)
I should note that there are no trains in the tunnels. This behaviour is not influenced by the setting "Use normal signals as three-state signals", i.e. I encounter this situation even if the patch is switched off.
In screenshot 2, I demolished the entrances while there were no trains near the problematic signals. Even in this situation, the signals stay red. (Again, there are no trains in the tunnels.)
It seems that there is a problem in clearing the signal blocks.
Also, when I tried to figure out what the green/red bars on the signals are (failing to do so by just observing their behaviour), I get an error with the last three signal states (!invalid string id 0 in GetString). It seems that they are not (yet) properly named.
Can someone please explain what they (should) do?
- Attachments
-
- [Screenshot 2] The signals stay red even if there are no trains!
- wrongsignals2.png (59.75 KiB) Viewed 6348 times
-
- [Screenshot 1] Those signals should not be red.
- wrongsignals1.png (72.9 KiB) Viewed 6349 times
wonderful track sprites, where have you got them?JackRange wrote:It looks like there are more problems with the PBS/Pre-Signals, or i am doing something wrong.
I attached a screenshot with somethings i have tried to make it possible that another train has to wait before it may enter a line. That works, but is also stops the wrong trains like shown in the picture.
A green horisontal bar is a pbs signal.
A red horisontal bar is a pbs presignal entry.
A green vertical bar is a pbs presignal exit.
A red vertical bar is a pbs presignal combo.
But as stated above, the pbs presignals are not recognized as pbs signals.
And, as also stated above, for some strange reason dual presignal exits and dual presignal combos misbehave.
For the pbs presignal problem, i'm considering just removing them again since fixing in the way I thought it should be fixed didn't help. (Making PBSIsPbsSignal recognize them that is.)
For the normal presignals, I can't figure out where it goes wrong. I'll have to continue looking at that. If somebody has any ideas, please feel free to tell me.
A red horisontal bar is a pbs presignal entry.
A green vertical bar is a pbs presignal exit.
A red vertical bar is a pbs presignal combo.
But as stated above, the pbs presignals are not recognized as pbs signals.
And, as also stated above, for some strange reason dual presignal exits and dual presignal combos misbehave.
For the pbs presignal problem, i'm considering just removing them again since fixing in the way I thought it should be fixed didn't help. (Making PBSIsPbsSignal recognize them that is.)
For the normal presignals, I can't figure out where it goes wrong. I'll have to continue looking at that. If somebody has any ideas, please feel free to tell me.
I have thought a little about signals should work in my opinion, and how this could be implemented in OpenTTD (just how they should behave in the game, not the source code).
I thought of what I once read about the signals used in the Netherlands. Basically, there are 2 sorts of signals: Automatic signals (which are called P signals, which is rather confusing in an OpenTTD-context), which behave more or less as the normal signals in TTD would do. The other type is the path-based signal, used at junctions and stations, where large quantities of tracks meet. The latter type is operated by humans and/or computers (in a control tower). In contrast with TTD, path-based signals are red until a path has been set by the control tower.
Now I came up with the following idea for OpenTTD.
For some reasons, I wish to used two-state signals and three-state signals at once. For instance, at the entrance of a long tunnel (or bridge), I don't want to have a signal that shows yellow. If you would place a three-state signal there, the signal would show yellow as soon as the block is cleared. If we would have a train waiting to enter the tunnel, it will depart as soon it gets yellow. However, this means that the train will get a speed restriction for the entire tunnel. We just want it to travel at maximum speed as soon as the tunnel is free.
Also, near stations, where trains usually travel relatively slow, you would not really need yellow signals.
I would suggest a more logical placement method for signals:
- 4 buttons (2-state light signal, 3-state light signal, 2-state semaphore, 3-state semaphore) in the construction bar
- Just clicking on an empty track places normal (non-PBS) signal, ctrl-click places PBS signal
- Clicking on an piece of track already containing a signal cycles through the signal layout (two-way, one-way, the other one-way) just as it does now.
- Ctrl-clicking on a track with signal switches between normal signal, presignal entry, presignal exit, presignal combo. Also just as it does now.
This way we have 4x2x3x4=96 types of signal configurations we may place on a particular piece of track. At least you would have to invent a way in which you don't have to click 95 times if you need the last configuration.
Also, as I already mentioned, I think PBS signals should be red if there are no paths through the signal block. Also, you have to figure out a way to recognise them in the field (i.e. which horizontal/vertical bars in which colour should be on which signal?). This should also be done in a logical way. (Maybe you figured it out already: I am a mathematician. I like things being logical
).
This is just a suggestion, I am not telling how it should be, only how it could be, or at least how it would be if I would write the source code.
I have even more ideas, but for this is enough for today.
I thought of what I once read about the signals used in the Netherlands. Basically, there are 2 sorts of signals: Automatic signals (which are called P signals, which is rather confusing in an OpenTTD-context), which behave more or less as the normal signals in TTD would do. The other type is the path-based signal, used at junctions and stations, where large quantities of tracks meet. The latter type is operated by humans and/or computers (in a control tower). In contrast with TTD, path-based signals are red until a path has been set by the control tower.
Now I came up with the following idea for OpenTTD.
For some reasons, I wish to used two-state signals and three-state signals at once. For instance, at the entrance of a long tunnel (or bridge), I don't want to have a signal that shows yellow. If you would place a three-state signal there, the signal would show yellow as soon as the block is cleared. If we would have a train waiting to enter the tunnel, it will depart as soon it gets yellow. However, this means that the train will get a speed restriction for the entire tunnel. We just want it to travel at maximum speed as soon as the tunnel is free.
Also, near stations, where trains usually travel relatively slow, you would not really need yellow signals.
I would suggest a more logical placement method for signals:
- 4 buttons (2-state light signal, 3-state light signal, 2-state semaphore, 3-state semaphore) in the construction bar
- Just clicking on an empty track places normal (non-PBS) signal, ctrl-click places PBS signal
- Clicking on an piece of track already containing a signal cycles through the signal layout (two-way, one-way, the other one-way) just as it does now.
- Ctrl-clicking on a track with signal switches between normal signal, presignal entry, presignal exit, presignal combo. Also just as it does now.
This way we have 4x2x3x4=96 types of signal configurations we may place on a particular piece of track. At least you would have to invent a way in which you don't have to click 95 times if you need the last configuration.

Also, as I already mentioned, I think PBS signals should be red if there are no paths through the signal block. Also, you have to figure out a way to recognise them in the field (i.e. which horizontal/vertical bars in which colour should be on which signal?). This should also be done in a logical way. (Maybe you figured it out already: I am a mathematician. I like things being logical

This is just a suggestion, I am not telling how it should be, only how it could be, or at least how it would be if I would write the source code.
I have even more ideas, but for this is enough for today.
We've been through this before. Pre-PBS signals would be useful for a station where all platforms are bi-directional.MeusH wrote:Please show me examples of using pre-PBS signals, I'm lost and I really don't see point of having this in game. Thank you
Here's where I answered you the last time you asked this: http://www.tt-forums.net/viewtopic.php?p=368681#368681
PGP fingerprint: E66A 9D58 AA10 E967 41A6 474E E41D 10AE 082C F3ED
Ohh, missed
Bi-directional... something like two-wat ro-ro station? Screenshot, please?
Thank you in advance
Meush
I'd like to see a screenshot, but a draw could be also helpful. Paint-edited OTTD screenshot would be good aswell.Brianetta wrote: If this doesn't explain it, let me know and I'll draw it, scan the image, and email it to you.
Bi-directional... something like two-wat ro-ro station? Screenshot, please?
Thank you in advance
Meush
Last edited by MeusH on 06 Jan 2006 17:19, edited 1 time in total.
You should be able to use the same signal placement as if you weren't using the yellow signals patch. Since there is only one track in each direction the loadbalancing part won't have any effect.
If you are using the option to have trains slow down at yellow signals, you might have to adjust the distance between signals to optimize performans.
If you are using the option to have trains slow down at yellow signals, you might have to adjust the distance between signals to optimize performans.
I have some ideas that you may wish to consider...
Firstly, it is very rare, even in real life, to find tracks that have signals placed evenly apart. Thus, it is not sensible to create a system to estimate the slowing down of trains when encountering yellow signals. just 1 predefined speed will do. Preferably user-settable and changable in the game.
The others... I'll get them back out if I can remember what they were...
Firstly, it is very rare, even in real life, to find tracks that have signals placed evenly apart. Thus, it is not sensible to create a system to estimate the slowing down of trains when encountering yellow signals. just 1 predefined speed will do. Preferably user-settable and changable in the game.
The others... I'll get them back out if I can remember what they were...

Come on people! Concentrate on merging ttdpatch into openttd!
Please spare a thought for those not on M$!
Please spare a thought for those not on M$!
Who is online
Users browsing this forum: No registered users and 2 guests