News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Distant signals

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

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

Interesting. Which of the two tool types is correct?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Dwachs

Parsley, sage, rosemary, and maggikraut.

jamespetts

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.

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?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Max-Max

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.
- My code doesn't have bugs. It develops random features...

jamespetts

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?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Max-Max

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)?
- My code doesn't have bugs. It develops random features...

jamespetts

#41
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 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 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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Erik

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.


jamespetts

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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Max-Max

#44
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?)
- My code doesn't have bugs. It develops random features...

jamespetts

#45
Sorry that you're having trouble with Github - have a look here for a list of Git tools that give a GUI and, I think, comparison tools. I use this 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 for Git for Windows, or have a look at one of these.

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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Max-Max

Thanks, I will have a look...
- My code doesn't have bugs. It develops random features...

isidoro

After reading this topic, I have some questions about it:

       
  • What happens if a player doesn't place those distant signals at appropriate distance for the train to brake properly?
  • And if that is not a problem because an infinite braking power is supposed, what is the purpose of these distant signals?  Only eye-candy?
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?


jamespetts

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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

eipi

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/.

Max-Max

@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?
- My code doesn't have bugs. It develops random features...

jamespetts

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...
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Erik

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.


Max-Max

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?
- My code doesn't have bugs. It develops random features...

jamespetts

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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Max-Max

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.
- My code doesn't have bugs. It develops random features...

isidoro

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?

Max-Max

@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.
- My code doesn't have bugs. It develops random features...

jamespetts

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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Erik

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.


Max-Max

@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.
- My code doesn't have bugs. It develops random features...

greenling

Hello on all
Gave it in Britain Signals they have a Distant signal on a choosesignal or blocksignal?
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

kierongreen

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.

Max-Max

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.
- My code doesn't have bugs. It develops random features...

jamespetts

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).
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

kierongreen

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.

jamespetts

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).
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

kierongreen

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).

jamespetts

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?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

isidoro

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).