News:

Want to praise Simutrans?
Your feedback is important for us ;D.

Distant signals

Started by Erik, March 26, 2011, 10:32:13 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Erik

The train drives the signal yes, but only in front of the train.
After the rain has been passed the signal the signal will get back to it's default stage on red.

If the next train comes in a signal range who is also effecting this signal. The signal will acting to that as needed.


Max-Max

Yes, that is what I mean.
We need a mechanism to track a signal behind the train to update it correctly if we are more than one block away. The signal A3 is not showing only the next block, but in this example the status of 3 blocks ahead at the same time.
- My code doesn't have bugs. It develops random features...

jamespetts

This topic is actually rather more complicated than first appears, as the signals behind the train should only show green/clear when no train is approaching if they are what is termed in UK signalling parlance an "automatic" signal. Automatic signals can only be used where there are no junctions/points between it and the next signal. All other signals are "controlled", whose behaviour (remaining red until a path for a specific train has been reserved through them) is the same as the current Simutrans signalling behaviour. In the very early days of signalling, signals were returned to clear (then a white aspect) after the train had passed through. After an accident in the 1870s, the later practice of returning all signals to danger (red) except when they were cleared for a specific train was adopted. This applied to all signals until automatic colour light signals were introduced in about the 1960s.

For Simutrans purposes, it would not make any actual difference to the way in which the trains worked if all signals were treated as controlled: the difference would be purely cosmetic. It would take a great deal of coding effort to (1) check backwards from a train to set previous automatic signals to clear; (2) distinguish in the .dat files between automatic and controlled signals (to prevent signals from the 1870s-1960s appearing as clear when no route is reserved through them and when they are on straight track); and (3) making sure that automatic signals cannot be placed before junctions (and working out what to do if somebody places one when it is not before a junction, then adds a junction ahead of it, or removes a signal that was formally between it and a junction). For all that coding effort (and effort to maintain it and debug it), it hardly seems worthwhile to have what would be an entirely cosmetic simulation of automatic signals.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

I'd like to add my 2 cents to this discussion, especially to 2-block (pre)-signals. I use them on some complex junctions and on overtaking loops. However many (if not all) uses on junctions could be avoided either by moving the signal further or closer to the junction, or - especially in case of single track lines, by allowing trains to pass signals in the "wrong" direction. I think if you start some deep recoding of signals, that this should be considered as well. Signals facing only one direction, should affect only trains that can see them, and the other direction should be clear, not blocked as it is now.

jamespetts

If that were done, then there would need to be some other means of having unidirectional rail lines.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Quote from: jamespetts on May 12, 2013, 06:05:59 PM
If that were done, then there would need to be some other means of having unidirectional rail lines.
A one-way sign is already available. I think that would be enough.

jamespetts

Yes, in principle, but two slight problems would need to be considered: (1) no such sign exists in actual railway practice (to my knowledge, at least), so we need to consider how graphically to represent this; and (2) it would make extra work for users to add on every line.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Yes, there are no one-way sings. But there are permanent stop signals, that can be used. They are usually at dead end, so they cannot be approached from the other side, but for the need in simutrans thay could be fine. Like this one: http://foto.masinky.info/uploads/foto.masinky.info/Navestidla%20AZD/img/P8110024.JPG

What I have observed on czech railroads is that on double track lines, there are signals that face both directions, but the lights are off on the "wrong" direction. Check the images here: http://forum.msts.cz/showthread.php?pid=113249

They show the same place from both directions - traffic is on the right, so you can see the signal light on the rightmost signal. Leftmost signal is turned off - as it is facing the wrong direction. Ignore the middle signal - it is marked by white X which means "this signal is out of service or broken - just ignore it." The rule here is that if the train driver comes to a signal that is off (and does not have the white X) - he has to stop the train, and ask for permission by phone (which is supposed to be nearby).

So what about this proposal: Instead of having three states of signals - left, right and both directions, we could have two more states - left on + right off, and vice versa. If the signal is only on one side - it can be passed in opposite direction. If it is on both sides, one side could be switched off - meaning one way track.

Erik

About the one way signaling.
These don't really exist on the way we use, but here in the Netherlands we have a sign for closed tracks.


The possibility to pass a signal from the "wrong" direction could be quite nice in some situations.

Quote from: jamespetts on May 12, 2013, 06:34:20 PM
Yes, in principle, but two slight problems would need to be considered: (1) no such sign exists in actual railway practice (to my knowledge, at least), so we need to consider how graphically to represent this; and (2) it would make extra work for users to add on every line.
A solution is to build a signal with the one way signal implemented. It is already partially implemented in the writer and reader of the .pak files, but not in the rest of the Simutrans source.

About the default on green unless the is a junction or something behind it.
We don't need to make two types of signal for that. It's that a signal is green on default unless there is a junction behind it. Or something in this way.


jamespetts

I don't think that we can build signals with the one way sign integrated, can we - what function would the one way element have when the signal is bidirectional? We could, I suppose, use the limit of shunt designation in Pak128.Britain:


shunt-limit_p1350622 by iandh, on Flickr

QuoteSo what about this proposal: Instead of having three states of signals - left, right and both directions, we could have two more states - left on + right off, and vice versa. If the signal is only on one side - it can be passed in opposite direction. If it is on both sides, one side could be switched off - meaning one way track.

This is an interesting suggestion - but how would the signalling logic for it work?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Hello! Being a silent reader of this forum for some years and have played Experiemental most of them! Lovely game! Thank you all for creating it! :-)
I have followed the discussions in here with big interest and I just have to throw in a question:

Most railways are either left hand traffic or right hand traffic. What if it the train was smart and automatically was able to "keep right"?

For instance, either when we are laying down the tracks, we somehow mark them with a tool as being a "pair of tracks" meaning it's one single route, or the train itself is able to calculate on the go that it can choose the right/left. Then it should be given some rules about when two tracks starting and stopping the same spot are seen as the same route or two different routes (if building singletracks in a circle).

Of cause junctions and bigger stations will still need some kind of players love......

Max-Max

Before I discovered Simutrans I played OpenTTD a lot!

In OpenTTD a one way signal don't block a train coming from behind, it is just ignored. There is a special signal blocking traffic from behind because OpenTTD don't have one way signs.

In Simutrans we could just add two more cycles when placing a signal giving us the following states:

  • Two way signal
  • One way signal blocking direction A
  • One way signal blocking direction B
  • One way signal non blocking direction A
  • One way signal non blocking direction B

In the dat file we add two more images and if those aren't define we skip the 2 last cycles.

Double tracks are in some countries used as bypass tracks if they are free, to allow faster express trains pass slower goods trains. For this a double way signal is needed and in some cases minor single signals will be facing the wrong way but ignored. The track section is in this case reserved by other signals in advance (like long block signals facing the wrong way). In those cases a train must be allowed to pass a single signal facing the wrong way.
- My code doesn't have bugs. It develops random features...

jamespetts

ViolinVictor- welcome to the forums! Glad that you find Experimental a worthwhile thing to play.

The keep left/keep right idea is an interesting one, but one with some considerable difficulties - what exactly counts as left/right when there are diverging tracks, or four track sections (which may be paired by use or by direction), or where there is a three track section, or a freight loop?

Max-Max - that idea might be workable; but how would we indicate to the players which are the blocking signals without every pakset author having to produce lots more graphics (and what would the graphics look like anyway)?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Max-Max

#118
What the signal should look like is something for the PAK designer to decide. A common style in OpenTTD for a one-way-signal can be seen in the attached picture. (A) are blocking one way signals while (B) are non-blocking one way signals (allowing trains to pass from behind).

Usually you only need one of those in intersections to prevent a train to enter the track from behind.

I do suggest that you try OpenTTD. Their signals are more intuitive to set up and I found them very easy to work with. Simutrans signals took me a while to understand while OpenTTD signals took a few minutes :)

Backward compatibilities are always a drag, but sometimes you just need to announce a change that will need some modifications. Another way to handle it would be to treat a signal as blocking if there is no blocking signal defined (missing image).

...or we can define a new signal and add always_2way=1 in the dat file to indicate a non blocking signal. This will not break the already compiled PAK files.
- My code doesn't have bugs. It develops random features...

Max-Max

Another problem I just had can be seen in this image.
Train (A) is waiting for a 100% load while train (B) only needs to pas train (A). For some reason the chose signal at (B) has decided to route train (B) through the same platform as train (A), even if there is a free path beside it all the way up to its designated destination.

Is this a known bug, or intended behaviour?
- My code doesn't have bugs. It develops random features...

Ves

Thanks James!

Even at present in simutrans, you would have some kind of "playerinterrupts" when you are making a 3-, 4-, 5-, 6-, X-track line. In a 6-track situation, the player could either mark it as three different lines, or the player could mark them as one line. The train itself chooses when more than one track available in one way, for instance always the innerpair which then have a condition, so the trains not allowed will have to make the outer pair. if no condition, the outer pair would not be used, as all trains would seek to the innerpair.

In a three track situation, you would then mark one in one way and the two others the other way and the action described above would appear on the dubble-oneway. The solution to not let you just mark three tracks become one line and not tell what to do with the third track, would be that the line-marker always mark tracks in pairs. Of cause you would have the option to select the last one after the pair of track has been made.

When the tracks are diverging, they would simply become two singlelines. If they are running parallel for a moment with a junction before divergion, that little section could be made a dubbleline, if not, they would count as two singlelines from beginning. At least if you are not marking them as a dubbleline.

The problem with automation is that all the worlds tracklines have been carefully designed to fit exactly their needs and possibilities. So also the player in simutrans. :)

prissi

This signals of OpenTTD are a nightmare ... They are a mixture of block and path based signals hacked together for compatibility reasons are source for most questions in the forum. You can do logics with them, but only because OpenTTD handles tracks differently. If you want OpenTTDs signalling, it would make sense to use OpenTTD, because to fully emulate them in simutrans, you would also need OpenTTDs track system. Rather add proper tunnels and bridges to OpenTTD, I would say.

Max-Max

OpenTTD was a reflection and I didn't say we should implement OpenTTD signals, the topic was about having a non-blocking signal where trains can pass from behind. Such signal do exist in OpenTTD and James wanted to know what a such signal may look like.
- My code doesn't have bugs. It develops random features...

prissi

In OpenTTD there are non no-blocking signals. See http://wiki.openttd.org/Signals Instead the trains start a route search at every switch or signal. But I get what you mean.

Erik

A signal who could be passed from the "wrong" direction is just something we could try and see how it will fit.
That actually count for many ideas.

Quote from: Max-Max on May 13, 2013, 12:01:17 AM
Another problem I just had can be seen in this image.
Train (A) is waiting for a 100% load while train (B) only needs to pas train (A). For some reason the chose signal at (B) has decided to route train (B) through the same platform as train (A), even if there is a free path beside it all the way up to its designated destination.

Is this a known bug, or intended behaviour?

It's a known behaviour. The chose signals are only working to direct a train to a free platform of the station at destination.


merry

#125
HI guys,

I'd very much support the provision of 'non-blocking' signals, which (as IRL) are ignored by a train approaching from the other direction. I believe this would offer much more sensible junction design, when used in conjunctoin with a 'no entry' signal (such as James' Limit of Shunt' example, which I have thought of previously in this discussion.

The most common use would be at a point where two bi-directional single lines combine and become a double track (1 line each way). At present, best capacity requires a 2-block signal at the end of the double track and a both-ways single block signal on the start of each single track, to avoid deadlocks.  but I can think of plenty of other uses, especially if the implicit signal at the end of each platform (but only for stopping trains) is considered.

Regarding backwards compatibility of savegames, it would be necessary to continue to keep the current behaviour & add in the non-blocking' signal. This seems to be a de-facto convention for ST, and to be honest it is the only choice if we are not to break every existing game. I shudder to think how much work would be required to 'fix' a large rail network otherwise!

And now... <pedantic=1>
@Vladki (and others!): Can I ask you to avoid use of the terms 'on' and 'off'. It caused me some headache to understand at first reading!
Explanation: In railway signalling (at least in the UK), the terms have very specific meanings. 'On' means a signal showing a danger (or it's most restrictive) aspect. 'Off' means a signal showing any less restrictive aspect. Yes, I know it's a bit counter-intuitive if you think of light switches, but this terminology was coined way before electric light was common...
BTW 'Wrong' is used to describe any unclear or incorrect aspect, e.g. an arm that is ambiguously positioned. 'Dark' is a common way to describe a signal that shows no indication (which can be by design, or a fault), but beware that in the USA 'DArk territory' is rail line not under the control of a signaller & using some other form of 'safety' control <shudder>. There's a reason we abolished time-interval working over a century ago. OK, I digress, back to the topic!
</pedantic>

Great to see such a discussion, I think I first suggested something like this some 3-5 years ago, but of course times change...Experimental is the place fro trying things out - thanks James !

Who knows, maybe we'll get cut-and-cover tunnels one day...
Cheers,
Merry

jamespetts

Thank you all for the useful contributions to this discussion - most worthwhile. Should we, I wonder, change the topic of this thread again to "Signalling"? "Distant signals" seems too specific now.

If we are to have unidirectional signals that can be passed in both directions, which is not a bad idea in principle, we need to make sure firs that there is a coherent means of implementing this feature in the GUI to make it clear to players what is happening, and also to make it easy for players to implement single directional working where appropriate. Special regard will have to be had as to how these solutions fit in with the automatic signal placement tool, which currently places a row of unidirectional signals when dragged along the track, which also has the useful effect of making the track unidirectional. We do not want to make it more difficult for players to achieve the same basic effect if we can help it.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

HDomos

Quote from: jamespetts on May 15, 2013, 10:02:18 PM
Thank you all for the useful contributions to this discussion - most worthwhile. Should we, I wonder, change the topic of this thread again to "Signalling"? "Distant signals" seems too specific now.

If we are to have unidirectional signals that can be passed in both directions, which is not a bad idea in principle, we need to make sure firs that there is a coherent means of implementing this feature in the GUI to make it clear to players what is happening, and also to make it easy for players to implement single directional working where appropriate. Special regard will have to be had as to how these solutions fit in with the automatic signal placement tool, which currently places a row of unidirectional signals when dragged along the track, which also has the useful effect of making the track unidirectional. We do not want to make it more difficult for players to achieve the same basic effect if we can help it.

Hi,

I support these non blocking signals, they can be a help in a lot of places, especially in complex junctions. About the automatic signal placing, there is already a popup window where you can set the distance between the signals, and there are already checkboxes in it... You can simply add a checkbox to this window, where the user can decide if he wants too build blocking or non-blocking signals :)

Erik

Possible, but I think it's too hidden.
I'm thinking more of a extra signal. Put the normal signal as the non blocking and the other signal as a new one.
I don't know how hard backwards compatibility will be. On the old save files the normal signal has to be loaded as the new blocking signal. Also it's of course preferable that a train prefers the direction of the signal when it is possible. So that has also to be implemented in the route search.


sdog

Quote from: Vladki on May 12, 2013, 07:30:57 PM
Yes, there are no one-way sings. But there are permanent stop signals, that can be used. They are usually at dead end, so they cannot be approached from the other side, but for the need in simutrans thay could be fine. Like this one: http://foto.masinky.info/uploads/foto.masinky.info/Navestidla%20AZD/img/P8110024.JPG

What I have observed on czech railroads is that on double track lines, there are signals that face both directions, but the lights are off on the "wrong" direction. Check the images here: http://forum.msts.cz/showthread.php?pid=113249

They show the same place from both directions - traffic is on the right, so you can see the signal light on the rightmost signal. Leftmost signal is turned off - as it is facing the wrong direction. Ignore the middle signal - it is marked by white X which means "this signal is out of service or broken - just ignore it." The rule here is that if the train driver comes to a signal that is off (and does not have the white X) - he has to stop the train, and ask for permission by phone (which is supposed to be nearby).

So what about this proposal: Instead of having three states of signals - left, right and both directions, we could have two more states - left on + right off, and vice versa. If the signal is only on one side - it can be passed in opposite direction. If it is on both sides, one side could be switched off - meaning one way track.

A very, very, very BIG  plus!

jamespetts

There seems to be much support for the idea of single directional signals that can be passed in the opposite direction - we just need a clear and easy UI design for them, I think.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

sdog

#131
How could it be implementd? Blocks would have different length, depending on direction, or rather blocks would be linked for one direction, but not the other.

UI: double directional signals, one is always set to red/danger/don't enter. Icon solves rest through pictogram. Single direction signals would not have any extra description and would be the standard. bi-directional would get two parallel arrows, opposing direction, one-way signals would get one arrow that passes, the other is blocked by a pair of 'flashing' lights

*<-
  ->*

prissi

How would a signal showing one side red other side green (entire possible even now) be different gamewise from the current behavior? It would still act as a signal.

Of course on can go all the way like roads, i.e. separate single direction from signals. THat is probably the best way to communicate it to the use.

However, I still have to see in real life a track which was regularly gone against the signals respective used different block lengths for backwards and forward directions. (Not counting construction works.)

ӔO

sometimes bi-directional tracks may be used for overtaking, although this usually only happens when a train is running behind schedule and requires special permission from control.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Erik

A signal just beyond a junction is just not practical. Because the train will block that junction when it's waiting for that signal. From the other direction it could be useful because the train has to get a free sign trough that junction. In real life you will see this also.

It isn't about fluctuating block sizes. (Some things are the responsibility of the player.)


Vladki

Quote from: prissi on May 17, 2013, 02:05:51 PM
However, I still have to see in real life a track which was regularly gone against the signals respective used different block lengths for backwards and forward directions. (Not counting construction works.)
Any single track line wold do. Usually there is an unidirectional signal in front of the station - facing the trains that approach the station, and showing if they can enter the station. Trains leaving the station see the back of this signal and obviously ignore it.

And there are signals at the end of platforms in stations (in real life), that tell if the train can leave the station - also unidirectional. The implicit station signals in simutrans work just like that, but only for trains that stop in the station.

Back to the block length. Currently a bidirectional signals are on opposite borders of one tile, so blocks in opposite directions overlap by one tile. In case of non-blocking unidirecional signals blocks would overlap by arbitrary amount of tiles - typically the whole part of track betweeen stations, or the whole platform.

@merry: I'm sorry for my bad English, I have not studied the jargon used by railway staff ;)

Ves

In the case of doubblefaced signals, why? Why would it not be applicable to put one signal facing one way, and then another signal facing the other way (on the same track of cause)?. What if the signal instead of black and white prohibits or allows traffic from travel the other way, instead just permits traffic the way the signal is facing.. if you put a signal facing one way on a singletrack, traffic would only be allowed to drive, seeing the face of the signal. If you then put a signal (or another special sign) the other way, traffic would be allowed to travel the other direction as well. If no signal is used, the traffic will just book the whole line till next stop or signal.

In this way, it would be easier to build bidirectional lines without having to have a multiple set of signals that allows traffic in the 'wrong' direction or not, and you would also be rid of the other solutions with dussins of onewaysignals.

In other words: Only onewaysignals which in default deny travel in the other direction, until a signal (or a sign) is put, faced the other direction. The two signals would then cancel the other signals 'deny'.