New signals - coding

[jamespetts]

If we can't handle (2) in a coherent and realistic way that does not allow for exploits, I don't think that we can have speed signals.

[Max-Max]

The distant signal is meaningless in the sense of; If you put a distant signal within the needed breaking range of a main signal, it becomes meaningless because the driver will see the main signal and the distant signal at the same time. In this case he goes for the main signal, just common sense...

In the real world this wouldn't be a case, so this is only a game technical scenario.

[jamespetts]

Then what incentive do players have to place speed signals at all?

[merry]

To answer James directly: none, in the current setup!
This of course assumes that the train brakes at the correct distance for a stop signal.
If using a Uk-style semaphore distant, this is only allows for correct sighting distances to be implemented such that the stop signal can be stopped at. In the same way, banner repeaters are used closer to a stop signal when sighting is difficult, to allow sensible braking behaviour. Banner repeaters are even used in MAS areas with poor sighting.
The result of this is that the true 'distant' in a ST semaphore installation (not speed signalled) is pointless.

Hmm. I've done a bit of thinking while writing the above.
IRL, signal spacing is done based upon max line speed - which is in ST the track speed - and standard braking curves. If a train can't brake from full speed in the standard braking distance, then it has to run at a lower max speed.
Logically, in ST, the signals can 'know' the max track speed. If a signal is too close to the one in advance, then the signal in rear would be held at an aspect that reduces speed to a safe braking distance, or at a safe approach speed for the too-closely spaced signal. I suppose this could even apply to distants if one wished. Lack of appropriately positioned distant means less than full speed on the approach from previous signal.
The above would apply to semaphores and MAS, as well as fixed-block speed signals as used in some countries (speed signalling with automatic block or absolute block equivalents). Speed-signalling is still block based, until it is a moving block transmission based systemand actually the speed indications are effectively an overlay onto a multiple-aspect system where appropriate speed is indicated and does not depend as much on the driver's route knowledge.
With Moving Block Transmission-Based Train Control (MB-TBTC) the signals are a bit irrelevant - approach braking to a restriction or stop will always be at a distance suited to the speed and braking characteristic of the train, and signals don't have the same meaning.
Hmm. If there is MB-TBTC and fixed signals, a non-MB-TBTC train could use the line subject to the fixed signals, and MB-TBTC trains could proceed according to the train control requirements. MB-TBTC control systems would ensure that the signals and transmitted controls maintain appropriate spacing, speeds, and protection.

Now, in ST, all the above can be implemented alreay with only a few tweaks to the existing. MB-TBTC is almost like driving with a regularly updated reservation in front of the train, equal to the braking distance plus a bit extra. Regular signals need to provide protection and indication (which may include speed) based on suitable spacing as described, but otherwise operate as normal, and trains need to obey the signals!
I'm sure that's an oversimplification, but you get the idea.

Hope this helps, it might even provide a framework to proceed - we'll see!

[Max-Max]

James, can 't you just accept that there is a world outside UK where signals work different from what you are used to. No one will force you to play with our signals, you can still use the UK style. But the rest of us would like to, as much you like your UK system, we would like to use our system in our countries. Not all of it will make sense to you but it does to us.

Then what incentive do players have to place speed signals at all?

As much we can place a distant signal next to a main signal, so can you, but do you do it? Of course not, because it's not practical nor realistic. We don't ban the UK style because we don't use it in our countries.

Another example, why would we have cars driving on the left side in Simutrans? I'm not using it for sure. What incentive do players have to drive on the left side at all?

[jamespetts]

Forgive me if I appeared to be hostile to non-UK signalling systems: that is not the intention. However, there is no point, I think, in having code for speed signals if the player is better off not placing them than placing them. The distant signal system (and a distant signal is not the same as a speed signal) that I originally outlined contained a strong incentive to place them (and place them in the correct places): without them, all trains would approach all stop signals, whether they were at danger or not, slowly enough to stop for them until getting within their sighting distance, which would involve trains slowing very significantly for each signal even if all were clear. It would be considerably more complicated (but probably possible) to provide an equivalent incentive to place speed signals. If a way of doing this can be achieved (which is pakset dependant and compatible with also having UK based signals defined instead), then that is one thing: but it would not add to the game to simulate signalling in such a way that a substantial part of that simulation is made redundant because the reason for having signals of that type at all in the first place is not adequately simulated.

I am afraid, however, that Merry's system, ingenious as it is, of calculating the speeds of speed signals using line speed is not, at least without considerable modification the details of how to accomplish which are by no means apparent, something that would work, for two reasons: (1) the tile of track on which a signal is placed might have a different speed limit to the preceding tiles, meaning that the speed could be significantly under-calculated or over-calculated; and (2) different trains can have different physical braking characteristics (sometimes quite widely different during eras in which some trains are continuously braked and some are not). There is therefore insufficient constancy in the starting data from which to produce reliable general calculations of speeds applicable to all trains from a given signal, rather than a train working out its own maximum speed based on a distance to a possible or certain stop or reduction in speed.

As to the analogy of driving on the left or right, I do not think that that is applicable, as the side of the road on which vehicles drive is entirely cosmetic, whereas signalling is economically significant, and it is important to simulate that economic significance, which is, as I understand it, the aim of a project to improve the realism of signalling. Given that real life signalling is economically significant (how a line is signalled will determine its speed and capacity, but installing and maintaining different signalling systems have different costs, and changing/upgrading a signalling system also has a significant capital cost), it would be anomalous when simulating the details of any given signalling system, such as speed signals, not also to simulate their economic significance. Whether one drives road vehicles on the left or the right, by contrast, has no or virtually no economic significance, so one would not expect this to have any economic consequences in the game.

In short: if we are simulating something that in real life has economic consequences, we should make sure that we can give it those economic consequences in the game, too. It is more confusing to players to appear to simulate something, but not actually simulate its economic consequences, than it is not to simulate it at all.

[Max-Max]

But you are missing a significant UK side effect in the current system. As you said, the driver has to know the line he is driving on, but what happens if he is ill? If there is no one else to operate the train with the right knowledge of the track? What happens then? What impact will it have on the system to bring in someone on short notice or just cancel the route. Think of all the costs involved in delayed deliveries or worse, cancelled routes.

In a non UK system, anyone can operate the line, with or without knowledge of the track. All he needs to know is how to operate the train. So the economic simulation isn't in place anyway.

So why do we have distant signals at all in Simutrans, if the train stops at the main light anyway? In Europe a distant signal is very often combined with a main signal (built into the main signal as I showed you earlier). The main signal is showing the status for the following block and the distant signal the status of the next main signal (next block).

So if the next block is free, the main signal shows clear (green), but assume the next block after that is occupied, the distant signal shows a speed limit. Now the train ahead is going at full speed and this train at reduced, meaning that when it comes to the next block it is most likely clear and the train can proceed at full speed and don't have to stop.

If the speed limit hasn't been there, the train might have caught up with the train in front of it and forced to stop at the next main signal. To stop and start a train is very time consuming and can easily clog up your line. With the speed limited distant signal, the train slows down to give the train in front of it a chance to clear the block before it reaches it.

So there you have your game effect of speed limited distant signals.

[jamespetts]

If such a side-effect were significant, then it would simply be a general overhead, and would be automatically taken into account when calibrating the pakset based on country-specific data (such as the profit to revenue and turnover to capital ratios of real UK transport companies in the eras modelled by Pak128.Britain-Ex).

We do not, at present, have distant signals in Simutrans. We have a special Simutrans-specific type of signal called a "pre-signal", which, because no real life equivalents exist, often uses the graphic from distant signals. The pre-signal does not function like a distant signal at all, but has its own specific function. This is potentially confusing for players, and I am rather hoping that any overhaul of Simutrans-Experimental's signalling system will remove the need for this anomaly.

Thank you for that interesting description of a function of speed signals. Do speed signals actually work this way in real life? If they do, in places where they do operate like that, is there a separate mechanism for ensuring that the trains can stop in time for the next stop signal, or is this part of the speed signalling system? Whatever the country, any railway signalling system has to overcome this basic constraint of physics somehow (that drivers cannot see stop signals far away enough to stop in time for them unless they are going very slowly), and it is necessary that any revised signalling system in Experimental simulate the means to overcome this in a way that is consistent with the way in which the rest of the signalling system in Simutrans-Experimental works/will work. The only way that I can think of doing that for speed signals (if the speeds are themselves used as means of slowing the trains enough to stop at subsequent stop signals) is to have a rather elaborate system of either not permitting players to place signals too close together (but that would not account for different braking performances of different trains), or have the speeds set dynamically depending on the braking performance of the train and the distance to the next signal rather than fixed in each signal (which would make the system almost, albeit not quite, like the UK system).

[merry]

hi Guys,

Well, an interesting debate:.

mad-max: the system you describe of 'distant' and 'stop' signals combined in one signal head is Multiple-Aspect Signalling (I abbreviated this MAS as per UK practice, sorry if it confuses, but it's simple). The use of speed signalling enhances the caution and clear aspects in most such systems to help the driver; the UK has considered this unnecessary and relies on route knowledge.

Interestingly enough, a driver in a speed-signalled system in any country still has to know the route: braking distances for stations and the effect of gradients make this essential anywhere. Station stops at the platform are very much appreciated by passengers, and freight train braking distances are very different from passenger services, which means a driver must know when to apply control to stop safely in the right place but not waste fuel or time - it is a most skilled job wherever you are. If route and traction knowledge is not enforced, at best it's missed stops or lost time, and at worst accidents ensue! So i don't think either James or mad-max's economic arguments are really relevant on that front. Let's move on!

If we are considering speed-signalling, this is a relatively modern invention: before MAS and speed signalling, there were semaphores [and 2-aspect colour lights, as still used on London Underground] with absolute block control or equivalent (if you were lucky, otherwise rather unreliable time interval operation with all the inherent safety risks...let's not go there for ST even if it is prototypical in 1850). In almost any country, these were i understand largely equivalent to UK practice at the broad level. 1 block=1 train. Absolute block is not a bad place to start and if we can get that to work sensibly then the add-ons of speed signalling, multiple aspect, etc are going to be easier.

See my last post for suggestions of how the effect of signal spacing might affect train speeds between signals.

Reading mad-Max and James' contributions, I also am persuaded that the true 'distant' (UK or other) would play no/little useful part in ST unless used as part of a signal spacing rule.
BUT, if you don't have distants, then they must be implicit, to allow trains to have appropriate sighting distances in longer blocks when running at or near line-speed, for braking physics to work sensibly. That in turn means the signal spacing - until too close (and maybe not then) - will not affect train speed. So perhaps this discussion then directs the focus of work: if we don't need explicit distants, and braking distances already consider the implicit 'distant', then speed signalling is implied! (and the similarity between apparently different national approaches is revealed to be greater than the cosmetic differences might suggest)

Should the focus then be  to sort out the issues that cause 'presignals' to be needed, and the 1-way / reversible signal issue (which actually makes the pre-signal necessary in the first place) ?

Hope this is helpful in summing up the debate, and not too biased towards UK or any other practice.

TTFN
Merry

[jamespetts]

We can, I think, have true distants: what we cannot (at least not without very great difficulty) have are signals where the speed is set in the .dat files. A halfway house sort of speed signal where the speed is set dynamically might be possible, but I do not know how useful that that would be.

To have working distant signals, one would follow the system that I think that I described on the original signalling thread. It would be assumed that drivers had route knowledge, and knew where all the signals were, but not what their aspect was until they are within sighting distance. Therefore, a train would have to be travelling slowly enough by the time that it reached the sighting distance of any signal which might be at danger to stop in time for that signal. Without distant signals, all stop signals would be considered to be signals which might be at danger, and all trains would have to slow to a stoppable speed within sighting distance of all of them, even if they were all clear. A distant signal would be able to give the indication that the next stop signal was clear, so the train would be able to proceed at full speed and not slow down within the sighting distance of that signal. That system is simple enough, and would give real meaning to distant signals, as well as being easy to adapt for multiple aspect signalling (including four aspect signalling, the details of which are described in more detail I think on the original signalling thread).

As I understand it, speed signals prescribe a maximum speed at which a train may travel once it has passed that signal until it reaches another signal giving a different indication. The reason for that speed limit is, I understand it, to permit the train to be going slowly enough either to stop in time for the next signal that might be at danger, or to slow down enough in time for the next speed signal showing a lower speed. For the reasons already outlined, it is unlikely to be practical to have speed signals which have a single, fixed speed set in the .dat files, as that single, fixed speed depends on their spacing, which cannot be known when the signal is coded. It is possible, however, to have dynamic speed signals, which base the speed that they indicate on the distance to the next signal or speed restriction in the train's actual route and the braking characteristics of the particular train. The only difference in practice between this and the UK system in Simutrans would be that, in this system, the trains would have to slow down fully once they reach the speed signal, whereas in the UK system, they would not have to slow down until later. It would add a fair bit of complexity to the code to work out in advance what the speed would be, rather than relying on the existing code for braking in advance of something, but it would be possible. The question is - for this relatively modest difference from UK practice as I have set out as being simulated - is it really worth the difference? Can graphics for speed signals in paksets representing the signalling practices of countries that use them not simply be paired with definitions of multiple aspect signals, which would work almost (but not exactly) the same as the dynamic speed signals that I propose here?

[Erik]

@ James: Interesting vision. A train has always to drive the capable speed to stop or reduce speed for when the signal comes in sight. So that the train can react on that in time.

Abouth putting multiple speed limits in the .dat file. I'm working on that to make it possible. Also I will make it possible to get complete other settings. Like the dependence of distance to the next signal.

But it's a hard part to get trough.

[neroden]

Modern signalling design follows a rather different set of rules.  For one thing, cab signals are standard now.

The basic principle of absolute block signalling is very simple: Trains always travel at a speed such that they can come to a full stop before entering the first *occupied block*. 

A block may be effectively considered "occupied" due to (a) actually having a train in it, (b) being under construction, (c) having a different train scheduled to arrive in the block in the near future (block reserved) (d) having switches in an interlocking set improperly for the train which is considering entering the block.

"Home signals" control access to the interlockings, and every other signal in the system is designed simply to show speed to the next block.  In fact, in modern systems the *only* signals are in the cabs.  The train driver (engineer) does not need route knowledge -- because the *dispatcher* has route knowledge and is setting the signals according to his route knowledge.

Every earlier signal system was a half-assed attempt to do absolute block, and the newest so-called "moving block" systems are actually pure absolute block systems (albeit with very short blocks, often shorter than one train).  Accordingly, I think we might as well implement the correct system of signals.  If we can.  Implementing it properly is actually hard.

At the moment, simutrans signals act as block boundaries.  So far so good.  There is a proper block reservation system.  So far so good.

However, simutrans currently attempts to implement dispatcher procedure with signals, and that doesn't really work.  Currently simutrans has only three types of dispatcher procedure, and each of them is tied to a signal: (1) reserve until next station ('choose signal'), (2) reserve one block ahead ('standard signal'), and (3) reserve two blocks ahead ('pre-signal'). 

Now, nobody can replace a manual dispatcher.  But here's some ideas.  What I think should actually happen is this. 

- Standard signals continue to act as block boundaries in the forward direction, but not in the reverse direction.
- Signals should point in one direction only.  It should be possible to place one type of signal in one direction and a different type in the other direction.  The classic example would be a forward signal and a reverse "do not enter".  For a short link line which could be used bidirectionally, it would have a (home) signal at the exit of each end but free entry from both ends.  (Obviously if part of it was reserved, then trains trying to path through it in the other direction would not succeed.)
- As a result of the fact that trains might have to wait for one-way sections, trains would need somewhat more lenient numbers of retries before they decided that they had no route.  In fact, to get this working right, trains which are waiting for a block to clear should probably be in some sort of priority queue.
- For fast trains.  By default, every train should reserve as many blocks ahead of it as it takes to (a) get up to top speed, and then (b) stop from top speed -- or to the next station, whichever comes first. 
- A special signal (sign, really) should say "do not reserve blocks beyond this point in this direction unless you are right here" (to give  branch line trains lower priority for entering the mainline, for example).
- The 'choose signal' should select a route but should not reserve it.  A separate signal should reserve the rest of the way to the station.

Of these, I think the "one-way" aspect of signals is the most crucial for improving the signal system, as it would make single-track lines practical.  We already have per-tile block reservation.  There is no reason I can see why all signals have automatic prohibition of reverse traffic.  If you want to prohibit reverse traffic, you can do so with additional signs.

[jamespetts]

Current signals in Simutrans do not automatically prevent reverse traffic: they actually have a bidirectional mode set by default (which is equivalent to two identical signals facing in opposite directions). Only the (optional) unidirectional signals prohibit trains going in the opposite direction.

As to cab signalling and moving blcok - this would indeed be worthwhile to implement. Indeed, the current signalling in Experimental is approximately similar to cab signalling (distant signals are not necessary, drivers are assumed to know where the next stop signal is and stop in time for it). It should be noted, however, that cab signalling is the exception rather than the rule in the UK, used only for the high speed line, and likewise moving block (used in a few slow speed urban networks as well as the high speed line). Ordinary main line railways still use multiple aspect absolute block type signalling.

I wonder also whether it is worth setting certain properties in a train's timetable related to signalling: setting different priority levels, for example, and having two types of block reservation: (1) actual reservation, as the current reservation system; and (2) provisional reservation (perhaps marked yellow in the game), ahead of where the actual reservation needs to be for stopping purposes, but can be cancelled by a higher priority train attempting to reserve the same tiles. This would allow for prioritisation of express over local trains etc..

[greenling]

Hello all
I think that's the new signals code as first need a reseach of all existence signalsystems in the world.
Than can we creat a new signal code.

[Max-Max]

There are what I know of two major systems; the European and the UK. I don't know if Japan and China has a third system or not.

James do have a point here, how do we translate this to something useful in the game, more than a cosmetic effects (if that is a must).
One issue to deal with is when a user place a European distant signal to close to the main signal. I say the main signal will precede the distant signal in this case. Another way is to prevent the user to place them too close, but as James said, the distance needed to slow down depends on the trains total mass and break capabilities, so how do we know if it is placed too close?

[jamespetts]

Max-Max - what do you mean by "precede the distant signal" here?

[Max-Max]

If the train reaches a main signal, start to break and then passes a distant signal (placed to close to the main signal) showing at danger, it is preceded by the main signal because the train has already started to break. Meaning its existence is pointless (the distant signal)

[jamespetts]

Ahh, yes, I see what you mean; the important thing is that there is a realistic incentive to place distant signals of any type, and disincentive not to place them or to place them too close to the stop signals that they serve to protect.

[sdog]

When you introduce such thorough changes of the signals, please also make sure help texts in game are up-to date and available. This could easily be too complicated to grasp it intuitively alone, providing endless frustration to players. For (i) railway signalling is complex and might not be well understood even by inclined players, (ii) it is also different almost everywhere leading to false assumptions, (iii) might be even less understandable when introduced at the present scale of simulation and display thereof.

Interestingly enough, a driver in a speed-signalled system in any country still has to know the route: braking distances for stations and the effect of gradients make this essential anywhere. Station stops at the platform are very much appreciated by passengers, [...]

OT: I remember seeing a station master taking pulling a tape measure from his pocket measuring the distance between a marking on the platform and the first door of each EMU arriving. Regardless how tiny the distance appeared to me, each operator was reprimanded, 2007 at Tokyo Ikebukuro station.

ps.: Glad Mittsommar! ( a little late...)

[jamespetts]

It is an interesting question as to what to do with the help texts, since, as you point out, each country's (and therefore each pakset's) signalling systems are (will be) different, yet the help texts generally come with the base game not with the paksets...

[Max-Max]

On though that came to my mind when I was supposed to sleep; We can select left or right side traffic, so why not also be able to select UK or European signal system?

This would simplify the help file as well, because it knows what system you have selected. Same graphics can be used in the pak files, the only thing changing is the behaviour.

[Erik]

I was thinking about determine it by the signal it self in the .dat file. But about the help documentation that could give some problems.

[Max-Max]

Erik, that was my though too, but James have a point here. How do we follow up with documentation? And would we need the ability to mix UK and non UK signals?

Tricky problem to solve...

[Erik]

I know.

One way to do it is by start coding. Make it possible to try something out and see which solutions will fit nice.
This will give much more insight about the possibilities. (At least it will do that for me.)
After that, revisit the results and discuss what is suitable for Simutrans.

I've just uploaded to my github fork in the signals branch about what I've got now.
Unfortunately, it isn't compilable now. (I'm still stuck with the writer and reader.)

[kierongreen]

While it's easy to label the current signalling system as "British" the reality is that the signalling system is the way it is because it best handles traffic in the simulated world. The original developer was German after all so had no vested interest in simulating British signals. Speed based signalling would be an unnecessary complication that would require lots of micromanagement to have any real benefit.

[jamespetts]

As indicated in a previous post, the only way of approximating speed signalling in Simutrans that I can see would be to use almost the same system as I had proposed before when considering UK signalling, except that the trains would have to slow to the signal sighting distance speed on reaching the previous signal, rather than on reaching the sighting distance of the next signal. Such a small variation does not really need multiple sets of help texts, in fact: a single help text can explain both systems. It would be simple to have a single property in a signal's .dat file making it a speed signal if necessary.

(Indeed, it should be noted that the implementation that I have previously described is not an exact reproduction of UK signalling, but a workable approximation: in the UK, the line speed itself would depend in part on the signal spacing on a line, whereas in the implementation that I describe, the speed in so far as it is referable to signal spacing would be calculated and applied individually for each train; this seems to me to be no more distant approximation of UK signalling than the speed signal variant that I describe to be of continental European signalling).

[neroden]

Current signals in Simutrans do not automatically prevent reverse traffic: they actually have a bidirectional mode set by default (which is equivalent to two identical signals facing in opposite directions).

That's an almost completely useless mode, however.  What you actually need is "This is a signal in one direction, and it is not a signal in the other direction." 

The only way of implementing bidirectional running without passing sidings is to have *one* direction be the "direction of traffic", with multiple blocks, and for the reverse direction to reserve *all* the blocks.

(Edit: I should note that the British apparently never figured this out, and as a result built an awful lot of passing sidings, generally one at every station plus more.  The method of signalling I describe is a standard method of operation in the US and IIRC Australia, however.   There is a more sophisticated method which *sets* the primary direction of operation, and can change it when the entire line is clear; that would require substantially more complicated coding.)

Only the (optional) unidirectional signals prohibit trains going in the opposite direction.

Those are the only usable ones in the current version.

As to cab signalling and moving blcok - this would indeed be worthwhile to implement. Indeed, the current signalling in Experimental is approximately similar to cab signalling (distant signals are not necessary, drivers are assumed to know where the next stop signal is and stop in time for it). It should be noted, however, that cab signalling is the exception rather than the rule in the UK, used only for the high speed line, and likewise moving block (used in a few slow speed urban networks as well as the high speed line). Ordinary main line railways still use multiple aspect absolute block type signalling.

It's just an approximation to what is desired; as they're being rebuilt they're all becoming cab signalled.

The real issue is that simutrans does not separate *signalling* from *dispatching*.  The *signalling* in simutrans is mostly implemented OK, with the exception of the absence of proper "one way only" signals, as I noted. 

The *dispatching* in simutrans needs a lot of work.

I wonder also whether it is worth setting certain properties in a train's timetable related to signalling: setting different priority levels, for example, and having two types of block reservation: (1) actual reservation, as the current reservation system; and (2) provisional reservation (perhaps marked yellow in the game), ahead of where the actual reservation needs to be for stopping purposes, but can be cancelled by a higher priority train attempting to reserve the same tiles. This would allow for prioritisation of express over local trains etc..

That would be a very loose attempt to approximate a separation of dispatching and signalling.  Let's take a lesson from real railroads and real model railroads: what we need is a *proper* separation of dispatching and signalling.

I have learned enough about international signalling and dispatching systems to realize that pretty much all signalling systems are attempts to implement correct absolute block systems with blocks of various sizes, and cab signalling is done whenever possible and affordable. 

Dispatching is another matter entirely.  The problem in simutrans is mostly not the signals.  The only problem with the *signals* is the inability to implement bidirectional lines due to the lack of a proper one-way signal.  (The two-way signals are essentially useless as I noted before.) 

There are a lot of problems with the *dispatching*.  I'm not sure it's actually reasonable to try to implement dispatching through signal placement; that isn't the way it's done in the real world.  A proper dispatching system could have major benefits -- it could even benefit truck traffic -- though it's also a major project.

[jamespetts]

The dispatching/signalling distinction is an interesting point, and to some extent there is a language barrier here: in British English, the word "dispatching" is not used (we do not have "dispatchers" - we have "signalmen", and signals are controlled from a "signal box"). I suspect that we use the term "signalling" for what in the US is called "dispatching".

May I ask - what, in overview, do you imagine that a distinction between signalling and dispatching entails, and do you have any thoughts, in outline, as to how this might be implemented in Simutrans?

(Incidentally, as to UK signalling not implementing the one way principle that you describe - that might well be because lines in the UK tended to be shorter and covering more densely populated areas, so have far more stations where things could be loaded/unloaded, and where one might as well have a passing loop to allow for higher intensity and flexibility of traffic, especially  since, when the railways were built, the labour costs necessary to have a signalbox at the relevant point were much lower. We also have in the UK a token system for single line working, which entails that only a train with the appropriate single line token can enter a single line section, and signalling equipment is such that it will only allow one token to be released from a token machine at any given time: traditionally, a pair of token machines, one in a signalbox at each end of the single track section, were electrically linked to each other using a telegraph system).

[wlindley]

U.S. dispatchers do much more than control local signals; they act as chess players, thinking several moves in advance; or like  a general considering a battlefield and what will happen hours later -- so that an entire railroad does not get jammed.  Also, grammar note: I do not mind being on a train that is braking (brake = slow down) but I hope never to be on a train that is breaking (break = to fracture).

[kierongreen]

I believe in the UK the term would be controller.

[jamespetts]

Kieron - interesting. What was the function of controllers in the days of mechanical signalling?

W. Lindley - the modern differentiation of the spelling of "brake" actually post-dates early railways, and some early records refer to "break vans".

[kierongreen]

Railway controllers: http://www.guardian.co.uk/money/2011/mar/19/working-life-railway-controller. In the early days there wouldn't have been the communication infrastructure to coordinate train movements in real time across a wide area. That only really became possible in the 1950s.

[jamespetts]

Interesting article.

I presume that, before the 1950s, there were no controllers, just signalmen?

[Michael Hauber]

Wikipedia has a couple interesting articles on signalling and centralised traffic control (CTC), the first system of which was built in 1927.  However prior to this there was always some element of centralised control and planning of train movements, although without systems such as CTC this control came from a combination of scheduling, rule books and local signalling and had limited ability to adapt to changes as they occurred.

In early railway days safety did not rely on signalling, but on trains following a timetable and emergency measures to warn following traffic in the event of a breakdown, such as a crew member walking back and waving a flag or setting a detonator (explosive device noisy enough to be heard by following driver when run over).  Later the telegraph was used so that signalmen could communicate with each other to determine if a section of track was clear, and finally automatic systems (interlocking) was developed to prevent miscommunication between signalmen resulting in a signal wrongly set to clear.  Token systems were important, where the train driver had to be in possession of a physical object to be allowed on a track section.  A primitive token system may have one token per track section, which worked ok for trains in alternating directions, but for allowing following trains required someone to send the token back to the other end.  A more advanced system had a box at each end from which one of several 'staff' (rod/key type object) can be taken, and which are electronically linked so that only one staff can be removed from the pair of boxes at any time.

There is a lot that could be simulated in simutrans, and it could easily overwhelm players with the options, and different systems to learn about if rail traffic from the earliest days to now is to be simulated.  The different options have significant economic impacts, for example earlier systems such as timetable separation reduce capacity by requiring significant slack built into timetable separation to allow for reasonable delays, and could also result in more accidents with both direct loss and a loss of reputation that may scare passengers away from an unsafe operation.  Token systems would require drivers to stop at every signal to obtain a token (or slow down for someone to hand the driver a token while still moving if the signal was at a manned location such as a station).

http://en.wikipedia.org/wiki/Railway_signalling
http://en.wikipedia.org/wiki/Centralized_traffic_control