The International Simutrans Forum

Simutrans Extended => Simutrans-Extended development => Topic started by: Erik on March 26, 2011, 10:32:13 PM

Title: Distant signals
Post by: Erik on March 26, 2011, 10:32:13 PM
Hey everyone I have made a new signal who let slowdown the train if the next signal is (keeps) red.
This is to prevent that a faster train after a slower train has stop and pull up all over again.

Some part of the code are a bit ugly and I working on it to make ik more smooth.
But for that I have to rewrite the whole part of the "block_reserver".
So that would take a while.

On the attachment I have put the .patch and the signal.

Try it  ;)
Title: Re: [Patch] announce signal
Post by: Erik on April 16, 2011, 12:49:19 PM
I have resolved the ugly part of the code I've build.
It wasn't needed to rewriting the whole block_reserver.

What I have done now is quiet similar to something I had already tried.
But is seems I has somewhere made a mistake.

I hope I can make the new patch soon.
EDIT: patch has been made from source r4397. :D
Unfortunately it's not directly compatible with the previous patch.
So remove (unpatch) the previous one and then use this patch.

(I hope also I have made a better type op patch.)
Title: Re: [Patch] announce signal
Post by: paco_m on May 10, 2011, 05:37:28 PM
Nice thing, this is more ore less the way how real presignals work ;)
Title: Re: [Patch] announce signal
Post by: Erik on May 10, 2011, 06:40:32 PM
Thanks, that's why I build it.  :D
I hope it will be implement soon.

Actually I wand also to rebuild a big part of the signals to make it more real.
But this would be a big patch, where waiting one whole month is too long.
Title: Re: [Patch] announce signal
Post by: jamespetts on May 10, 2011, 10:11:05 PM
Quote from: Erik on May 10, 2011, 06:40:32 PM
Actually I wand also to rebuild a big part of the signals to make it more real.

What had you hoped to change?
Title: Re: [Patch] announce signal
Post by: Erik on May 11, 2011, 10:19:25 AM
A few points.

- Seperate the different vehicle types in different files. It will blown all existing patches as it is now, but it will be much more clarifying to work on it in the future. (This one is fast done, but can't wait one month for implement. Becouse it will blown all the changes made in that month.)

- To make the signals reserve till the next signal before the next crossing if the whole track is free. It has a few advantages.
- With the previous one, make it possible that a faster train takes a track parallel to pass the slower one. Also useful on very busy tracks.
- Prevent traffic jam on the track. This would be the hardest one and jet I don't see exactly how it can be done.
Title: Re: [Patch] announce signal
Post by: Dwachs on May 11, 2011, 10:52:46 AM
Erik, am I right that the only differences to simutrans-standard-classic presignal are (1) check max 2 blocks and (2) speed limit?
Title: Re: [Patch] announce signal
Post by: Erik on May 11, 2011, 11:04:32 AM
Yes,
(1) check max 2 blocks and not more.
(2) If it could only check one block, it gives a speed limit.
Title: Re: [Patch] announce signal
Post by: prissi on May 15, 2011, 07:16:59 PM
But then you would need a real two block signal, since this is needed in certain situations.
Title: Re: [Patch] announce signal
Post by: Erik on May 16, 2011, 09:42:01 PM
Yes, that is one of the changes who I have made and put it in the patch.
Title: Re: [Patch] announce signal
Post by: VS on October 15, 2011, 04:47:04 PM
Did this... umm... resolve in any way? It looks like the thread died without any result or a clear "no".
Title: Re: [Patch] announce signal
Post by: Erik on October 15, 2011, 06:05:33 PM
At the moment I'm not working on it.
I know all patches are broken by now.  :-[

With the little time I have I'm working on rebuilding of the ns-pak set.

After that, I will go further with this.  ;)
Perhaps even rebuild the whole way that the signals are working now.
Title: Re: [Patch] announce signal
Post by: Max-Max on May 01, 2013, 05:02:46 PM
While you are at it I may suggest the following:

1) A real pre-signal also shows at what speed the train should proceed with and never stops a train. In Sweden there are 2 kind of speeds; 80 and 40 (http://en.wikipedia.org/wiki/Swedish_railway_signalling)
2) A real main signal may be combined with a pre-signal.
3) Pre-signals for road crossing.


1) This would be a new signal type in simutrans and could be implemented by setting is_presignal to the maximum speed to proceed with in case of red light at next signal. This signal will never stop a train. To make it simple, just allow one speed.

2) This could be an extension of the existing main signal by adding both is_signal=1 and is_presignal=60 (for example max 60km/h). As long the main signal is green the train will pass, if the pre-signal is activated (next block red) it will pass at the pre-signal speed. For this we need more images in the main-signal graphics and we can keep it simple by only allowing one pre-signal speed.

3) This has to be a new type that shows if the next road crossing signals shows stop for traffic. This signal shows red if crossing traffic is allowed to pass and white light if it is safe for the train to pass.

To further elaborate a normal engine will proceed with the pre-signal speed to the next signal, even if the status changes. If we expand the engines to have an ATC parameter, those can go up to full speed as soon the next signal shows green.
Title: Re: [Patch] announce signal
Post by: jamespetts on May 01, 2013, 05:06:01 PM
Sadly, since the last post in this topic was in October 2011, I rather doubt that Erik is any longer at it. Adding realism to the signalling is somewhere in my long queue of things to do for Experimental one day, though.
Title: Re: [Patch] announce signal
Post by: Max-Max on May 01, 2013, 05:11:25 PM
I happen to have all the time in the world right now, but I'm not familiar with the code design to do this on my own. My German really sucks too, so I'm having difficulties to read the code as well.

Although I would e happy to try with some guidance.
Title: Re: [Patch] announce signal
Post by: jamespetts on May 01, 2013, 05:22:46 PM
I see! Interesting. What I was planning to do is something that interacts very specifically with the code for braking distances in Experimental: have a look at the "railway signalling" section in this (http://forum.simutrans.com/index.php?topic=8172.0) post. The basic idea is to have proper pre-signals ("distant signals" in UK nomenclature) and a sighting distance for signals, so that trains must travel within the speed that allows them to stop (according to their braking ability) within the sighting distance of the next signal that might be at danger, as well as multiple-aspect signals (signals that can be distant and stop signals at once). The idea is that a train driver would be presumed to know where the next signal is, but not the aspect that it is showing except by what has been indicated by a previous signal, until that signal is close enough to come within that train's sighting distance.

I had also planned to implement a system requiring railway signals to be placed within the coverage radius of a new type of signal box object, for such signal boxes to have a monthly maintenance cost, and be able to support a limited number of signals (depending on settings in their .dat files; for example, a small ground frame signal box might support six signals, a medium sized lever frame type might support 12 signals, and so forth) and to require that signals be of a compatible type to the signal box (e.g., semaphore signals for a lever frame box, colour light signals for a power signal box).

I had also considered implementing systems other than absolute block, including moving block, drive by sight (the code for the former two could be essentially the same, as drive by sight is in effect a crude form of moving block signalling that works at low speed: it is mainly used for trams) and radio electric token block (the signal boxes in that case would have an extremely wide catchment area, but the trains would have to stop at every "signal" (sign board/radio post) before continuing).

Are you interested in implementing any of this? If so, I can provide assistance as to how to find the relevant parts in the code and what sort of things need to be done (I can say now that most of the relevant parts of the code will be in route.cc, simvehikel.cc and simconvoi.cc).
Title: Re: [Patch] announce signal
Post by: Max-Max on May 01, 2013, 05:28:59 PM
Well I will try to read through the code to see if I can get an idea of how to code this. I guess a first step would be to have a pre-signal to limit speed and then work from there.

A silly question: What is the difference between the experimental and the standard version? Are the Experimental transitioned over to teh Standard when Stable? (like an RC version?).
Title: Re: [Patch] announce signal
Post by: Erik on May 01, 2013, 05:36:00 PM
Sorry, I know.
I'm a bit off line the last two years. (First full job, looking for a house, etc.)
I didn't get much time to it.

Also I discovered my programing skills weren't sufficient enough. So for the last year also there I was working on. (Far as I did get the time for it.)

Quote from: Max-Max on May 01, 2013, 05:11:25 PM
I happen to have all the time in the world right now, but I'm not familiar with the code design to do this on my own. My German really sucks too, so I'm having difficulties to read the code as well.

Although I would be happy to try with some guidance.
Exactly also my point. Perhaps I can start over again and we work together?

O, for I forget. The correct English name is distance signal.
Title: Re: [Patch] announce signal
Post by: Max-Max on May 01, 2013, 05:42:17 PM
Erik, where are you located, Holland?

I'm in Sweden and sure we can work together on this. Are we doing this in the Standard code base? Can we reuse your old code or do we need to design this all over again?

I guess we first need to agree on a road map for this and make some design strategies.
Title: Re: [Patch] announce signal
Post by: jamespetts on May 01, 2013, 05:44:42 PM
Erik - welcome back! Simutrans does require some fairly complicated coding, which is not always easy for a new coder; but I knew very little about C++ when I started, so it is not impossible (but does take a lot of work to get up to speed).

Max-Max - have a look at the Simutrans Experimental FAQ (http://forum.simutrans.com/index.php?topic=9184.0). In general terms, Experimental is a permanent fork with a (slightly) different design philosophy to Standard, focussing more on detail and realism, whilst Standard focusses more on good performance on limited platforms and gameplay simplicity. For that reason, in a number of respects, the code has diverged from Standard quite significantly, although in other areas (graphics processing, for example, and many low-level operations), it is identical. Most of the code from Experimental is identical to that in Standard, but there are number of quite important differences (see the FAQ and the posts linked there for more details). The most relevant difference for signalling purposes is the simulation of braking physics.
Title: Re: [Patch] announce signal
Post by: Max-Max on May 01, 2013, 05:54:01 PM
Allright, I'm installing GitHub for Windows now and will see if I can compile and run the game. I need to play around a bit with it to understand the new game mechanism...
Title: Re: [Patch] announce signal
Post by: Erik on May 01, 2013, 05:55:17 PM
Yes, I'm from the Netherlands and also from the province North-Holland.
I think it's best if we use the Experimental source.
I do like the Experimental pak very well.

About my old source code. I'm afraid it is mostly useless.
Title: Re: [Patch] announce signal
Post by: jamespetts on May 01, 2013, 07:37:39 PM
Do let me know either of you if you have any queries about the Experimental specific aspects of the code, or the general layout (although I am afraid that I cannot much assist in relation to the details of the code from Standard in most cases).
Title: Re: [Patch] announce signal
Post by: Max-Max on May 01, 2013, 09:07:43 PM
Okay, I pulled the source from GitHub, added the external libs as I did for standard edition and compiled. I used the files from Simutrans-Experimental-Complete.zip to get the structure and PAK128.Britain-Ex-0.8.3.

Dropped in my compiled .exe but when I start i get the message "Fatal ERROR: vehicle_reader_t::read_node() - Do not know how to handle version=18184 Aborting program execution ..."

The .exe file that came with the zip works fine so it must be something VC settings that isn't right.

Any ideas what this might be?
Title: Re: [Patch] announce signal
Post by: jamespetts on May 01, 2013, 09:15:45 PM
Hmm - very odd. The number 18184 is entirely spurious, as the version number there should be in the single digits. Which Github branch are you using?
Title: Re: [Patch] announce signal
Post by: Max-Max on May 01, 2013, 09:33:22 PM
I used the Master branch... wait there is one more "Experimental" =)

Okay I will try again...
Title: Re: [Patch] announce signal
Post by: jamespetts on May 01, 2013, 09:36:01 PM
Which Github repository are you using? This (https://github.com/jamespetts/simutrans-experimental) is my repository, and this (https://github.com/jamespetts/simutrans-experimental/tree/112.x-private-car-merge) is the branch with the latest code on it (which will form part of the next release version).
Title: Re: [Patch] announce signal
Post by: Max-Max on May 01, 2013, 09:42:59 PM
That was a different one :)

Okay, I will clean up and begin fresh again...
Should I use the second link to the "latest code on it..." ?
Title: Re: [Patch] announce signal
Post by: Max-Max on May 01, 2013, 09:46:14 PM
jamespetts and Erik,

I sent you my contact info in a PM.

Erik I have received yours, thank you.
Title: Re: [Patch] announce signal
Post by: Max-Max on May 01, 2013, 10:09:25 PM
Okay I got it to compile and the Executable works :)
Title: Re: [Patch] announce signal
Post by: jamespetts on May 01, 2013, 10:11:50 PM
Yes, indeed, do use the link with the latest code, as that is the code base that will become the next major version release in due course. Perhaps we could start a separate discussion as to the detailed implementation on the Simutrans-Experiemental development forum?

Incidentally, you might want to create your own GitHub repository with a specific branch for this project, with the master version being synchronised with the latest version on my repository.

As to the warnings, many of those are also present in standard (especially the signed/unsigned integer warnings).
Title: Re: [Patch] announce signal
Post by: Max-Max on May 01, 2013, 10:14:08 PM
But I got 555 warnings!!! (no errors although)...

I would estimate that about 95% of them are:

warning C4373: 'wkz_lower_t::get_tooltip': virtual function overrides 'werkzeug_t::get_tooltip', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers...

...and there are some conversion warnings like float to const int.
Title: Re: [Patch] announce signal
Post by: jamespetts on May 01, 2013, 10:24:36 PM
That particular one arises in Standard code, as I suspect that the rest do, and are probably nothing to worry about.
Title: Re: [Patch] announce signal
Post by: prissi on May 02, 2013, 09:49:07 PM
The are indeed to worry about, as virtual const char *xz cannot be overlaid by char *cz, be first one would not be called on many compilers. I do not get those warnings in standard, so those are not from standard. Rather a definition has missing a const I suspect.

What I get are float in int warnings (or sint64 in sint32 and the like) one volatile is ignored. But then I use MSVC 2010 or mingw GCC 3.4.5
Title: Re: [Patch] announce signal
Post by: Ters on May 03, 2013, 04:57:55 AM
I checked werkzeug_t::get_tooltip in standard, and there is some slight difference in const. The warnings are therefore valid for standard as well. Raise, lower and similar tools for some reason declare a constant pointer to constant spieler_t, while werkzeug_t only declares a non-constant pointer to constant spieler_t. Ironically, the warning applies to the compilers that don't emit the warnings, the compiler that spits out the warning does the right thing, or so I understand it.
Title: Re: [Patch] announce signal
Post by: jamespetts on May 03, 2013, 07:56:27 AM
Interesting. Which of the two tool types is correct?
Title: Re: [Patch] announce signal
Post by: Dwachs on May 03, 2013, 10:19:11 AM
This is a warning of Microsoft program to warn users that their compiler now COMPLIES to the standard ^^

See:

http://code.google.com/p/googlemock/wiki/FrequentlyAskedQuestions#MSVC_gives_me_warning_C4301_or_C4373_when_I_define_a_mock_method
Title: Re: [Patch] announce signal
Post by: jamespetts on May 03, 2013, 10:54:57 PM
Warnings aside for the moment, one of the other things that improving the signalling needs to do is only letting a train pass a signal into a section in which a level crossing is located when that crossing is clear and blocked to road traffic.

For more information on real life signalling, see here (http://www.signalbox.org/).

Edit: Incidentally, if you have decided to do this in Experimental, I should move this to the Experimental development board. Can I confirm before I do that that that is your intention?
Title: Re: [Patch] announce signal
Post by: Max-Max on May 03, 2013, 11:51:30 PM
It seems like there is no interest for this in the standard, so I will have a look in the Experimental code together with Erik.
Title: Re: [Patch] announce signal
Post by: jamespetts on May 04, 2013, 12:32:39 AM
Splendid - thank you for letting me know. Now that we have confirmed that this is being designed for Experimental, we shall need to make sure that we are all pulling in the same direction before coding work starts. A brief checklist to ensure that we are on the same page so far - are we doing:

* absolute block signalling incorporating Experimental's braking distances;
* multiple aspect signalling (including four aspect signalling with its double caution aspect meaning that the signal after next is at danger);
* proper signal control of level crossings;
* signal boxes (as described above);
* other types of signalling, such as drive on sight, moving block, and radio electric token block?
Title: Re: [Patch] announce signal
Post by: Max-Max on May 04, 2013, 12:42:05 AM
I was thinking to start with the pre-signal (I know it isn't the right term but easier for me to write and remember :)

First approach I would like to look at is to have a pre-signal to react on the next block's status.
I guess the next step after that would be to use the is_presignal value (>1) as the new speed limit.

So if you could explain to me a bit how the block reservation works.

How does a signal know the status of its own block?
How does it get updated if the block status changes?
How can a signal access a block's status of the following block(s)?
Title: Re: [Patch] announce signal
Post by: jamespetts on May 04, 2013, 02:33:30 AM
Ahh, we need something a little more sophisticated for the speed limit. What we need is a signal sighting distance combined with the convoy's braking distance to produce a bespoke calculated speed limit for every situation. Assume the following line, where "t" is a train, "D" is a distant signal and "S" is a stop signal, and coloured dashes (---) indicate track reserved by the train:

----t--------D----------S-------

Suppose that the signal sighting distance is 250m (see this (http://www.atsb.gov.au/media/51281/RO2008003.pdf) Australian accident report which gives a similar figure). (This value would be set in the signal's .dat file).

The train approaching the distant signal would know that there is a distant signal ahead and how far away that that signal is (because the driver would have learnt the route, or would have a route map in the cab correlating with mileposts on the track) from the beginning, but would not know what aspect that that signal was showing until it gets within (say) 250m of that signal.

Because it is a distant signal, the driver knows that the train will not ever be required to stop at that signal, but will be required to stop at the next stop signal. So, the fastest that a train can go at any given point before 250m before the distant signal is whatever the maximum speed is for stopping in time for the next stop signal. This speed will obviously decrease as the train gets closer to the next stop signal. If the distant signal is far away enough from the stop signal, however, that signalling maximum speed will still be higher than the train's actual maximum speed right up until it gets to within the sighting distance of the distant signal.

Once it gets to within sighting distance of the distant signal:

-----------t-D----------S-------

the aspect of that signal, and therefore the next stop signal, is revealed. In game terms, this means that, at that point, the game must attempt to reserve a block beyond the next stop signal to the stop signal (or possibly station platform - we probably also need to have a discussion about whether to abolish the behaviour of station platforms behaving as signals, and, if so, how to do that, because it will be tricky). It should be noted that there must already have been a block reserved to the next stop signal (i.e., beyond the immediate distant signal) for the train to have got where it is already.

If, on entering sighting distance of the distant signal, the train is able to reserve a block on to the next stop signal, then the distant signal will need to be set to clear along with the next stop signal:

-----------t-D----------S------------D-----------------S-------

The train's maximum signalling speed is now the maximum speed to stop in time for the next stop signal but one, which may well be be far in excess of the train's maximum speed for a long time, unless the signals are close together or the train is travelling very fast (in which case four aspect signalling may be needed to allow the train to run at its maximum speed).

If, however, on entering sighting distance of the distant signal, a block cannot be reserved from the next stop signal to the one beyond it, then the distant signal should remain at caution and the stop signal at danger:

-----------t-D----------S------------D-----------------S-------

The train will then be able to go no faster than the maximum speed that would allow it to stop for the next stop signal (which, of course, will gradually reduce to zero as it gets to the next stop signal). Once it has passed the distant signal, it will have to continue at this reducing speed until it is within sighting distance of the next stop signal, even if in the meantime it would have been possible to reserve a route from the next stop signal to the one after it. Only when it gets within the sighting distance of that next stop signal (by which time it would be travelling slowly, enough to stop 250m or so ahead) would it re-check the block reservation and see whether it is able to obtain one to the next stop signal on its route:

-------------D--------t-S------------D-----------------S-------

It would, as now, keep re-checking that periodically until it succeeds. If it succeeds straight away, then the stop signal would clear, and the train would be able to accelerate again without stopping at all; otherwise, the train would have to come to a stand at the signal and wait for the route to clear. The route clearing here ought to include the closing of any level crossing gates, only after all the cars on them have left.

As to your specific questions, the idea of a "block" in Simutrans is not an exact representation of a block in conventional signalling practice. Instead, it consists merely of a route reservation from one signal to the next (press the "b" key when playing the game to see these route reservations in red). The signal does not know the status of a block, as there is no such thing, as such: it will register as clear when there is a route reserved through it to the next signal, and danger at all other times. Trains clear the reservation on a given tile as soon as they leave that tile.

Signals therefore cannot access the "status" of a succeeding block, as such, but can reserve a route through more than one signal, and set the status of the signals along the way. To implement four aspect colour light signalling, for example, a train on getting within sighting distance of a signal would trigger that signal attempting to reserve a route three signals ahead (assuming that all intermediate signals are also four aspect signals). If it is able to reserve all three blocks, then it will set itself to clear, the next signal to double caution and the one after that to single caution. If it is able to reserve only two blocks, it will set itself to double caution and the next signal to single caution. If it is able to reserve only one block, it will set itself to single caution. If it is not able to reserve any blocks at all, it would remain at its default state of danger. As each next signal is approached, the same checks would be performed so that a train would get a run of clear signals if the line ahead is clear. (See here (http://myweb.tiscali.co.uk/gansg/3-sigs/powersig.htm) for an explanation of multiple aspect signalling).

The current system in Experimental, incidentally, which differs from the system in Standard, takes into account braking distances, but assumes an infinite sighting distance, and does not therefore have the concept of a caution aspect. Trains on getting within a fixed distance of a signal will try to reserve as many blocks ahead as is necessary for it to go at its current speed and still be able to stop in time for the next signal. Trains know how far ahead that they have been able to reserve, and therefore where the next signal that is at danger is so that they can ensure that they do not travel at any given point at a speed in excess of the stopping distance to the next signal at danger. This basic mechanism should be retained, but added to it should be the specific refinements discussed above relating to sighting distances and distant signals (as well, in due course, as multiple aspect signals).

I hope that this helps so far!


Edit: One thing that I should add to this is that it will probably be necessary to try to obtain a route reservation some time before a train reaches the sighting distance of a signal, as obtaining a route reservation might not be instantaneous, especially if there is a crossing in the section. Care should be taken not to try to reserve a route too early, however, as this would result in unnecessary blockages and inefficiency. How many meters before a signal that a route reservation ought to be sought should probably be an adjustable parameter.
Title: Re: Distance signal
Post by: Erik on May 04, 2013, 07:22:15 AM
Some memory's are coming back about how I've build the previous announce signal. To make small steps I think also it is best if we start with the Distance/Pre-signal.

Before I can explain something abbout how the "block_reserver" is working, I've to check what has been changed about it. I just downloaded the source and if I compared it with a previous source code I've found some were in a map. The new code is twice as long.

P.s. I've changed the name of the topic to Distance signal. Since this is the correct name.
Title: Re: Distant signals
Post by: jamespetts on May 04, 2013, 11:45:32 AM
Erik,

firstly, the correct term is "distant" signal, not "distance" signal - I have changed the topic name accordingly. Secondly, thank you for your assistance with this. The new code to which you refer is that which I describe above relating to reserving multiple blocks based on the trains' stopping distance: you will be able to make use of much of that code when implementing a distant signal, as the part about calculating braking distances will be able to remain the same. You will just need to add code for signal sighting distances and advance warnings about the aspect of next signals.

One note of caution, however: adding code just for a simple distant signal without also adding multiple aspect signalling will not result in a fully playable outcome in modern times, because modern railways (with faster trains which accelerate more quickly) rely on multiple aspect signalling to maintain simultaneously high speed and high capacity, which is not possible with old-fashioned single aspect signalling. However, once you have a distant signal, multiple aspect signalling should be easy to add, as you just have to combine the functions of a distant and stop signal in one signal (for three aspect signals), and add a double distant function for the double yellow aspect of a four aspect signal.
Title: Re: Distant signals
Post by: Max-Max on May 04, 2013, 04:22:03 PM
I and GitHub are not getting along very well. I'm used to TortoiseSVN and to have all the tools right in the explorer. Are there a similar tool for GitHub? What I miss most is to easily spot what files have been changed, the update and version comparison tools.

Or are you suggesting that I checking the GitHub Checkout in my local SVN and handle it local?

James, we have to takes this in small steps. If we try to implement all of it at once we will probably end up with nothing. I think the first step would be to figure out what state a distant signal have at any given time. Then we work from there... Breaking distance is, as I see it, a "minor" adjustment when the main functionalities are in place.

Depending on how object oriented the code is it shouldn't be to hard to combine one main signal object and a distant signal object into a new combined main-distant object.

Erik,
Have a look and see if it rings any bells... If someone just can explain briefly how the the train is aware about its surrounding and what is driving the signals (call from the train?, system message?, tick interval?)
Title: Re: Distant signals
Post by: jamespetts on May 04, 2013, 04:51:01 PM
Sorry that you're having trouble with Github - have a look here (http://git-scm.com/downloads/guis) for a list of Git tools that give a GUI and, I think, comparison tools. I use this (http://msysgit.github.io/) one, which has the ability to show you what files that you have changed locally, as well as what files are changed (and, in each case, what the changes are) on any given branch. As for tutorials, you could try this (http://nathanj.github.io/gitguide/tour.html) for Git for Windows, or have a look at one of these (http://sixrevisions.com/resources/git-tutorials-beginners/).

As to braking distances, because that is already implemented for stop signals, it'd be easier to make it work that way with distant signals than take out all the braking distance code and start again (and doing so would also be a step backwards, not forwards). All that you need to do is introduce a signal sighting distance and the idea of signal aspects that inform the train that the track is clear up to the stop signal after next (or the one after that for four aspect signals), and of course that reserve the track that far ahead. I am not sure how you would do it otherwise; certainly, not working with the breaking distance code already present would mean doing as much if not more work later to get it to work that way as it would take to get it to work that way now, on top of the work that it would take to make a distant signal somehow work a different way now.

Edit: Incidentally, you need to be looking at bool waggon_t::is_weg_frei_signal( uint16 next_block, int &restart_speed ) in simvehikel.cc as a place to start to understand the signalling code.
Title: Re: Distant signals
Post by: Max-Max on May 04, 2013, 08:03:17 PM
Thanks, I will have a look...
Title: Re: Distant signals
Post by: isidoro on May 05, 2013, 12:45:10 AM
After reading this topic, I have some questions about it:
The point is that in a RL situation, a distant signal placed wrongly (too near to the next one for the driver to be able to react) may cause an accident.  But that doesn't happen in ST, does it?

Title: Re: Distant signals
Post by: jamespetts on May 05, 2013, 10:53:40 AM
1. The trains will have to travel slowly enough that, when they reach the distant signal, they will be able to stop in time for the next stop signal. The code in Experimental already provides for trains to count backwards from the next signal at which they must stop (which is at danger) and begin to brake in advance of it as early as is necessary. Adding distant signals just involves adapting this code so that trains always assume that signals ahead are at danger until they get within sighting distance of them, unless they have passed a clear distant (or multiple aspect) signal, in which case they know that the next (or, in the case of a four aspect signal at clear, next and second next) (stop) signals are at clear.

2. This is not applicable in light of the above.

In real life, the spacing between distant signals and stop signals (or between different multiple aspect signals) together with the expected braking performance of trains would determine the maximum speed limit of that section. Where the speed limit is low in any event (if there are sharp corners, or the line is used mostly by trains that would not be travelling fast, such as local stopping services), signals are spaced closely together; on faster track, the signals are spaced further apart (and, to increase capacity, four aspect signals used in modern times).

The point of all this is to reflect the real life relationship between signal placement and track capacity/speed. The idea of having signal boxes with a limited number of signals each and a limited coverage radius is to simulate the practice in times gone passed of clustering signals around stations (which would have had signal boxes), and only putting signals between stations (entailing an extra, small signal box controlling perhaps four to six signals) where traffic demanded it (usually, on the principal lines), a practice which was displaced in modern times by having strings of evenly spaced multiple aspect colour light signals over the whole network, controlled from centralised power signal boxes at far fewer locations. It should also require players periodically to re-signal their lines as technology evolves and train speed increases.
Title: Re: Distant signals
Post by: eipi on May 05, 2013, 12:32:57 PM
Quote from: Max-Max on May 04, 2013, 04:22:03 PM
I and GitHub are not getting along very well. I'm used to TortoiseSVN and to have all the tools right in the explorer. Are there a similar tool for GitHub? What I miss most is to easily spot what files have been changed, the update and version comparison tools.

There's also TortoiseGit, available at http://code.google.com/p/tortoisegit/ (http://code.google.com/p/tortoisegit/).
Title: Re: Distant signals
Post by: Max-Max on May 05, 2013, 04:44:44 PM
@Erik
I left you a message on Skype.

@Eipi
You made my day! Thank you!!!

@James
Yes, I think we should make a fork for this. Can you be so kind to do it for us?
Title: Re: Distant signals
Post by: jamespetts on May 05, 2013, 04:58:45 PM
It is probably preferable for me to explain how to create a fork, but to do that, I need to know which tool(s) that you are using...
Title: Re: Distant signals
Post by: Erik on May 05, 2013, 06:01:13 PM
Quote from: Max-Max on May 05, 2013, 04:44:44 PM
@Erik
I left you a message on Skype.
...
Strange, I didn't receive it.
Title: Re: Distant signals
Post by: Max-Max on May 05, 2013, 09:40:07 PM
I'm using TortoisGit but I guess I don't have the permission to create a fork, right?
Can't you create a fork on Simutrans Experimental GitHub project page for us?
Title: Re: Distant signals
Post by: jamespetts on May 05, 2013, 09:47:06 PM
Ahh, no, what you need to do is create your own fork, which is a mirror of the 112.x-private-car-merge branch on your own repository, and keep that as a mirror of that branch on my repository. Then, on your own repository, you need to create a new branch (e.g., "distant-signals") based on that first branch. You will need to pull changes that I make to my 112.x-private-car-merge onto your master branch, then merge them into your distant-signals branch.
Title: Re: Distant signals
Post by: Max-Max on May 05, 2013, 10:25:38 PM
But I and Erik needs to keep "our" new fork in synch with each other as well.
I have a SVN server we could use for the fork, but I have never got the SSL to work so it's not public accessible.
Title: Re: Distant signals
Post by: isidoro on May 05, 2013, 11:52:45 PM
Quote from: jamespetts on May 05, 2013, 10:53:40 AM
1. The trains will have to travel slowly enough that, when they reach the distant signal, they will be able to stop in time for the next stop signal. The code in Experimental already provides for trains to count backwards from the next signal at which they must stop (which is at danger) and begin to brake in advance of it as early as is necessary. Adding distant signals just involves adapting this code so that trains always assume that signals ahead are at danger until they get within sighting distance of them, unless they have passed a clear distant (or multiple aspect) signal, in which case they know that the next (or, in the case of a four aspect signal at clear, next and second next) (stop) signals are at clear.
[...]

Thanks, James, for your answer.  Although I guess I'm somewhat thick and still don't understand it fully.  Imagine I have one one-way signal just before an intersection.  What would be the difference (game-wise) if I place a distant signal one tile before it, say 3 or 4 tiles before it, 100 tiles before it, or don't place it at all?

If I have understood it well, if the one-way signal is red, the distant signal would be yellow, and the train would drive slower from the distant signal on.  But, if I place no signal at all, the train will go full speed and calculate where it has to brake so that it stops at the one-way signal, which is better...  Placing a distant signal isn't then an advantage, is it?
Title: Re: Distant signals
Post by: Max-Max on May 06, 2013, 12:17:52 AM
@isodoro

Yes it is because it will take longer time for the train to reach the red signal at reduced speed. Meanwhile the red signal may change to a green so the train doesn't have to stop at all and can proceed at full speed.
Title: Re: Distant signals
Post by: jamespetts on May 06, 2013, 12:23:31 AM
Max-Max,

the way that you keep it in sync is this: you each do what I describe. Erik would have his own fork and you yours. You would periodically merge each other's changes into your respective "distant-signals" branches. Git is a distributed system: I think that you are conceptualising it as a centralised system like SVN: it doesn't work like that. It's actually better for collaborative projects like this than a centralised system precisely because you don't need to agree on a "master" branch - you can each do your own thing and merge it together arbitrarily.

Isidoro,

ahh, you don't take into account sighting distances here. The behaviour that you describe for the stop signal alone is the current behaviour, in which there are no sighting distances. With sighting distances, trains will assume that all signals are at their most restrictive possible aspect until they can see otherwise. So, the train would have to brake as if it were going to stop at the stop signal, and only accelerate again once it got within sighting distance of it and could see that it was clear (if indeed it was - otherwise it would come to a stand and wait for it to clear). If a distant signal was placed just one tile in front of the stop signal, this would have little practical effect - it would be very similar to having no distant signal at all, except that the train would be able to see one tile (125m) earlier that the signal is at clear (if indeed it is), and start accelerating again earlier. If the distant signals are far away enough from the signals, the trains won't have to brake at all.
Title: Re: Distant signals
Post by: Erik on May 06, 2013, 08:55:19 AM
Quote from: Max-Max on May 06, 2013, 12:17:52 AM
@isodoro

Yes it is because it will take longer time for the train to reach the red signal at reduced speed. Meanwhile the red signal may change to a green so the train doesn't have to stop at all and can proceed at full speed.

Yes, this was the first reason to begin with it. I've tested it and it did work partially.
At the end I hope to get a smarter traffic control to let the trains run more realistic and more smooth.
Title: Re: Distant signals
Post by: Max-Max on May 06, 2013, 02:52:18 PM
@james

I can see a conflict here.

Currently:
1. The main signal in Simutrans behaves as it should, no problem here. Red is stop if the next block is occupied.

2. The distant signal in Simutrans do stop a train if the full path to the next main signal (or station) is occupied.

3. The choose signal is also a type of main signal with a condition as long the train is in front of it. If the train's path goes through it via a distant signal it behaves as a distant signal with a condition (free path to next main signal/station)

Problem:
The new distant signal will never stop a train, only reduce speed. The current distant signal behaves more like a main signal with a condition (full path must be clear). Another property of the current distant signal is that multiple trains are allowed into the same block as long their paths doesn't cross. Again this has nothing to do with a real distant signal.

At shunting areas, a train can be allowed to enter even if there is other trains present. This is usually shown with a dwarf signal, signalling proceed with caution at very low speed. This would, in my opinion, be the same as a distant signal allowing multiple trains in the same block.

A distant signal can also declare that there is a speed limit ahead due to sharp turns, switches, deep slope or a bridge.

The question is, how much can we change the current system? Is it okay to remake the whole signal system?

If we break it down by functionality we get:

1. Stop if next block is occupied else full speed of X.
2. Reduce speed to N if next signal shows stop else full speed of X (remember that a distant signal can't show stop so they are ignored).
3. Reduce speed to N if next block is occupied AND no crossing path else stop.

If we define these 3 functions in the PAK file, we can combine them into new types of signals as rules of behaviour where the the outcome is prioritiesd: Stop, reduced speed and full speed.

Main signal, full track speed: is_stop_signal=1
Main signal, new speed 110km/h: is_stop_signal=110
Main+distant signal 60km/h: is_stop=1 is_distant=60
Distant signal 80km/h: is_distant=80
Choose signal at 30km/h: is_stop_signal=1 is_dwarf=30

To have a faster train to use a fast track if there is a slow train in front of it, put a minimum speed limit on the faster track and a signal before the switch: is_stop_signal=1 is_dwarf=1 This will stop the train if both tracks are occupied and switch over a faster train at full speed if possible. Slow trains will be stopped because they can't meet the minimum speed limit.

If we can identify different rules we can then combine them into quite advanced signal systems.
Title: Re: Distant signals
Post by: greenling on May 06, 2013, 03:25:24 PM
Hello on all
Gave it in Britain Signals they have a Distant signal on a choosesignal or blocksignal?
Title: Re: Distant signals
Post by: kierongreen on May 06, 2013, 03:39:28 PM
In Britain distant signals don't impose speed limits as such, but if set they do warn that the train should be brought to a halt at the next signal. Similarly for coloured light signalling a double yellow indicates there is a red two signals ahead, and a single yellow that there is a red one signal ahead. In both cases again the driver should be controlling the speed to bring the train to a stop for that red signal if necessary.

This is why in Britain a train driver needs to have route knowledge before driving along a particular route, otherwise they wouldn't know appropriate speeds. Other countries have different systems which are based on set speed limits however.

The High Speed line linking London to the Channel Tunnel, and the Docklands Light Railway (DLR) are the exceptions that I know of as both have in cab signalling which indicates a target speed. In the case of the DLR under normal circumstances a computer runs the service to this target speed therefore no driver is needed.
Title: Re: Distant signals
Post by: Max-Max on May 06, 2013, 05:20:44 PM
But if a distant signal doesn't change the speed, what point would it serve in Simutrans?

You can define the British behaviour by setting is_distant=1 this would not change the speed, but change the signal according to the status ahead of it.
Title: Re: Distant signals
Post by: jamespetts on May 06, 2013, 05:37:44 PM
Max-Max,

I think that there is still some confusion here about the way in which distant signals need to control speed. We cannot have them with a fixed speed limit set in the .dat files. Although there are some places in the world where there are such things as "speed signals", this is only possible because the spacing between the signals and the expected braking performance of the trains using the line have been precisely calibrated to that speed. Neither of those things practically can be done by a player in Simutrans. We need to retain the present system of having trains calculate automatically where they need to start braking for the next signal, but overlay onto that sighting distances, the presumption that all signals are at their most restrictive aspect unless the driver knows otherwise, and distant/multiple aspect signals, whose clear aspects let the driver know that the next stop signal will not be at danger (or, in the case of clear four aspect signals, that both the next stop signal and the one after next will not be at danger). Kieron has described the signalling practice applicable. As he explains, distant signals are not used (in the UK at least) to alert drivers to speed limits. There is already code in taking care of braking in advance of speed limits: this function does not need to be duplicated in the signalling code.

To give a practical example to explain what I mean, suppose that a train is proceeding along a section of track at 100km/h. Suppose further that it needs 2km to come to a complete stop. Suppose further that there is a stop signal 2km ahead. What happens now in Experimental is that the driver is assumed magically to be able to see the next stop signal - if it is at clear, the train can carry on going at 100km/h. If it is at danger, it has to slow down now. What needs to happen in the new system is that, at 2km from the stop signal, the train needs to start slowing down whether the stop signal is at danger or not, as the driver cannot see a signal from 2km away. Only when the train gets to within 250m of the signal can it accelerate again, provided that that signal is clear. Now, suppose that 2km in front of this stop signal is a distant signal. If the distant signal is at clear, the driver knows (as soon as the train is within 250m of that distant signal) that the next stop signal is at clear, so can carry on going at 100km/h until the train gets within 2km of the next signal that might be at danger. Now, suppose that on that same stretch of track is another train, going at 200km/h, with a stopping distance of 4km. The distant signal is only 2km from the stop signal, and the sighting distance of the signal adds only 250m. The train would therefore have to start to brake in order to stop in time for the stop signal 4km from it whatever the distant signal was showing: the distant signal would be too close to the stop signal to allow the train to continue at 200km/h. Only when the train gets to within 250m of the distant signal, and can see that it is clear can it stop braking and start accelerating again. To allow this train to continue uninterrupted at 200km/h, it would be necessary either to double the spacing of signals along the line (but this would halve capacity), or use four aspect signals instead of three aspect or single aspect signals such that there is another signal at 4km which would tell the driver that the next signal 2km away is clear, and that the signal after that, 4km away, is also clear.

As to what you describe as a conflict, there is not a proper distant signal in Simutrans at present. There is a "pre-signal", which has a totally different functionality. It is not clear to me whether this functionality needs to be retained - some careful thought will have to be given to that. However, that functionality, if retained, is completely different to the functionality of a true distant signal, and the two should not be confused simply because, in Pak128.Britain, the authors of the pakset have chosen to represent it with the graphics of a distant signal.

When you write about multiple trains being allowed into the same "block" as long as their paths do not cross, I think that there is some misunderstanding of how block signalling works here: a "block" is the path from one signal to the next. That path might be changed by the use of points. What counts as a "block" therefore depends on how the points in the relevant area are set. The notion of a "block" as a single fixed section of track only really makes sense where the track between two signals has no points. For all signals controlling points, the principle that you describe here, and that is in fact used in Simutrans, applies: trains will be allowed to proceed when the path to the next signal as currently set by the various points is clear. The points cannot be changed whilst there is a path set over them until the train has passed (or unless the route is cancelled, in which, in real life, there is a time delay during which one cannot set any conflicting path over those points in case the route is cancelled too late and the train for which it was originally set over-runs the signal that has just turned red without warning).

Turning to the specific questions:

QuoteThe question is, how much can we change the current system? Is it okay to remake the whole signal system?

If we break it down by functionality we get:

1. Stop if next block is occupied else full speed of X.
2. Reduce speed to N if next signal shows stop else full speed of X (remember that a distant signal can't show stop so they are ignored).
3. Reduce speed to N if next block is occupied AND no crossing path else stop.

That rather depends on what you mean by "remake the whole signal system". All other things being equal, the fewer changes the better, as there will be less chance of bugs, less work for pakset maintainers, and more backwards compatibility. All things cease to be equal where a change is necessary to produce a coherent system or simulate some economically significant element of transport operation. We should probably discuss and agree specific changes here before they are coded to make sure that the balance is got right.

Your list of functionalities needs to be modified in light of the above. Having a modular system (a signal can be stop, distant, double distant or any combination of the above) allows the same system to work for older single aspect signalling and modern multiple aspect signalling, which is a sensible way of doing things. The functionalities should therefore be as follows:

Stop
If at danger: Stop behind this signal
If at clear: Proceed to the next signal, but be able to stop in time if it is at danger.
Condition for being at clear: If the path between this signal and the next signal on the approaching train's route is clear, and all crossings on that path are (1) free of all road vehicles; and (2) closed to all road users.

Distant
If at caution: Proceed on the assumption that the next stop signal in the train's route is at danger, and be ready to stop in time.
If at clear: Proceed on the assumption that the next stop signal in the train's route is at clear, but that the one after it might be at danger, and be able to stop in time for the stop signal after next.
Condition for being at clear: If the next stop signal on the train's route is at clear.

Double distant
If at (double) caution: As for "clear" in the distant.
If at clear: Proceed on the assumption that both the next stop signal and the stop signal after next in the train's route are at clear, but that the one after that might be at danger, and be able to stop in time for the stop signal after the stop signal after next.
Condition for being clear: If the next two stop signals on the train's route are at clear.

Combinations of those functions should allow for multiple aspect signalling: a three aspect signal is a stop signal combined with a distant signal, and a four aspect signal is a stop signal combined with a distant and a double distant signal. (In UK practice, the "double distant" function is only actually used in four aspect signalling so far as I know).

Trains/drivers will always be assumed to know where the signals are at all times, but not what aspect that they are showing until they are within sighting distance of them. Trains must always travel at such a speed that they are able to stop at the next stop signal that might be at danger. This means (and is intended to mean) that trains will have to keep slowing down if the signal spacing is too close for their speed and braking performance, as well as the type of signals used.

Obviously, trains will have to reserve a path through to the next stop signal: a path can never end at a distant signal. Thought will need to be given to exactly when trains first attempt to reserve a path. Where there are distant signals, they should do so far enough ahead of those distant signals (including a multiple aspect signal) so that, if the path is clear, the path can be reserved from the next stop signal (or stop signal after next, or the one after that, for three and four aspect signals respectively) so that those distant signals are at clear at the moment that the train enters their sighting distance, to minimise the chance of it having to slow down unnecessarily (it should only have to slow down if the path from the applicable stop signal is not available straight away; delays in clearing vehicles from crossings ought to be accounted for by increasing the time in advance for checking paths).

Some consideration will have to be given to whether it should be possible to set some trains to check further in advance of others, in order to give them priority over others: this might facilitate the simulation of express trains, freight loops and the like.

Greenling, as to your question, yes, there are pre-signals, choose signals and long block signals in the current Pak128.Britain (both Standard and Experimental).
Title: Re: Distant signals
Post by: kierongreen on May 06, 2013, 11:33:00 PM
You should also note that 5 aspect signalling has existed in the UK. This allowed trains to travel up to 225km/h on conventional railways (sections of the east coast railway) until they deemed it unsafe. This is part of the reason 20 years on that line is still slower than under British Rail.
Title: Re: Distant signals
Post by: jamespetts on May 06, 2013, 11:53:40 PM
Quote from: kierongreen on May 06, 2013, 11:33:00 PM
You should also note that 5 aspect signalling has existed in the UK. This allowed trains to travel up to 225km/h on conventional railways (sections of the east coast railway) until they deemed it unsafe. This is part of the reason 20 years on that line is still slower than under British Rail.

Ahh, the flashing greens? Yes - the drivers couldn't see the signals clearly at that speed (presumably, especially if they were flashing on and off), from what I understand, so that cab signalling is now required for anything over 125mph (200km/h). This constraint is something that I have also wanted to simulate, along with moving block signalling (the Central Line's implementation is probably the easiest), drive by sight (no signals needed, trains/trams go no faster than allows them to stop within whichever is the lesser of their sighting distance or the next convoy ahead) and radio electric token block (only RETB boards are allowed, trains have to stop and wait a short time at every signal to ascertain whether the line ahead is clear; but the signalboxes would be cheap to build and run and have a massive coverage area compared to ordinary signal boxes).
Title: Re: Distant signals
Post by: kierongreen on May 06, 2013, 11:58:30 PM
Note that in normal use RETB doesn't actually slow trains down, as loops tend to be at stations where trains are stationary anyway.

Up to 225km/h should be allowed with conventional signalling - at least, if signal spacing is far enough apart (and there are no crossings).
Title: Re: Distant signals
Post by: jamespetts on May 07, 2013, 12:17:42 AM
Quote from: kierongreen on May 06, 2013, 11:58:30 PM
Up to 225km/h should be allowed with conventional signalling - at least, if signal spacing is far enough apart (and there are no crossings).

I thought that the problem was that drivers could not reliably see the signals at all when travelling at that speed?
Title: Re: Distant signals
Post by: isidoro on May 07, 2013, 12:24:39 AM
Thanks, James, for your explanation.  Now it is clear.  Since the driver knows where the next signal is, even if he doesn't now its aspect if farther than the sighting distance, he can drive intelligently (at full speed, for instance, if he knows that there is enough space to bring the train to stop before the next signal).

Title: Re: Distant signals
Post by: jamespetts on May 07, 2013, 12:26:03 AM
Quote from: isidoro on May 07, 2013, 12:24:39 AM
Thanks, James, for your explanation.  Now it is clear.  Since the driver knows where the next signal is, even if he doesn't now its aspect if farther than the sighting distance, he can drive intelligently (at full speed, for instance, if he knows that there is enough space to bring the train to stop before the next signal).

Yes, indeed - that's exactly how it works on real railways.
Title: Re: Distant signals
Post by: kierongreen on May 07, 2013, 12:34:03 AM
The 200km/h limit is because of the braking distance imposed by signal spacing and 4 phase signalling. 5 phases was one way around that, increasing signal spacing would be another. Moving all the signals would have been a much greater expense than adding the 5th phase of flashing greens, hence why that approach was adopted.
Title: Re: Distant signals
Post by: jamespetts on May 07, 2013, 10:15:33 AM
Yes, I understand that, but you wrote that this practice was discontinued because it was "deemed unsafe": it was deemed unsafe, I understand, because drivers cannot reliably see signals at all at 225km/h (presumably, especially if they are flashing on and off). Cab signalling would be required at that speed, from what I understand.
Title: Re: Distant signals
Post by: kierongreen on May 07, 2013, 06:04:04 PM
I've done a bit of research on this just now... Unsafe seems a relative term. Restrictions on running trains above 125mph/200km/h seem to have applied to revenue service rather than passenger service as such - there are plenty of documented press runs for both Intercity 225 and APT when trains went up to around 225km/h. Test runs for both train types went above 250km/h but they should be disregarded. It seems like service APT trains regularly went above 125mph in the 1980s, before health and safety was as strict as it would be now.

Not sure how you'd best deal with this in Simutrans (Experimental). Certainly above 140mph should be prohibited using conventional signalling - but I don't know how you'd simulate the additional expenditure required to refit trains for in cab signalling.
Title: Re: Distant signals
Post by: Max-Max on May 07, 2013, 06:22:01 PM
Well we are an international community and we need a way to satisfy as many as possible.

If we start to put down the requirements to begin with, I can see if I can work out some system that will be able to satisfy the list.

So far I understand:

Main signal (block signal?):
On green: Set track speed.
On Red: stop.

Distand signal:
Green/red: Set speed depending on number of green signals ahead (this can be track speed or max speed limit)

With track speed I mean the speed the train would have on a "normal" clear track.
With max speed limit I mean the signal will decide a new max speed for the block. It is however caped to the track speed.
Title: Re: Distant signals
Post by: kierongreen on May 07, 2013, 06:26:17 PM
Note - British signalling is significantly different from that on the continent. Hence cause of some confusion I think.
Title: Re: Distant signals
Post by: Max-Max on May 07, 2013, 06:40:48 PM
This is why I try to get all the requirements so I can work out a configurable system.
Try to break down the functionality for your country and list them here.

So far we have not mentioned ATC or the new ERTMS/ETCS systems that all European countries will adapt.
It sounds boring to have no signals but there are 3 levels.

Level 1 has signals and works pretty much as ATC does today. You do need eurobaliser along the track.
Level 2 has no signals and requires both eurobaliser, signal lines and RBC stations along the track.
Level 3 Has no signals and also allows moving block. It also doesn't requires any signal lines along the track, this is completely radio based.
Title: Re: Distant signals
Post by: jamespetts on May 07, 2013, 06:51:13 PM
May I ask: what is eurobaliser?
Title: Re: Distant signals
Post by: Erik on May 07, 2013, 08:07:26 PM
With a quick search I found this:
http://www.ertms.net/ertms/ertms-signalling-levels.aspx (http://www.ertms.net/ertms/ertms-signalling-levels.aspx)

I've never heard from it earlier.
Also I thing it isn't suitable for Simutrans. I like to build a working rail system with the signals.
Title: Re: Distant signals
Post by: Max-Max on May 07, 2013, 09:08:05 PM
Well suitable or not, I can think of a whole range of things you could use in an ERTMS/ETCS system, but I do agree that it is more fun to watch a signal.

As I said before, no one is forcing anyone to use things they don't find fancy or fun.
Title: Re: Distant signals
Post by: jamespetts on May 07, 2013, 10:08:28 PM
The ETRMS discussion is an interesting one. We must, however, seek to differentiate, on the one hand, the underlying technology, which we need not directly simulate, and the functionality, which we do. (We do not, for example, directly simulate block instruments or track circuits). From what I can make out, the functionality layers that we need to be able to simulate at some point are cab signalling and moving block signalling. I should note that moving block signalling is not limited to ETRMS - it also exists on a number of low speed lines in London, such as the Central Line and Docklands Light Railway.

Because of the way in which the code in Simutrans works, it is hard to have a system that is completely without signals. What I suggest that we do for moving block signalling is have a system like that on the Central line, which is backwards compatible with trains not equipped for moving block signalling by having special three aspect signals: the danger (red) and clear (green) aspects work as with normal absolute block signalling, but there is an additional special (white) aspect which allows only moving block equipped trains through it. This is a good way of doing things in Simutrans because it interacts well with the existing system (we do not have to define track tiles as having any special signalling property: we just work on the basis that the path between a moving block signal and the next signal operates according to moving block rules when a moving block equipped train passes).

Cab signalling in one sense is easier and another harder. In one sense, the present signalling system in Simutrans-Experimental is more or less equivalent to cab signalling, in that drivers are assumed always to know what the next signal aspect is. In principle, it is not too hard to assign rail vehicles a property of having or not having either moving block or cab signalling equipment (defined in the .dat files), and further operating only according to cab signalling principles when the train has cab signalling installed and the next signal is compatible with cab signalling. What might be slightly trickier is simulating the economics of retro fitting existing vehicles with cab signalling equipment - the only easy way of doing this is to have two versions of the vehicles in the .dat files, one with and one without cab signalling, and define an upgrade path between them. That is a trifle cumbersome, but it will probably have to do.

Returning to the earlier questions about absolute block signalling:

Quote
Main signal (block signal?):
On green: Set track speed.
On Red: stop.

This is still not quite correct. The signals do not, of themselves, set the track speed. The track speed is a property of the track itself (and the way object, too, if it has its own speed limit). The speed at which a train can go is determined by:

(1) the track/way object maximum speed;
(2) the train's own maximum speed;
(3) the curvature of the track; and
(4) the need to brake in time for any upcoming:
(a) speed limit reductions (of any type - whether track, way object or curvature);
(b) stations;
(c) reversing waypoints; or
(d) signals that might be at danger.

To that sublist list we might add "other trains" in a moving block or drive by sight system. As explained above, the train (driver) will know where the next stopping point is and start braking in good time to stop there, taking into account the current speed and the train's braking capabilities. In the absolute block system, we just need to add the concept of being ignorant of the aspect of the upcoming signal (and therefore whether the train needs to stop for it), and the means of overcoming that ignorance (the signal's sighting distance, and signals with a caution aspect).

There is one exception to that, and that is the signal sighting speed limit, which, as discussed with Kieron above, is 200km/h in the UK. This means that for any train not equipped with cab signalling or where the next stop signal is not compatible with cab signalling, it will not in any event be able to travel more than 200km/h. I suggest that the signal sighting speed limit be set in simuconf.tab.

QuoteDistand signal:
Green/red: Set speed depending on number of green signals ahead (this can be track speed or max speed limit)

In UK signalling practice, distant signals display yellow and green rather than red and green aspects - one should rather talk of "caution" and "clear" designations than use colours. Again, this does not actually set the speed as such, but gives information to the train as to whether it will have to stop at the next signal or not, so that it knows whether to start braking to stop for it or not.

Quote
With track speed I mean the speed the train would have on a "normal" clear track.
With max speed limit I mean the signal will decide a new max speed for the block. It is however caped to the track speed.

As stated above, we cannot really have speed signals with a fixed speed in Simutrans because it is not practical to have any means of reliably calculating what that speed should be. What is needed is a means of communicating to the trains whether the next signal (and the signal after next) will be at danger or not.

Perhaps it is best to conceptualise it in this way: in absolute block signalling, a signal can have any of the following states:

(1) stop: do not proceed beyond this signal;
(2) proceed, but assume that it will be necessary to stop at the next signal capable of displaying (1) unless and until the next signal is visible and shows otherwise; and
(3) proceed, and assume that it will not be necessary to stop at the next X number of signals capable of displaying (1).

State (1) corresponds to the danger aspect of all double and multiple aspect signals. State (2) corresponds to clear on a double aspect signal (a semaphore stop signal or a two aspect colour light signal) or caution on a distant signal or a multiple aspect signal. State (3) where X = 1 corresponds to clear on a distant signal, clear on a three aspect signal, and double caution on a four aspect signal. State (3) where x = 2 corresponds to clear on a four aspect signal. (In Kieron's example of experimental five aspect signalling, the flashing green would be state (3) where X = 3).
Title: Re: Distant signals
Post by: Max-Max on May 08, 2013, 03:37:38 AM
James,

I will try to be as frank as possible without the meaning of being rude, maybe I just have a hard time to explain my thoughts.

I'm trying to design a system that will work for as many countries as possible, not only UK. I have perfectly well understood the UK distant signals (http://en.wikipedia.org/wiki/UK_railway_signalling) by following the very detailed corresponding in this thread and various information from Google.

This article (http://www.railway-technical.com/US-sig.shtml) explains in a very simple way the differences between the UK and US/European signal systems.

I'm trying to break down the functionality from a program design perspective. A distant signal may have the possibility in the PAK .dat file to be configured to set a maximum speed because this is how it work in many countries, including Sweden. It also has to be able for a configuration to work as an UK distant signal.

Here is a some what not fully translated (the original Swedish has more text) Wiki about Swedish signals (http://en.wikipedia.org/wiki/Swedish_railway_signalling). The German distant signals can also show a max speed limit as seen here (http://en.wikipedia.org/wiki/German_railway_signalling) and what I make out of it it is 40, 60 and 100km/h. This is another excellent site for German signals (http://www.sh1.org/eisenbahn/sh.htm). The Italian distant signal (http://en.wikipedia.org/wiki/Italian_railway_signalling) can also indicates a maximum speed, and so can Polish etc...

I'm trying to figure out what functions do we need to create all these different signals in the PAK file, through the .dat configuration.
Some parameters would be more appropriate to put in the Simutrans.conf file I guess, like how far can the driver see? In theory, he would be able to see a light from an even further distance during the night. Should the terrain block line of sight? etc...

I wrote "track speed" to avoid a long novel about how the train's speed is calculated. As I understand, this is already implemented and has very little to do with this signal project, except that we need to recalculate the speed depending on the distant signal UK style, where we use train mass, speed, break ability and what ever we need to adjust the speed to the next indicated full stop. I can be completely wrong on this point, but please do correct me. I just feel that this is a far to detailed discussion at this point. Let us just say that the train must be able to stop in time at a certain point.

I agree that a signals colour is irrelevant for the discussion, let us continue on your definition of track clear, proceed with caution (at danger) and full stop. Now, I'm still on a very high level of brainstorm/design phase. So far I have concluded:

(1) That a signal needs to see X number of blocks ahead.

(2) One or more rules to "search" for a path through the blocks in (1).
    (i) "normal" path finding (as of a block signal today)
    (ii) "choose" path finding where more than one alternative can be chosen (as for a Choose signal of today).
    (iii) "crossing path" allow a train to proceed even if another train is crossing its path, the train will stop if it needs to avoid a collision (this is a
pure brainstorm but would allow us to create dwarf signals on shunting yards).
    (iiii) search for "road crossing". This would tell it to only look for a crossing of another type than itself. In this way we can create signals for road/tram crossings.

(3) It must react to the outcome of (2) in one of two ways.
    (a) adjust the speed to stop in time before next confirmed full stop (UK style).
    (b) adjust the speed against the the indicated max speed by the signal (non UK systems). The track's "track speed" has of course the highest priority, then the train and last the speed indicated by the signal. It is common sense that a train that can travel at max 30km/h can't suddenly go up to 80km/h on a 50km/h track just because a signal say "maximum speed allowed 80km/h". It would of course still proceed at 30km/h (unless other factors makes it go even more slow).

If we combine these 3 elements in the PAK .dat file, the PAK designer should be able to create the most kind of signals. Exactly how this would be done is to early to tell at this stage, just embrace the thought that it is possible. I'm tempted to write a simple scanner and parser for the .dat files. This would open up a lot more possibilities of what can be done in a .dat file.

The challenge with (1) is that we also need to give feedback to the signals behind us, up to X blocks, so they can be updated correctly as we pass each signal. One thought that comes to my mind would be to have the train carry a list of passed signals and remove them when we past the signals range.

If we now leave all the technical details for a while, is there a scenario I have missed? Can we create the signals we need with these components?

As a side note:
When It comes to ATC and the new ETRMS I think we can expand on this structure and replace signals with eurobaliser and radio stations covering covering them. ETRMS Level 1 and ACT still use signals but can adjust the speed between signals if the conditions change. ETRMS Level 2 and 3 will just require different elements to operate, like tracks, eurobaliser, radio and moving block algorithm.

The code and logic to drive the signals are mainly in the train, so to implement ACT or ETRMS would "simply" be a new set of rules (what block to look for and react on). But we can leave this for now.
Title: Re: Distant signals
Post by: jamespetts on May 08, 2013, 10:23:42 PM
Thank you for the helpful reference to that article - signalling in the US is indeed very different (the most interesting difference seems to be the non-totality of signals, and the frequent use instead of the "track warrant" system).

We do indeed need to specify very carefully what functionality that we need to implement in a somewhat abstract way. One of the things that is particularly difficult for us to do properly is the (fixed) speed signal. Presumably, in real life applications, these speeds are not plucked out of the air, but based on the actual expected braking performance of trains combined with the spacing between the signals. We cannot really do that in Simutrans - at least not without a fiendishly complicated system for placing signals and spacing them automatically based on expected braking performance (where do we get that from? And then what happens when two sets of automatically spaced signals merge on a junction - etc.). Indeed, the article on Swedish signalling suggested that the distances between speed signals there are very precisely set. Presumably, the 40km/h speed (the only true limit that seems to be given by the signals themselves - the 80km/h limit appears to be Sweden's maximum speed without ATC, which seems to be a form of moving block or cab signalling) is based on the expected braking ability of trains, the spacing of signals, and the sighting distances such that a train travelling at 40km/h can stop by the next signal within sighting distance of it? (I daresay that the same applies to the seemingly rather convoluted Italian system).

As to the "crossing path" - how would this work? I am not sure what you mean here. As to road/tram crossings, all signals (including choose signals) ought not to allow a train to proceed beyond them if the path between them and the next signal is occupied by a level crossing that is not (1) free of traffic; and (2) closed to traffic.

As to a .dat file scanner and parser - what had you in mind here? How do you imagine this opening up new possibilities?

As to this point:

QuoteThe challenge with (1) is that we also need to give feedback to the signals behind us, up to X blocks, so they can be updated correctly as we pass each signal. One thought that comes to my mind would be to have the train carry a list of passed signals and remove them when we past the signals range.

I don't think that we actually need to do this - unless you want fully to simulate automatic signals on straight stretches of track even though this would largely be cosmetic. All that we have to do is have signals at danger unless a path is reserved from it to the next signal on an approaching train's route. There is no need for a train to communicate backwards to tell signals that it has passed what to do; all the logic can be put in what happens when a train requests that a route be reserved beyond a signal, as is the case now.

Quote
When It comes to ATC and the new ETRMS I think we can expand on this structure and replace signals with eurobaliser and radio stations covering covering them. ETRMS Level 1 and ACT still use signals but can adjust the speed between signals if the conditions change. ETRMS Level 2 and 3 will just require different elements to operate, like tracks, eurobaliser, radio and moving block algorithm.

The code and logic to drive the signals are mainly in the train, so to implement ACT or ETRMS would "simply" be a new set of rules (what block to look for and react on). But we can leave this for now.

I am not sure quite how you imagine implementing the "eurobalisers" here. For moving block signals, all that we have to do is work out the braking required to stop before the next train rather than signal on the path, taking into account the fact that, if moving, that next train itself will take time to stop, and update the reservation ahead every tile passed, rather than only when approaching a signal. We can use the same basic code to check for signals ahead and brake in time for them as is in the code already, just adapted instead to look for trains as well as signals.
Title: Re: Distant signals
Post by: cy087 on May 09, 2013, 02:06:59 AM
(Just passing by and noticed the question "is there any scenario missed?".)

To my mind there is one thing missing in simutrans regarding rail transport and that is "speed boards". In rural Australia there are many sections (somewhere between a simutrans signalling block and a simutrans track tile) that have absolute maximum speeds, regardless of the maximum rated speed of the road construction, curvature or control mechanism.  The reasons for speed board controlled sections ranges from the shunting/switching reasons already touched on in this discussion through to more complex conditions such as environmental hazard zones (for example, sections where track deformation due to extreme heat is possible; sections where advance visibility can change suddenly due to prevailing weather conditions (( I'll give this one a special mention as it includes sections in tropical or even temperate areas subject to sudden fogs)); sections where interfaces between normal & non-normal operating rules apply; sections with histories of SPAD incidences; etc.

My main point is, that these sections have a fixed maximum speed, regardless of anything at all but in particular regardless of the rated track speed.

As I indicated, this is just an observation on a fascinating topic and I have posted it only within my understanding of the intent of the experimental branch to make things more realistic.  I feel sure that speed boards have their equivalent in non-Australian rail systems.  The Australian system, by the way, appears to have borrowed signalling methodologies from where-ever as well as from it's English system heritage and then modified them to suit not only national but local conditions.  For example, (and beyond the discussion here) in central Sydney there are road guarantees as low as 6 minutes in some places in order to cater for metropolitan, inter-city and interstate passenger services AND freight consists all using the same main lines. Frankly, if you do not accept an offer and enter it within the six minutes then the section is closed and the offer is revoked. Fullstop.  Another anomaly is the hesitancy to adjust SafeWorking rules to accommodate in-cab signalling, possibly due to the wide age range of  operating equipment.  Finally, (AFAIK), reliance on ATC beyond metropolitan boundaries remains a dream, the Queensland "Tilt train" incident (http://www.tmr.qld.gov.au/Safety/Rail-safety/Safety-reports/Cairns-tilt-train-derailment.aspx) being a perfect example (refer section 2.1).

cheers
CY087


Title: Re: Distant signals
Post by: jamespetts on May 09, 2013, 09:42:56 AM
Interesting - thank you for your suggestion. May I ask, however, what exactly is the "rated track speed" if not the speed shown on what you describe as a "speed board"? Certainly, in the UK, the speed limit of any section of track is always shown on a board or sign of some or other sort, so the two are not conceptually distinct. In terms of simulating this, how might this fit in with the things that Simutrans actually simulates? What conditions that are already in themselves simulated would give rise to this "speed board"?
Title: Re: Distant signals
Post by: Vladki on May 09, 2013, 09:56:57 PM
Hello,

I have read through this discussion, and as I would like to see distant signals working in Simutrans, I wanted to share some info about czech signalling so that you can compare.

Main lines have "autoblock" - three light signals evenly spaced with the following states:
green - clear, go at full speed
yellow - warning, start braking so that you can stop at the next signal
red - stop.
Some lines have four light signals at shorter distances. The extra signal is:
yellow and white - repeated warning - this is the last signal before red, yellow was on the signal before this one.
Autoblock signals so far away that trains can safely start braking after passing the yellow light. However the yellow and white signal is not far enough and the train should be already braking when approaching that signal.
For simutrans implementation I would suggest maybe simplistic solution - just keep the braking code as is, and modify only the display of signals. When the train is approaching a signal, try to reserve as far as the braking distance is, plus one more block. If it can be reserved - show green. If only the braking distance can be reserved - show yellow, and if we are closer to the red signal (end of reservation), show yellow and white.

On czech railways we have signals that tell the max speed, but they are used only when entering or leaving the station when the train goes through switches. They are never used on straight track. There are also distant signals telling the max speed on next signal. But I think this is a completely different stuff.

Tracks without autoblock use distant signals with yellow/green, and main signals with red/green. Distant signals are always put in safe braking distance from the main signal. There are also special crossing signals put in braking distance from road crossing, to inform the train driver whether the crossing is closed or not. Crossings close to other signals (or on autoblock lines) may be bound with them - signal goes green only when the crossing is closed.

So, I hope some of this info will be useful for you.

Vladki
Title: Re: Distant signals
Post by: jamespetts on May 09, 2013, 10:09:11 PM
This system seems very similar to the UK system described, except for the colours and sequence of the four aspect signals, and the absence of speed limits on all track. The way to implement this system is as already described for the UK signalling: to make it work for Czech signalling, one would just have to produce different signal graphics.
Title: Re: Distant signals
Post by: cy087 on May 10, 2013, 04:25:57 AM
Quote from: jamespetts on May 09, 2013, 09:42:56 AM
Interesting - thank you for your suggestion. May I ask, however, what exactly is the "rated track speed" if not the speed shown on what you describe as a "speed board"? Certainly, in the UK, the speed limit of any section of track is always shown on a board or sign of some or other sort, so the two are not conceptually distinct. In terms of simulating this, how might this fit in with the things that Simutrans actually simulates? What conditions that are already in themselves simulated would give rise to this "speed board"?

1. The rated track speed is the speed limit depending on track construction and track layout (and grade).  This is well implemented in the game.
2. Sometimes (in the game) where a high speed passenger service and a low speed freight service contend for a block a passing loop is built to enable the passenger service to overtake the freight.  While this is achievable using way-points in the freight line and a lower grade track on one section to "slow" the freight to the point that the passenger service can overtake that approach tends to look ugly to me, means the freight will always use the "low speed lane" and can be difficult to implement with interference from weight limits.  If the passing loop could be a controlled speed area perhaps the code could
a) slow the freight sufficiently to increase the probability that the following passenger service can overtake
b) route the freight over the slower side of the loop only if there is a following consist with a higher maximum speed (maybe this is harder).

Title: Re: Distant signals
Post by: jamespetts on May 10, 2013, 06:30:37 AM
Quote from: cy087 on May 10, 2013, 04:25:57 AM
1. The rated track speed is the speed limit depending on track construction and track layout (and grade).  This is well implemented in the game.
2. Sometimes (in the game) where a high speed passenger service and a low speed freight service contend for a block a passing loop is built to enable the passenger service to overtake the freight.  While this is achievable using way-points in the freight line and a lower grade track on one section to "slow" the freight to the point that the passenger service can overtake that approach tends to look ugly to me, means the freight will always use the "low speed lane" and can be difficult to implement with interference from weight limits.  If the passing loop could be a controlled speed area perhaps the code could
a) slow the freight sufficiently to increase the probability that the following passenger service can overtake
b) route the freight over the slower side of the loop only if there is a following consist with a higher maximum speed (maybe this is harder).

(a) does not make a great deal of sense - why should the freight train slow down on the loop unless there is a passenger train needing to overtake (in which case, why slow down, rather than just stop at the end of the loop?).

In order to make this work in a useful way (something like your (b)), what would be needed is contingent orders in schedules, which would be enormously complicated, not least from the user's perspective (what - exactly - would a user actually input to a revised schedule window to explain to the freight train what exactly it is looking for and where for it to trigger the relevant condition?) The easier thing is for users to construct what are in effect timetables using the spacing/offsetting procedure so that freight trains and passenger trains meet in predictable places; if a(n empty) freight station is placed on the loop, the freight train can be made to wait at the "station" (sidings) until a particular time.
Title: Re: Distant signals
Post by: merry on May 10, 2013, 12:05:01 PM
Ok, lots of good work going on in here. As someone with an interest in signalling, I'd like to add some observations:

(0) All signalling systems are an effort to avoid trains colliding, either through long stopping distances or conflicting routes.

(1) all fixed-block systems of train control (semaphore, 2-aspect, 3 & 4-multiple-aspect [MAS], RETB, and even ERTMS level 1 & 2 and dispatcher-based systems) are fundamentally the same idea. One train per defined section, please! I think that the French TGV/Eurostar TVM430 (and predecessors like TVM380 [number might be wrong] are cab-based ways to do this with the addition of speed indication as below). The exact form colour and positioning of the signals is not important as the basic function is the same. Block based transmission based systems (including Eurobalise) will still need blocks to be defined.

(2) all speed signals are a way for the signalling to tell the train (& driver) what is the safe speed at which they can (a) travel over the infrastruture without risk of derailment or damage, and (b) expect to stop within the available blocks. TPWS is a UK example of a cab-based solution to this. Fixed track speed limits are speed signals with one indication, in all but name.

(3) The UK distant signal is, in effect, a 'speed signal', but in the UK the driver is expected to have 'route knowledge' and to know the permissible speeds at which a signal may be passed to stop safely at the next known danger indication.

(4) moving block systems are different: track speed is observed by the signalling too, but the train effectively reserves the necessary stopping distance ahead only [actually the signalling system gives a continually updated authority, but let's not worry about this, it's irrelevant for ST] . A complication for ST is to reserve routes correctly through single lines and junctions especially where trains can follow one another at short safe separations - you can't reserve the whole block ahead, but you need to book the route for reservation when available and prevent opposing moves on single lines. This could provide an improved way of handling

(5) Level crossings: not all require to be closed when a train enters the block:
   (a) Busier crossings are directly protected by signals, and require to be closed to conflicting traffic before the signal can show a proceed aspect
   (b) other crossings are closed to road traffic upon the approach of a train. In semaphore days, this required a crossing keeper but was not a block post. In the UK, many had distant signals but were not block posts. Nowadays a good example is the AHB (for all the associated risks of users ignoring them) or the open crossing with warning lights (on slow tracks) - they operate automatically and only when the train approaches. This allows crossings to be protected in long block sections without being closed to the road for an unreasonable time
   (c) 'accommodation crossings' [Uk term, but the idea occurs in many countries] are normally closed to road traffic, and opened by the road user upon the authority of a signaller, or simply upon adequate visibility. Obviously these are only on low/medium speed lines and for low road traffic, such as farm or individual properly access!

(6) All the above require a singalling control point - some are quite local (traditional signal boxes), others cover huge areas, e.g. the UK regional operations centres, or central radio dispatcher centres. In the middle are Power signalling centres, covering districts or route sections.

(7) <pedantry>
To clarify & avoid confusing false descriptions, a single-aspect signal is an end of line! Semaphores and colour light distant+stop signal systems are 2-aspect (where each signal has either red/green or yellow/green). Note London Underground only uses 2-aspect - many LUL distants are mounted on the same post as the preceding 'stop' but are not 3-aspect signals!
</pedantry>

( 8 ) Drive on sight is what James describes above, but it still needs signalling or dispatcher control for single lines and for junctions. There may be a need to be able to define the end of 'block signalling' after a signalled portion of line if this is implemented.

What i'm trying to get at is that there are really only two types of signalling - fixed or moving block - and everything else is an implementation of these. Speed signals are implemented by the braking distance and infrastructure limits in ST and are not actually needed.

As a thought, the discussion includes systems requiring a central control point (e.g. ERTMS or Dispatchers). To have these explicitly woudl be nice, but this implies a need for signal control points of different types and grades - from a crossing cabin to a regional control centre. Lots of change for some realism but I wonder it the work is worth it for the game improvement?

To add a personal opinion, I'd very much like to support james suggestion of  removal of the 'pre-signal' and the implicit platform signal, and replacement by a proper train control system to allow single lines to be handled without deadlock. I am fairly sure that amongst the desirable  moves would be to make all signals able to be passed in the reverse direction [noting that this is always real-life practice; where bidirectoinality undesirable there is a 'fixed stop' signal or a lack of track authority in the other direction, which in ST would be a 'rail close' signal, commonly found is ST standard already but not in PakBritain!] thus enabling bidirectional platform signalling instead of the current implicit platform signals. it would also allow two trains to follow through a section with mid-section signals on a single line, etc, etc.

Hope this helps the debate, please keep up the excellent development!

TTFN
Merry
last edit reason: remove auto-generated smileys!
Title: Re: Distant signals
Post by: cy087 on May 10, 2013, 03:01:05 PM
@James

Yes, exactly. I don't know enough about the internal workings of Simutrans to offer a functional specification of how this could be done, but contingent orders would seem to be the "most obvious way" to resolve that scenario.  As far as I know, those contingent orders are far beyond the capabilities and expectations of the game. So be it. 

But now we are digressing from the matter of speed boards. 

The simple aspect is this.  As you said, (in real life) sign posted speed restrictions over road sections (not blocks) are a general way to provide safe working conditions for any traffic.  I was looking for a game oriented example of how speed boarding can "make things easier" for the player. But, yes it "makes it more complicated". Culpe mea!

Such is life.  We may have digressed a little bit from the intent of the thread and I apologize for that   --  it was just the question about "is their anything forgotten".  So to get it down to its' simplest and within the intent of what I originally posted. There is a non-signalled road control mechanism in the real world, and (apart from the fact that it is missing in the game) that was all I wanted to say.  So, having said that, let me now say this this. "This!" :-)

Anyway,  the game is still fascinating and I applaud all of you adding more and more to it.  So stop listening to me and get on with making those signals work.

@merry
Nice synopsis. Some really good real life scenarios raised and much better than I could put them.

best regards
CY087
Title: Re: Distant signals
Post by: Max-Max on May 11, 2013, 12:14:14 PM
Regarding speed boards.

I do see little function to have a speed board limiting the speed, more a cosmetic detail for the player. However for roads, we can today put up a minimum speed board to divert faster trucks onto a faster route. AFIK these speed boards doesn't exist in reality, we are just told that we aren't allowed to drive 50 on a 110 highway. However this is implemented as a game feature to solve a problem.

If we made the same kind of speed boards for trains we could easily solve the same issue without adding way points. When the train looks for a path, it will tray to select the fastest (km/h) path. This solves a problem and adds to the realism in Simutrans, without having a counterpart in the real world.
Title: Re: Distant signals
Post by: Vladki on May 11, 2013, 12:24:50 PM
Quote from: Max-Max on May 11, 2013, 12:14:14 PM
If we made the same kind of speed boards for trains we could easily solve the same issue without adding way points. When the train looks for a path, it will tray to select the fastest (km/h) path. This solves a problem and adds to the realism in Simutrans, without having a counterpart in the real world.

Minimum speed signs for railroad exist - see here: http://forum.simutrans.com/index.php?topic=10813
Title: Re: Distant signals
Post by: Max-Max on May 11, 2013, 12:26:28 PM
Great! Problem solved :)
Title: Re: Distant signals
Post by: AP on May 11, 2013, 03:07:29 PM
Quote from: Vladki on May 11, 2013, 12:24:50 PM
Minimum speed signs for railroad exist - see here: http://forum.simutrans.com/index.php?topic=10813
They just aren't in all paks yet (e.g. not in Pak.britain or pak.britain.experimental, although eagerly awaited!).
Title: Re: Distant signals
Post by: Max-Max on May 11, 2013, 03:47:22 PM
Yes, I figured that if the code is in place :)

James,

I'm starting to have some questions about the actual code now... Should we do this in a new forum thread?
Title: Re: Distant signals
Post by: jamespetts on May 11, 2013, 09:35:39 PM
Merry - thank you for your contribution: that is most detailed and helpful.

Max-Max - yes, it is probably sensible to have a separate thread about the coding mechanics of this, and this thread can remain comprehensible by non-coders to discuss in principle how things ought to work.

Thank you all very much for your contributions to this subject!
Title: Re: Distant signals
Post by: Max-Max on May 11, 2013, 09:40:30 PM
One more thought...

The current implementation of distant signals (pre-signals) stops a train if the next signal isn't clear. This creat a chain reaction where all cascading distant signals has to be clear before the path up to the next main signal is clear.


---t2>---P2-\
            |    /---S1
---t1>---P1-+-C-+----S2
                 \---S3


Asume train t2's path goes through pre-signal P2, chose signal C to enter a free station S1 to S3. If S1, S2 and S3 are occupied we don't want t2 to stop in front of C blocking t1. With the distant signal we have talked about here, this scenario hasn't been addressed. How do we create the current pre-signal behaviour in our "new" system? It is basically a main signal with a condition; show clear if we can reserve path to next main signal.

Maybe we need to add one more rule to our basic needs of signal functions?

James asked what benefits we would get out of a parser? The parser is a structured way to easily classify characters and words. With a parser we can do proper syntax check and add reserved words in a centralised way.

This could be handy when we define our new signals and their states (.dat file).
Title: Re: Distant signals
Post by: jamespetts on May 11, 2013, 09:52:56 PM
Hmm - would the solution in the above scenario not simply be to remove signal "C" and replace "P1" and "P2" with choose signals? As to the parser, can you elaborate on how this would be used in practice, perhaps with an example? I am not sure that I really follow.
Title: Re: Distant signals
Post by: Max-Max on May 12, 2013, 01:59:27 AM
The signals was just an example, maybe a bad one. Okay here is another one.

---<-B1-\
t1->-B2-+-<->-+--<->--
              |
              \-P--<-t2


Train t2 wants to go on the green path, P on to a 2 way track turn make a turn to block signal B1 on a one way track. In this case B1 shows STOP. Without P, t2 would occupy the double way line and wait for B1 to clear. Meanwhile train t2 comes but has to wait for B1 to get t2 out of the way before B2 shows clear.

If we put P into place, t2 will stop at P instead and t1 can pass meanwhile t2 is waiting for B1 to clear.

One may argue that B1 can be moved just further away, but since it is a block signal, this would not help, unless B2 is a pre-signal. There can be other reasons why B1 can't be moved. Again this is only an example to show how powerful the pre-signals are today. I use them all the time to keep waiting times as short as possible and not block the line.

Regarding a parser.
I don't know if you are familiar with a "standard" compiler/interpreter design. The scanner classifies each character such as white space characters, digits (0-9), letter a-z and A-Z, symbols etc... These are then turned into tokens such as integer, real, reserved words etc...

The parser basically asks the scanner for the next token and executes its. It doesn't need to know anything about white space or how to read a number. From there you can add simple expressions such as 2+3*6-(alpha/beta). The dat files could with some effort have small "scripts" defining the signal's function.

signal(mainSignal) {

  States {
    Clear:
      Block(1) status clear

    Stop:
      Block(1) status not clear
  }
}

Here we define a "mainSignal" and the condition to signal "Clear" is; the following block has to be clear. A stop condition is when the following block is not clear.

To create a combined main and distant signal one may script:

signal(comboSignal) {

  States {
    Clear:
      Block(1) status clear
      Speed(UK)

    caution:
      Block(1) status clear and Block(2) status not clear
      Speed(UK)

    Stop:
      Block(1) status not clear
      Speed(0)
  }
}


These is only brainstorming, but with a parser it is more easy to implement some more flexibility into the .dat files.
Title: Re: Distant signals
Post by: TurfIt on May 12, 2013, 02:08:27 AM
Quote from: Max-Max on May 12, 2013, 01:59:27 AM
The signals was just an example, maybe a bad one. Okay here is another one.
You've just shown the exact use for Simutrans two block signals (those signal with the unfortunate pre-signal name stuck to them). In real life, signal P would not be an automatic signal. It would be controlled by a signaler/dispatcher who would make the regulation decision on whether T1 or T2 should go first. Simutrans signals are all automatic, and hence sometimes need different logic from any real life signal to prevent deadlocks. Unless someone cares to implement a super smart dispatcher algorithm, real life signaling cannot just be inserted and expected to work...
Title: Re: Distant signals
Post by: Erik on May 12, 2013, 07:41:52 AM
Sometimes I'm thinking about how to make the route search and signaling smarter. It will be nice to have that the trains aren't jammed each other in a circle when the train network gets more complicated.

I use Pre-signal barely by my self. Mostly I prevent to need them, because often they will work for the one direction but not for the other.

About programming.
The current Pre-signal (a.k.a. 2Block signal) has something like this:
Signal(Pre-signal){
   if(first block clear){
      if(next signal clear){
         Clear
         }
      else {
         block
      }
   else {
      block
   }
}


So for the distant signal it has to become:
Signal(Pre-signal){
   if(first block clear){
      if(next signal clear){
         Clear
         }
      else {
         Limit speed()
         Clear
      }
   else {
      block
   }
}

Title: Re: Distant signals
Post by: jamespetts on May 12, 2013, 11:36:16 AM
As to your example, what is the purpose of signal B1? Can it not be removed entirely? If a train will only ever get to approach it if it is clear (by going through P1), then is exactly the same effect not achieved by removing it and letting trains wait until they have a clear path through to the next signal? Indeed, is that not generally the answer in pre-signal cases: to remove the first stop signal along the line so as to make the block twice as large? Currently, pre-signals might be useful where some trains do and some trains do not stop at a station (with its implicit signal, making variable length blocks depending on stopping at stations); but, if this functionality is removed, it seems difficult to imagine this being relevant.

As to the parser - you mean effectively having our own scripting language for signals? Interesting, certainly, but perhaps a tad ambitious? There is a great deal of coding to go into that, and therefore a great deal to go wrong. Are we sure that what can be achieved with this cannot just as well be achieved with a few conventional parameters, and, if so, that the extra that can be achieved is on its own worth all the work of writing then debugging a parser?
Title: Re: Distant signals
Post by: Max-Max on May 12, 2013, 01:26:59 PM
Even if B1 is moved you may end up with a train in front of it. If train t2 doesn't block t1's path, it is inside the B1 block, preveting B1 from showing clear.

Maybe I have missed something here... I use pre-signals all the time, can't imagine how to be without them. I will try to play around without the use of any pre-signals to see how that would be done.

But I can see now how this would work in a new system (thank you Erik) :)

signal(preSignal) {

  States {
    Clear:
      Block(1) status clear and Block(2) status clear

    Stop:
      status not clear
  }
}


When it comes to the parser, I think the code will be a lot more clean and more stable if we had a parser, even if it only supports the .dat files of today.

In the future it would be quite easy to implement more functions. In theory we can create different parser objects for different type of .dat files, without involving code scattered all over Simutrans. We already have a symbol table, but it is only used to insert symbols (when parsing .dat files). We could easily also use it for using variables values in the .dat file like (again just an example)

BaseDir= ./images/signals/
signal(combo3blockSignal) {

  States {
    Clear:
      Block(1) status clear and Block(2) status clear and Block(3) status clear
      // set speed and other params for this condition

    Caution1:
      Block(1) status clear and Block(2) status clear and Block(3) status not clear
      // set speed and other params for this condition

    Caution2:
      Block(1) status clear and Block(2) status not clear
      // set speed and other params for this condition

    Stop:
      status not (Clear | Caution1 | Caution2)
      // set speed and other params if next block status isn't one of the above
  }

  image[Clear] = BaseDir + sg01
  image[Caution1] = BaseDir + sg02
  image[Caution2] = BaseDir + sg03
  image[Stop] = BaseDir + sg04
}


If we have different variants we would like to test in the development process, we can simply just change BaseDir.
I'm not saying we should implement all this scripting right away, but if we have the vision in mind, we can design the code to be prepared for it. This small snippet is just a thought of how it might work. The state definition isn't static, the PAK designer can define his own states and attach graphics to it.
Title: Re: Distant signals
Post by: Max-Max on May 12, 2013, 02:06:57 PM
James,

I forgot to reply on your comment regarding:

QuoteThe challenge with (1) is that we also need to give feedback to the signals behind us, up to X blocks, so they can be updated correctly as we pass each signal. One thought that comes to my mind would be to have the train carry a list of passed signals and remove them when we past the signals range.

The thought came up on the topic of 3,4,x aspect signals. Elaborate on the following setup:

---t1>---A3------B1------B2------B3------B4------

Train t1 aproach a 3 aspect signal A3 (maybe the wrong term here, but what I mean is that it shows the status for 3 blocks ahead, you get the picture). Block B1,B2,B3 and B4 are clear so A3 is reflecting this state.

When the train pass B1 the aspect signal is updated, now one block behind t1.
------A3------B1--t1>----B2------B3------B4------

As the train moves, the A3 signals needs to be updated for each block t1 passes.
------A3------B1------B2--t1>----B3------B4------

------A3------B1------B2------B3--t1>----B4------

------A3------B1------B2------B3------B4--t1>----

A3 will be located further and further away from the train and because the train is driving the signal, it needs to know where it is and when to stop updating it.

But I think I have a solution for it (as I mentioned before). This is why I think
Quote...need to give feedback to the signals behind us, up to X blocks...
is needed.
Title: Re: Distant signals
Post by: Erik on May 12, 2013, 02:28:38 PM
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.
Title: Re: Distant signals
Post by: Max-Max on May 12, 2013, 02:32:25 PM
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.
Title: Re: Distant signals
Post by: jamespetts on May 12, 2013, 05:00:39 PM
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.
Title: Re: Distant signals
Post by: Vladki on May 12, 2013, 06:01:18 PM
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.
Title: Re: Distant signals
Post by: 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.
Title: Re: Distant signals
Post by: Vladki on May 12, 2013, 06:26:08 PM
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.
Title: Re: Distant signals
Post by: 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.
Title: Re: Distant signals
Post by: 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.
Title: Re: Distant signals
Post by: Erik on May 12, 2013, 07:43:26 PM
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.
(http://machinistlog.nl/blog2010/wp-content/uploads/2011/09/diefstal-3-300x150.jpg)

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.
Title: Re: Distant signals
Post by: jamespetts on May 12, 2013, 08:10:03 PM
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:

(http://farm1.staticflickr.com/147/401846592_909f104c96_z.jpg?zz=1) (http://www.flickr.com/photos/iandh/401846592/)
shunt-limit_p1350622 (http://www.flickr.com/photos/iandh/401846592/) by iandh (http://www.flickr.com/people/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?
Title: Re: Distant signals
Post by: Ves on May 12, 2013, 10:00:10 PM
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......
Title: Re: Distant signals
Post by: Max-Max on May 12, 2013, 10:21:07 PM
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:

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.
Title: Re: Distant signals
Post by: jamespetts on May 12, 2013, 10:32:22 PM
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)?
Title: Re: Distant signals
Post by: Max-Max on May 12, 2013, 11:50:26 PM
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.
Title: Re: Distant signals
Post by: 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?
Title: Re: Distant signals
Post by: Ves on May 13, 2013, 08:38:13 AM
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. :)
Title: Re: Distant signals
Post by: prissi on May 13, 2013, 02:10:16 PM
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.
Title: Re: Distant signals
Post by: Max-Max on May 13, 2013, 06:41:20 PM
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.
Title: Re: Distant signals
Post by: prissi on May 13, 2013, 09:31:11 PM
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.
Title: Re: Distant signals
Post by: Erik on May 14, 2013, 06:05:59 AM
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.
Title: Re: Distant signals
Post by: merry on May 15, 2013, 12:16:21 PM
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
Title: Re: Distant signals
Post by: 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.
Title: Re: Distant signals
Post by: HDomos on May 16, 2013, 12:54:21 AM
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 :)
Title: Re: Distant signals
Post by: Erik on May 16, 2013, 06:56:11 AM
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.
Title: Re: Distant signals
Post by: sdog on May 16, 2013, 09:18:04 PM
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!
Title: Re: Distant signals
Post by: jamespetts on May 16, 2013, 09:48:07 PM
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.
Title: Re: Distant signals
Post by: sdog on May 17, 2013, 01:53:22 AM
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

*<-
  ->*
Title: Re: Distant signals
Post by: prissi on May 17, 2013, 02:05:51 PM
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.)
Title: Re: Distant signals
Post by: ӔO on May 17, 2013, 02:36:33 PM
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.
Title: Re: Distant signals
Post by: Erik on May 17, 2013, 03:36:48 PM
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.)
Title: Re: Distant signals
Post by: Vladki on May 17, 2013, 07:39:08 PM
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 ;)
Title: Re: Distant signals
Post by: Ves on May 17, 2013, 09:59:24 PM
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'.