New signals - coding

[Max-Max]

This thread is intended for the development of the "new" signal system. The brainstorm and discussion about the signal functionality are discussed here.

This thread will discuss the code implementation only.

[Max-Max]

We need to get the code ready for development. I'm not quite sure of how you meant regarding the repository.

If I create a local copy of the master and Erik creates a local copy of the master how do we synch our local copies (Erik's and mine) without a server?!?

By the way, I found this excellent page about TortoiseGit vs TortoiseSVN

[Erik]

I've no big experience with Git servers. So I don't border about what it will become.
I've to learn it at anyway. 

Further, the first thing what we needed is a function "signal_speed_limit()" who limits the allowable speed.

[jamespetts]

What you need to do is as follows:

(1) each create a fork of my 112.x-private-car-merge branch;
(2) one of you create a new signalling-overhaul (or something) branch on your own repository;
(3) the other one of you pull from the signalling-overhaul repository;
(4) each of you work on changes on your own signalling-overhaul repositories as necessary;
(5) each of you push to your own repositories each time that you have a single coherent set of changes/fixes;
(6) each of you pull from each other's repositories when the other has pushed a set of changes/fixes;
(7) each of you pull new changes from my 112.x-private-car-merge branch (or any successor branch, such as a probable future 11.x branch) whenever I make changes onto your own local master branches; and
( each of you merge those changes from your own local master branches into your own signalling-overhaul branches so as to keep your code up to date with mine.

Alternatively, you might want to create multiple branches each, and have each set of changes in one branch: for example, having distant and multiple aspect signal functionality in one branch, signal boxes in another, cab signalling in a third, the parser (if this is done) in a forth, and so forth, and have an additional branch where you merge all of the changes into one testing branch to see how they all work together (but actual code changes are applied to the sub-branches not the combined testing branch).

This latter approach is probably preferable, as it gives more robustness and flexibility, although set against that is the fact that it will be more time consuming to maintain.

I hope that this helps!

[Max-Max]

The part I don't see to understand how to do is:

(6) each of you pull from each other's repositories...

How can his Git client find my repository behind my firewall? NAT setup?
I'm not willing to share even a sector of my Harddrive to the whole internet.

[jamespetts]

Ahh, no, what you do is set up a repository on Github (it's free for public projects), and synchronise each branch on Github with an equivalent branch (with the same name) on your local hard drive. You each do that, and then you can merge from each other's branches.

[Max-Max]

Alright, that was what I meant in the first place but you said I should create one locally, so I thought we could do it without a GitHub server

Okay, I will have a look at GitHub then...

[Max-Max]

James & Erik

I have made a new fork at GitHub and posted you both a PM.

[Max-Max]

I cloned the 112.x-private-car-merge and tried to compile.

There seems to be some files missing:

Error   434   error C1083: Cannot open source file: 'tpl\debug_helper.cc': No such file or directory   D:\Projects\Simutrans Experimental\Signals\c1xx   Simutrans-Experimental
Error   446   error C1083: Cannot open source file: 'utils\cstring_t.cc': No such file or directory   D:\Projects\Simutrans Experimental\Signals\c1xx   Simutrans-Experimental
Error   458   error C1083: Cannot open source file: 'gui\colors.cc': No such file or directory   D:\Projects\Simutrans Experimental\Signals\c1xx   Simutrans-Experimental

The master branch compiles fine.

[jamespetts]

What are you using to compile it? Other people seem to have compiled without difficulty.

[Max-Max]

I did a fresh clone from your 112.x-private-car-merge. I'm using VC 2012 Express. I'm using the project file as it is after I added the usual include and lib path to OpenTTD...

I have looked and those fie are indeed missing. Maybe ppl added the missing files manually. I wasn't sure if your intention was to remove them or not.

[Erik]

I don't see those files in the master branche also. Perhaps they've never existed.

[jamespetts]

At least one of those files has been renamed and no longer exists with that name - which project file are you using?

[Max-Max]

I opened Simutrans-Experimental.vcxproj in VC 2012 Express.

[jamespetts]

Did you try opening the .sln file instead?

[Max-Max]

Okay, so I tried the .sln file, same thing there... Same files missing...

I went back to GitHub and browsed your repository jamespetts / simutrans-experimental and checked both in the Master and 112.x-private-car-merge branch and they aren't to be found there either.

Do you have those file in your local copy? They seems to be missing in the repository...

[Junna]

Okay, so I tried the .sln file, same thing there... Same files missing...

I went back to GitHub and browsed your repository jamespetts / simutrans-experimental and checked both in the Master and 112.x-private-car-merge branch and they aren't to be found there either.

Do you have those file in your local copy? They seems to be missing in the repository...

Have you made sure you have added all the required libraries and includes? These kinds of errors I get when not having added all, but as long as I add all required it will compile all right and I have not had any errors.

[jamespetts]

The problem is, I think, that these files are erroneously listed in the first place: they ought not to be in the solution at all. If you can delete them from your solution/project, you should be able to compile (all other things being equal). I am not sure why you are getting a version in which these are included, however. Which branch are you using? You should really be making sure that you are on the 112.x-private-car-merge branch.

[Max-Max]

I deleted my local copy and started over and suddenly it compiled fine!?!
I also managed to setup the upstream remote and updated my copy from it.

[jamespetts]

Splendid!

[Max-Max]

I have to admit that I got caught in a completely different subject in the code.

It started with some test of the skin system and I got curious when I found some "undocumented" skin images in the code. One thing led to another and now I'm kind'a fixing the skin system to actually use the D_TITLE_BAR_HEIGHT and other constants correctly.

There are a lot of dialogues using magic numbers in their size and position calculations and I'm trying to replace them with the defined element dimensions.

I have also added a D_GADGET_SIZE so the gadgets can be customized a little bit more in the future...
Anyhow, I have to start to learn the code somewhere, so why not start here

I'm sorry Erik, but I will catch up with you as soon I have fixed this...
We can still discuss the implementation if you want, or you can just poke around meanwhile to get an understanding of how things work.

[Erik]

And I was afraid that I was falling behind. 
It's itching to pick up an old project as well.
The rebuild of the ns-pakset (dutch railways), but let me be careful that it consumes my complete concentration again.

In the mean time I've figured out how to implement the signal_speed_limit. Unfortunately something goes wrong.
One of the speed_limits goes to zero. It could be the signal_speed_limit but it could also the corner_speed_limit.
I hope to fix this soon.

[Erik]

Finally I've figured out how GitHub works and pushed my work to my fork.

https://github.com/Erik-Krom/simutrans-experimental.git
In the branch "signals" I've put the implementation of the "signal_speed_limit".
I also changed the pre-signal so it can be tested.

[jamespetts]

Thank you all for your work on this - most interesting. I am currently away from my development environment, so can't test the signal speed limit code. May I ask: how in principle does this work? In real life, the signal speed limit is based on a precise relationship between the breaking performance of trains and the distance between signals; what happens when the player does not observe this precise relationship in placing signals, and places them too close together?

[Erik]

The lowest speed_limit is valid.
So the red signal is overruling the signal_speed_limit and the train will slowdown and stop in time for the red signal.

For the test I've set a fixed signal_speed_limit for the "pre-"signal if it's set on caution.

There are a few bugs with the signal itself.
Like the pre-signal it will activate the next signal if it's free. If that signal is also a "pre-"signal it will also activate the signal after that.
The speed limit of the last signal counts so if the last "pre-"signal is on caution the train will continue with a reduced speed.
Those has to be solved a next time.

[jamespetts]

Hmm - you mean that the train will travel at the slowest of the fixed speed or the speed at which it needs to travel to stop at the next signal? Is this how operating practice actually works in countries with speed signals?

[kierongreen]

Presumably not because that would require route knowledge...

[Erik]

I've some trouble to find a clear explenation.
I've put the signal_speed_limit with the corner_speed_limit and overweight_speed_limit.

Abbouth the fixed speed limit.
For now I've it set on 45km/h. So if a train reach a (pre-)signal on caution it will reduce it's speed to 45 km/h.
Signals who can give an adjustable speed_limit (speed signals) aren't build jet. I'm working on that.

[jamespetts]

Erik,

I am not sure that I follow. In the current Experimental, trains will always start braking soon enough before a signal that they will stop in time for that signal. Have you changed that in your code? How does the 45km/h limit fit in with that system?

[Erik]

I've done nothing about the breaking for a red signal. That's completely unchanged. So the train will still beak soon enough for a red signal anyway.

The 45 km/h is just the lowest speed limits on the Dutch railways and I use that for testing. Later is could be set by the designer of the signal. I will give it also the possibility that the speed limit is calculated by the distance of the next signal or that the train reduces its speed smoothly.

I will try to make the different variants so it can be tested and discussed what's the best balance between reallity simulation and game play.

[jamespetts]

If the trains still automatically start braking soon enough for the next stop signal in any event, what is the function of the signal speed limit? I thought that, in the real world, a signal speed limit was intended to slow trains to the correct speed to stop/slow furhter in time for the next signal by the time that they see it.

[merry]

If you are interested, at least according to UK practice, closely spaced signals are handled as follows. NB this is a bit mind-bending to start with. There are better (longer) explanations on-line (e.g. http://www.signalbox.org/) but this is just the most relevant bits.

In MAS installations, if a signal is to close to the signal in advance of it (in advance=next), then the signal is 'approach released'.
This means that the signal is held at Danger, until the train is close enough that (on the normal braking curve) the train will be travelling below the speed safe for approach to the signal in advance. This is usually done by timing the occupancy of an approach track circuit. At that time the signal will be released to the correct aspect for the next signal.

In semaphore practice with Absolute Block, it's a bit different. For a signal box that is a block post, if signaller has not received 'line clear' for the block section in advance, then the 'first' stop signal (the 'home') controlled by the box is held at danger until the train is nearly at a stand, and then cleared so the driver knows he does not have a clear run and must stop at the signal protecting the next block section. This is in addition to the distant signal which can only be clear if the next block post has given 'line clear' for the section in advance ans all 'stop' signals are cleared. there are variations allowing some more complex approach conditions such as a double amber aspect at the distant, which then allows clear signals for entry to (say) the platform but indicates the next block is not at 'line clear'
This is relevant because in effect, all the 'stop signals' controlled by the signaller are too close together for braking from line-speed, except the home which protects all shunt / conflicting movements in the signal box's area and has a clearing distance beyond the signal before any conflicting movements can occur.

Hope this is of some help.
Note that Simutrans signalling - even with semaphores - is fundamentally 2-aspect MAS with automatic routing at junctions. I know there are ideas to vary the signalling methods in future, but it's true now.

TTFN,
Merry

NB I am not a signalling engineer, just an interested party...

[Max-Max]

Remember that UK distant signals are very different from the.. Uhmm... non-UK signals
When a non-UK system signals at danger, a max speed limit (may it be distant signal, track or whatever) is used to slow down the train immediately and be prepared for a red main signal.

In practice the non-UK train will move slowly all the way up to the main signal and stop in time if needed. With the slower speed there is a chance that the initially red main signal will turn green and the train can continue at full speed from the main signal without stopping.

A UK train will reach the main signal faster because the driver knows where and when to hit the breaks in case of a red main signal light.

In an ATC system the driver will receive the max speed in real time depending on where it is and the state of the next signal. ATC overrides a distant signal's max speed.

By the way, great work Erik!

[jamespetts]

This all still leaves open the question of how we handle (1) determining what the maximum speed should be in the speed signal types; and (2) what to do when the spacing of these speed signals together with the braking capability of trains is such that the speed is too high for the distance between the signals. Without a clear way of handling this, such a system is open to exploitation by players deliberately placing speed signals with a high speed very close to the stop signals that they are protecting, knowing that one cannot actually have a crash in Simutrans, to get out of trains having to take the correct distance to brake.

[Erik]

(1) At the moment I will let determine it by the one who designed the signal. In the .dat file it will be possible to define a couple of levels with each its own speed limit. The implementation of the UK-way the distant signal works has to be done later.

With the code I'm stuck with that. With vehicles you can define constrains about witch vehicle can be put previous and next. This works with strings. For a list of speed limits for the signal I need it with integers. My programming skills aren't high enough yet.
Also I've to figure out how the version control works and how to set to the next version.

(2) On that point the distant signal becomes meaningless. For the gameplay the distant signals has a purpose to increase the distance the  train will start to brake so the signal has more time to go on green before the train has to stop completely.

[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