Transport Tycoon Forums

DaleStan wrote:Then don't say that they behave like presignals.

And I seem to see a presignal flag on some of those PBS signals. I thought you said that presignals wouldn't be needed any more.

That wasn't me who said that. But anyway, these new pbs signals will do most of what you could do with presignals, so presignals are not really needed. What doesn't work is wacky stuff like priority lines, but as this patch is about realistic signals, I'm not bothered.

And the pre-signal entry graphics are, like Tekky said, used for the no-entry signals because I'm certainly no graphics artist and couldn't paint a signal to safe my life.

-- Michael Lutz

It would be much clearer if one way signals appear as they are currently - a single signal, whilst two way signals appear as they do currently - two signals. Even if this is not functionally the case it is much clearer graphically and easier to get used to...

Zephyris wrote:It would be much clearer if one way signals appear as they are currently - a single signal, whilst two way signals appear as they do currently - two signals. Even if this is not functionally the case it is much clearer graphically and easier to get used to...

And how would you then see which side of a pbs signal is the "active" side and from which side a train can pass the signal?
-- Michael Lutz

Please dont take this the wrong way...

To me, it just looks wrong that you can pass the back side of a signal. It may be real, but its not TTD. Maybe its just something that will take time to get used to.

Maybe what is needed is to have a signal "stump" where the old two-way signal was. This will clearly say "This side no longer matters". Or maybe, have a small sign with a red cross (like the "not this way" routemarker - see my sig) on the no-through side of one-way signals.

My preference would be for the single one-way signal to be just a normal lone signal. Nothing special about it, and work on the graphical representation of the other signals so that they are clear at allowing two way traffic.

The signals which allow two way traffic could be made more "intelligent", acting as a signal in the appropriate direction when necessary. These could then be given the current two way graphics and when placed would behave in essentially the same way...

richk67 wrote:To me, it just looks wrong that you can pass the back side of a signal. It may be real, but its not TTD. Maybe its just something that will take time to get used to. ...

Well OpenTTD already contains so much features that aren't original TTD(including for example el. rails, presignals, and in future NewGRF_Ports(right? )) and this is, I believe only difference in graphics, so it should be possible to change it with NewGRF file right? Or(And) it could be handled in same way as el. rails(because that's the same case - more realistic, but possibly disliked by some players) - on by default, with switch to turn it off.

Maybe I should have advertised this patch as newsignals and not as PBS, because PBS is only an end to a means. The main point of this patch is to create a more realistic signal system: Instead of the old system of one block - one train with signals that divide the blocks it is now path based (a signal block can have as many trains as possible without crossing paths) and signals as safe waiting points and not block dividers.
And because signals are now waiting positions and not block boundaries, two-sided signals don't really make sens because they only generate deadlocks as two trains waiting on each other on each side are definitly not both on a safe waiting position.

Anyway, enough ranting for today, I may now present you the next version.

Changes:

• Fixed a bug where trains would sometimes crash in terminus stations. (Thanks MarkyParky)
• Fixed a bug where a looping path would lead to crashes. As a side effect this now inhibit trains from leaving a depot if they want to enter the same depot again. Place signals on any track loops to solve that. (Thanks Tekky)
• Improved code style. (Thanks Tron)
• Changed the semantics of no-entry signals, more below.
• Introduced different patch settings to control which signals to build, more below. This breaks savegame compatibility.
• PBS signals can now be build via the signal GUI.

No-entry signals:
There are now two kinds of PBS signals: signals that can be passed from behind and signals that disallow passing just like the regular signals. The passable signals use the old PBS signal graphics, the one-way signals the old PBS pre-signal graphics. If somebody can draw appropriate new sprites for these signals, I will gladly use these to minimise any confusion.

Patch options:
There are now two patch options: 'Signal type to build by default' should be pretty self-explanatory. You can switch between normal, pbs and one-way pbs signals. The second option is 'Cycle through signal types', it controls which signal types are cycled through by ctrl-click. Options are cycle only the regular signals, only the pbs signals or all signals. You can always change these settings in game. Note that both settings aren't synchronised in any way.

First post updated as well.

-- Michael Lutz

Thank you very much for the bugfixes, I will try the new patch right away

I have a little bug report:

When you try to bulldoze a depot which a train is heading into, it lets you bulldoze it. The train then continues heading down to where the depot was and when it encounters the dead end (where the depot was), it reverses. In my case, this caused a train crash after reversing.

For this reason, I think it should not be allowed to bulldoze depots if a train has reversed a path into the depot.

EDIT: It is also possible to remove a signal that a train has reserved a path to. In the case of that signal being removed or changed, the train will simply drive past that location where the signal was, possibly causing a crash. Therefore, I think that signals that a train has reserved a path to should not be allowed to be removed or changed.

EDIT2: Apart from these minor issues, I love your patch, though

Why are depots any different than any other reserved tile?

And if they aren't any different, now you're preventing removal of any tile that happens to be reserved, so what's the procedure for removing reservations that got erroneously left by bugs?

DaleStan wrote:Why are depots any different than any other reserved tile?

And if they aren't any different, now you're preventing removal of any tile that happens to be reserved, so what's the procedure for removing reservations that got erroneously left by bugs?

In an ideal world, there wouldn't be any erroneous reservations, but as bugs can happen, the bulldozer will remove anything for now, even with reservations on it. Just be carefull were you click.
The remove single rail tool and the remove station part tool will not allow removal of reserved track. The remove signal tool should probably do that as well.

-- Michael Lutz

Why should these be saved in the savegame? They're client-side so should be like the other client-side options and only saved in the config.

[Re: signal graphics]

Let me just point out that there are already a couple of PBS-related signals, both light and semaphore signals, in ttdpbase[w].grf, supplied by me. As these are under the GPL, they may be used.

regards
Michael

Tekky wrote:I have a little bug report:

When you try to bulldoze a depot which a train is heading into, it lets you bulldoze it. The train then continues heading down to where the depot was and when it encounters the dead end (where the depot was), it reverses. In my case, this caused a train crash after reversing.

For this reason, I think it should not be allowed to bulldoze depots if a train has reversed a path into the depot.

EDIT: It is also possible to remove a signal that a train has reserved a path to. In the case of that signal being removed or changed, the train will simply drive past that location where the signal was, possibly causing a crash. Therefore, I think that signals that a train has reserved a path to should not be allowed to be removed or changed.

I disagree. This could make it impossible to modify rail network under heavy traffic.
Wouldn't better solution be to check which train has reserved bath to the current tile, and then find a new path for it?

Besides, in original TTD signalling, when you remove a signal while a train is approaching it, you're likely to cause a train crash as well... You're merging two blocks into one after all...

Mchl wrote: I disagree. This could make it impossible to modify rail network under heavy traffic.
Wouldn't better solution be to check which train has reserved bath to the current tile, and then find a new path for it?

Besides, in original TTD signalling, when you remove a signal while a train is approaching it, you're likely to cause a train crash as well... You're merging two blocks into one after all...

And in current OpenTTD, too. I wouldn't call this a bug, either. If you are modifying the signaling infrastructure (removing signals, connecting previously separate tracks etc.) during operation, you have to take care (e.g. stop the traffic if needed) or you get punished with crashes[0]. I consider this part of the game. The game should avoid crashes in normal operation but not if the player interferes with the signaling.


[0] We're talking here about train crashes, of course, not the game crashing

Tekky wrote:

Roujin wrote:However what I was clearly missing was combining the pbs signals with presignals - are you planning to do that in a future version?

I see no point in having additional PBS-pre-signals because PBS-signals have similar behavior as pre-signals. As long as you only place signals before and not after junctions (in contrast to traditional OpenTTD signalling), there should be no need for having pre-signals.

Please note that these new PBS-signals behave very differently to TTDPatch-pre-signals and the old PBS system of OpenTTD. In this new signalling system, you are only supposed to place signals where trains are supposed to wait. Since trains are only supposed to wait in front of junctions and never inside a junction, you must place signals only before an intersection/junction and never immidiately afterwards.

It seems I still have to get used to these signals. there was some stuff i was unable to build because I was used too much to the style of "normal" signalling in OpenTTD. Some of the screenshots posted in this thread afterwards already helped me, but I think I'd need some really good tutorials on PBS to fully understand how to use it
Well, good luck with developing it further then

Roujin wrote: It seems I still have to get used to these signals. there was some stuff i was unable to build because I was used too much to the style of "normal" signalling in OpenTTD. Some of the screenshots posted in this thread afterwards already helped me, but I think I'd need some really good tutorials on PBS to fully understand how to use it
Well, good luck with developing it further then

The main new rule is that you are only supposed to place signals in locations where trains are supposed to wait. Assuming you don't want trains to block intersections while waiting, this means you should only place signals before intersections and never immediately after intersections, so that trains always wait in front of the intersection and never inside it. Of course, if you enjoy trains blocking intersections, you can continue placing signals the traditional way

The other important rule is that you should always place a signal in front of every platform to prevent a train from leaving the platform when the track is not clear. I had several crashes because I had forgotten to do this

Also, I don't recommend mixing traditonal and PBS signals or to at least keep them on seperate track networks. Otherwise, you will have many issues with train collisions, because they seem to not be compatible. When upgrading your old signals to PBS, I recommend sending all trains into the depot beforehand. Otherwise you will have many train collisions. Only let the trains out of the depot again after the entire track network has been upgraded to PBS signals.

Maybe the easiest way to learn the new signals is to see them in action. In the attached savegame, I demonstrate the power of the new PBS system. Please note the station layout of Little Gratfingford Heights, which is in the center of the screen when you load the game. The junction in front of this terminal station offen allows up to 3 or 4 trains at the same time inside the junction. Also note how I designed the track to the far-away station. I have two tracks in every direction. With traditional signals, I had to leave one tile between both tracks in order to place signals in places where you swap from one track to the other. However, with these new PBS signals, this is no longer necessary.

Tekky wrote:The other important rule is that you should always place a signal in front of every platform to prevent a train from leaving the platform when the track is not clear. I had several crashes because I had forgotten to do this

If the track is not clear surely the train should not have gone into the station in the first place...

It's clear when it goes there. While it is stopped the other train moves to the crashline. The "problem" is that the stopped train doesn't reserve it's route out of the station before stopping.

Zephyris wrote:

Tekky wrote:The other important rule is that you should always place a signal in front of every platform to prevent a train from leaving the platform when the track is not clear. I had several crashes because I had forgotten to do this

If the track is not clear surely the train should not have gone into the station in the first place...

If the track was clear when it enters a station then that doesn't necessarily mean that it will be still clear when leaving a station. Therefore, a train may have to wait before it leaves a station platform, otherwise a collision may occur. For this reason, it is important to place a signal for all trains leaving a platform.