Swedish signals and signs.

[Vladki]

No, unless there are also many trains from 19th century. Theres a lot of work on 20th century semafores and I want to move on to other projects. Guys with flags/lamps will have to do for now. Translation is not necessary now (but would be interrsting). Just help me with the timeline.

[Ves]

ok I understand you have more projects! Currently there are no train before 1914 so in that way, earlier semaphore signals can wait
Help you with timeline?

[Vladki]

When the first light signals appeared, when the last semaphore was built...

[Ves]

Ah ok!
1858 - First semaphore model (danger, caution, stop)
1870 and 1890 - two and three wing semaphores are introduced.
1906 - the semaphores is now decided to point upwards (the models you have painted)
1915 - introduction of presignal
1920'ies - first modern signals (light signals) appears.  Number of lights represent number of wings
1950ies - the last semaphores are built (according to http://www.jvmv2.se/forum/index.php?mode=thread&id=90897 )
I try to find when the signals got the white rim, but haven't found anywhere. Somebody happen to know?

[Vladki]

Here is an attempt for a light signal without the white rim, and also with modified backside (narrower), so that the light can be seen also from backside. I really hate the backside, but I have not got any better idea.

[Ves]

Sweet! Although I could live with that backside, did you try painting the grey color on the backside with a brighter grey?

[Junna]

Ah ok!
1858 - First semaphore model (danger, caution, stop)
1870 and 1890 - two and three wing semaphores are introduced.

Does that mean you intend to introduce actual early steam engines and earlier rolling stock?

[Ves]

Yes! Although I don't know how to paint them yet. Maybe go for rendering?
Incidentally I already painted some of the earliest G-cars, showed in the other thread.

[Junna]

Rendering certainly makes it easier, but I don't know how you would maintain consistency. If you do go this way, I recommend it might be easiest - for consistency of the visual appearance - for you to make a basic model, render this and then draw on it to add details and touches. It will make it easier for you to maintain a consistency of scale and appearance for steam engines, which are notoriously quite complex in their shape by their nature, without compromising the visual consistency.

[Ves]

Vladki, do you have the sources for the signal? the latest update on your server I could find is 19 april.

[Vladki]

I'll try some modifications and upload tonight.

Well here it is - I repainted also the pole to pure grey - I took the same colors as for big road signs.
As you can see it is a bit harder to see it on grey track, an similar problem is with the road signs.
It may need some tuning when rails and roads are finished.

New files are uploaded, but the png and pak are the same as used to be (white rim) for consistency. This signal is only in src/signals_1_small.xcf (gimp), and here as attachment.

[jamespetts]

Incidentally, may I ask whether there are any plans to make this pakset open source?

[Ves]

As you can see it is a bit harder to see it on grey track, an similar problem is with the road signs.
It may need some tuning when rails and roads are finished.

At the first look, i have no problem 'finding' the signal, however I have not tried yet ingame.

Well here it is - I repainted also the pole to pure grey - I took the same colors as for big road signs.

Although the color on this new pole is very much better, it also makes it look very much thicker. Next to the catenary, it almost looks twice as thick.

New files are uploaded, but the png and pak are the same as used to be (white rim) for consistency. This signal is only in src/signals_1_small.xcf (gimp), and here as attachment.

great thanks! Im looking at the signal in the .xcf-file and it looks great! Will export and pak it to get it ingame tomorrow.

Incidentally, may I ask whether there are any plans to make this pakset open source?

Well, yes in the end, I think the plans are to make it open source like the rest of the game. However, I cant really overview how to make that happen with updates, contributions and how im supposed to work with the sources as its all currently down on my computer.

[jamespetts]

Well, yes in the end, I think the plans are to make it open source like the rest of the game. However, I cant really overview how to make that happen with updates, contributions and how im supposed to work with the sources as its all currently down on my computer.

May I suggest using Github? It's free for open source projects, and it's what is used for Pak128.Britain-Ex (and there is a mirror for Standard's version, too).

[Ves]

May I suggest using Github? It's free for open source projects, and it's what is used for Pak128.Britain-Ex (and there is a mirror for Standard's version, too).

Funny, as I was about to check it out, it didnt accept my email adress, and it appeared that I already had signed up for it ages ago but never used it and forgot it

edit: gosh, I realize why I gave up so quicly last time! how do you create folders and upload files? Its only yelling about pull requests and commits....

[Vladki]

The poles are 2 px thick. Just as the catenary. Imho catenary looks thin on green background as it is painted in green-grey. Should the signal pole have the same color as catenary?

No need to export and compile. Pak (for std) is attached above.

License for signals: artistic same as simutrans and many paks. Feel free to improve.

[Ves]

The poles are 2 px thick. Just as the catenary. Imho catenary looks thin on green background as it is painted in green-grey. Should the signal pole have the same color as catenary?

The signal poles should not have the same color as the catenary poles. I think you found a good color. The artistic decision I made behind the current catenary poles is that I think they look too thick if they got to be 3 pixels wide. Also, the irl poles are wider at the bottom than the top, but this won't look good as it will be very edgy.
However the brigtnes of the poles could still be adjusted.

Reason the signal poles looks thicker (to my eyes) is the brighter pole which will shine more on the screen than the relatively dark catenary pole and the signal itself.
Maybe you could try to darken the color and quite heavily the 'shadow' side of the pole (the right side) or simply make the pole only one pixel wide.

[Ves]

Vladki, Im about to create this public Github repository, do you mind if I put the signals you created there?

[Vladki]

I don't mind, but please give me access so I can upload new versions. It is work in progress.

[Ves]

I don't mind, but please give me access so I can upload new versions. It is work in progress.

Yes ofcourse! ... once I figure out how..
At least I think you need a profile on github, and then I should search for your name.

I will soon share the link to the repository in the forum, only need to understand the last things!

[jamespetts]

I see that the sources for these have been added to the Github repository - splendid! I see also that the .dat files from Pak128.Britain (Standard) have been used. Did any of you want any help in setting up these signals to work with the new signalling features in Experimental?

[Vladki]

Sure I do. I had a quick look on the dats of new signals in pak britain but some sort of reference would be handy.

[Ves]

That would be great to have some references! Also eventually to all other cool stuff you implemented :-)
Vladki, do you have access to the github? Can you "do" stuff there?

[jamespetts]

Here is a basic reference, adapted from the notes in various commits on Github. I do hope that this is useful; let me know if you have any questions.

New data members for signals' .dat files are as follows:

- aspects: the number of aspects that a signal has (default: 2 for all signals but pre-signals; maximum is 5)
- has_call_on: whether the signal has a call-on aspect defined (0: no; >0: yes; default 0);
- has_selective_choose: whether different graphics are provided for choose signals operating as such or operating as normal signals (0: no; >0: yes; default 0);
- permissive: whether this signal will let trains pass in the drive by sight working method assuming no converging or diverging routes to the next signal after it has been brought to a stand (0: no; >0: yes; default 0);
- max_speed: the maximum speed at which a train can approach this signal in km/h (default: 160) (Note: Was originally incorrectly written in this post as max_speed_kmh)
- signal_groups: comma separated list of numbers (1 to 31); if any of these numbers match any numbers specified in a signalbox's "signal_groups" comma separated list, this signal can be built from that signalbox. An entry of 0 (default) means that this signal can be built without a signalbox.
- working_method: the working method used by the signal, which will determine the method in which the train operates when under this signal's control. Default: track_circuit_block. Setting a signal to "drive_by_sight" makes it an end of signalling sign (beyond which trains operated in drive by sight mode) rather than a signal in the conventional sense. Possible methods:

   - drive_by_sight;
    - time_interval;
    - absolute_block;
    - track_circuit_block (the default if none of the other valid types are specified);
    - token_block (this will have the same effect as setting the signal to be a longblock signal);
    - cab_signalling;
    - moving_block; and
    - one_train_staff.

NOTE: any signal encoded as a "longblock" signal will override any user specified working method with the token block working method. A "longblock" signal is identical to a signal with the token block working method. It is recommended not to encode signals as "longblock" for clarity and consistency. It is preserved for backwards compatibility only.

- upgrade_group: a signal with the same upgrade group as this signal will automatically upgrade to this signal in the following conditions: (1) that signal is obsolete; (2) this signal is current; and (3) the underlying track is being renewed or replaced. Be very careful to make sure that signals in the same signal group are functionally identical to avoid unpredictable results, and likewise, make sure that only one signal in every upgrade group is current at the same time so as to avoid unpredictable results.
- signal_upgrade_cost: the cost that will be charged to a player when the signal is updated as above.
- max_distance_to_signalbox: the maximum distance from any signalbox that this signal can be placed EXCEPT for signals in the moving block working method, in which this instead denotes the maximum distance between moving block signals/beacons (any greater space than these and the train reverts to drive by sight after that distance has passed); this is expressed in meters
- is_presignal: this works largely as before, except that this now designates the signal as a distant signal or repeater signal, depending on the working method (distant signal in absolute block, repeater elsewhere; the difference between the two is slight in any event). What they both have in common is that a train will never be brought to a stop at a signal marked is_presignal: such a signal does nothing more than give an indication of the state of signals ahead. Note that if a signal has is_presignal=1 defined, is in the absolute block working method and has aspects=3, it is treated as a combined signal (that is, a signal that is both a distant and a stop ("home" or "starting") signal at once. The stop signal part will always work, but the distant signal part will only work if the next signalbox on the train's route is in range.

As for signalboxes, the .dat file parameters are:

Obj=building
Type=signalbox

allow_underground - as with signals; allows underground signalboxes
signal_groups - as with signals: see above
radius - the maximum distance from this signalbox that any signal connected to it can be placed
capacity - the maximum number of signals that can be connected to this signalbox at any given time

All other parameters are as for buildings (including new parameters, such as population_and_visitor_demand_capacity or employment_capacity.

Have a look at the Github repository for Pak128.Britain-Ex (especially here and here) for worked examples of this in practice.

[Vladki]

Hi, james. Thanks for this nice reference. A few questions though:

What is the difference between token block and one train staff (staff as stick or staff as employees?)

What is the difference if aspects=3 and is_presignal=0 or 1

What is the simutrans use of call_on and permissive signals? I always thougt their use is only in case of signalling failure, ans there are no failures in simutrans.

Does cab signalling and moving block require changes in engine dat file?

[Ves]

Really great references!
Looking through the links you posted, and there's some great work and cleverness behind it! Keep up! :-)
It will probably take some time to fully understand it all...

Sometime in the future, I could help you write descriptions to all new parameters in the datfiles :-)

[jamespetts]

Vladki,

I answer your questions below.

(1) Single train staff as against token block

(a) Single train staff (and "staff" as in stick rather than employee) is a system in which only one train is permitted on a whole stretch of line. It is very simple in operation: only a train whose driver is in physical possession of the staff may enter the section. This system must therefore have only one entry and exit point for all trains, or else the staff will be left in the wrong place. It is only really useful for either entire lines where only one train is running (very basic railways, where this would be placed on the exit from the depot and not on the train's normal route), or single track dead-end sections that have no internal signalling. In Simutrans-Experimental, the staff cabinets (there can be more than one for a section, but they must be placed in an immediately adjacent tile to one another to work as one) work by reserving the train's entire route until it comes back and reaches that cabinet again (or until it reaches the same point in its schedule as it is now, whichever is sooner).

(b) Token block is a much more sophisticated system. In real railways, it requires a train's driver to hold a physical token before entering the section. However, there is more than one such token, meaning that many trains can go through the section in one direction one after another. Only one token can be released at any one time. This is ensured by telegraph equipment at either end of the section. The rest of the tokens are locked in the token machine. This allows signalling of a single track line with multiple sections and multiple entry and exit points. In Simutrans-Experimental, trains will reserve the route only as far as the next signal, but will not unreserve the route until they pass the next signal.

(c) I had considered implementing an intermediate system between the two called staff and ticket, which was the way in which single track lines were signalled before the telegraph was used (it was introduced in the late 1850s but took a while to spread fully). Like the simple staff system, a physical staff represents the permission to be in a section. However, instead of having to take a staff, a driver may take a "ticket" instead provided that he/she sees the staff before entering the section. This allows more than one train to pass in the same direction without a train going back in the other direction. However, I decided not to implement this because, even in real life, this could frequently lead to deadlocks which, in real life, had to be resolved by sending somebody on horseback to the next station to collect the staff.

(2) For absolute block signals, aspects>2 is not supported except when is_presignal=1. For track circuit block, is_presignal=1 is not supported when aspects!=2. "Not supported" means that this combination is not intended to be used, has not been tested, and may produce unpredictable results.

(3) I plan to make a video about this, but, briefly, is_permissive indicates that the signal works in the permissive block mode. This is a variation of either track circuit block or absolute block (and should work in the cab signalling mode also, which is very similar to track circuit block in basic operation, although it has not been tested in cab signalling). It is a real life signalling system that is used to increase line capacity. I think that it is still used on the London Underground, or, in any event, was in use there until very recently. In a permissive block system, a train that is brought to a stand at a signal at danger may proceed even though the signal is at danger provided that it travels slowly enough to stop on seeing the train ahead. This is only possible where the signal controls a section of straight, unidirectional track. In real life, there sometimes are and sometimes are not subsidiary signal arms showing a "call on" aspect allowing the train to proceed in this way. call_on=1 indicates the presence of graphics for such an aspect. See the Pak128.Britain-Ex files for examples of how to encode this graphic. It is possible to have permissive signals without a visible call on aspect: in this case, they will continue to show a danger aspect when the train passes. There are underground permissive signals that work in this way in Pak128.Britian-Ex. In Simutrans-Experimental, permissive signals will work as such only if the route to the next signal has no junctions. If there are junctions, the permissive functionality is disabled and the signal works as an ordinary stop signal. In Pak128.Britain-Ex, the signal's sighting speed is lower for these call on signals, so there is a real disadvantage in placing them where they do not work as such. Provided that the line to the next signal has no junction, the train, once it has come to a stand at the signal, will be given a call on aspect, and will be able to proceed in drive by sight mode. This allows multiple trains to enter a section, which might be useful in busy goods loops, for instance, or low speed high density urban passenger lines. Choose signals cannot be permissive signals, as it is assumed that there will be junctions ahead. Note, however, that it is planned in future for signals that are not defined as permissive to have call on aspects to deal with light engine movements and splitting and combining trains; this is a significant new set of features, however, and has not been implemented yet.

(4) Cab signalling and moving block do not require compatible trains. It would be difficult to handle the situation where a non-compatible train is sent down the line, and, in any event, it is common to have portable equipment that can be carried by non-compatible trains (even steam trains use this equipment when they run special enthusiasts' trains on lines with cab signalling, which strongly suggests that there is really no such thing as an incompatible train).

***

Ves,

thank you! Do let me know if you have any questions. If you would like to help with the documentation, it would be much appreciated. Thank you again!

Generally, very best wishes with the Swedish pakest project - it is excellent to see a new pakset for Experimental being created. Do let me know if you have any queries about how to make Swedish style signalling work in Experimental.

[Ves]

Wow, I was speculating what this "permissive" would do to the signal, now I understand! The three green steady lights would mean that the route is shortened (possibly by other rail vehicles or going sideways in a junction) but i dont know of any practice in Sweden where eg underground trains may use such signaling routinely. Worth investigating!

Do let me know if you have any queries about how to make Swedish style signalling work in Experimental.

I havent got into very deep detail for most of the old signal systems, but I do know something of the very first one which differs a bit from normal signaling:

To protect a station, a T-semaphore was used. It was usually placed directly in front of the station building, showing trains at the edge of the station if they are allowed to enter the station. The signal was bidirectional with one wing for each direction and the driver was supposed to look at the lefthand wing. When the signal is in stop position for both directions, the signal looks like a "T".
It had three aspects:

horisontal = stop
pointing 45* downwards = caution
vertical downwards = clear (very seldom used and later removed)

When the train approach the station area, the driver would look after this signal and, if it showed stop, he had to wait with the train outside the furtherst junction or at a special sign.
The signals where all local operated.

When the train leaves the station, Im not sure, but I think a "flagman" would show up and let the train continue.

Pictures in this link:http://ekeving.se/si/mek/T-sem/T-sem.html

I dont know if this system would be doable or preferable for Simutrans. It would be fun to see, although its more like eyecandy and there is a danger that it would just overcomplicate things.
There also exist another signal used in a more normal way (train stops in front of signal).


Regarding signal boxes, would you consider to let station buildings or platform tiles (or any other building for that sake) behave as signal boxes?

I would love to help with some documentation. After all, I anyway need to dig in to understand and code dat-files.
Obviously, I need to learn the parameters first in order to later describe them :-P
How would you suggest?

[jamespetts]

That is interesting - thank you for that description. Firstly, to answer your question about the documentation, what would be particularly helpful is if you could put what I have written above in the same format as the .dat reference addendum documentation in this post, which is currently up to date only as at 11.35.

As to the T-semaphore, that is quite unusual in your description. Was it functionally different, or was it just a signal that was in one place and intended to be read in and to apply to another place visible from the first place to save on installation costs? How significant was this system of signalling? This might be a little tricky to implement, as one would have to have the train look ahead in its route, find the T-signal, then work backwards to a specifically linked sign to determine where to stop, and that functionality is quite different in type to the functionality currently implemented. One might conceivably partly simulate this visually by having a signalbox graphic with the T-signal built in and the actual signals being the stop boards, but this would not, of course, allow for the T-signal to operate visually.

As to signalboxes being built into stations, this would be quite fiddly to achieve in the code; is this a significant thing? It is possible to place a signalbox immediately behind a platform, for example.

Incidentally, I have realised that one thing that I missed from my earlier post about parameters is that signals now have a "maintenance" parameter, which works in the same way as that parameter does for ways. This is not available in Standard or earlier versions of Experimental, as signals had no maintenance cost.

[Ves]

Edit: bah, hitted save button accidentally....

As to the T-semaphore, that is quite unusual in your description. Was it functionally different, or was it just a signal that was in one place and intended to be read in and to apply to another place visible from the first place to save on installation costs?

As I have understood, the second of your statements is true. So it was not functionally different, just a practical solution.
The guard could just walk out from the station building out on the platform and shift the signal instead of walking the entire way (or hiring another guy) to operate a signal at the entry of the station. There where no wire mechanism at that time.

How significant was this system of signalling?

I have the impression that almost all stations have used this method for quite some time. From the very beginning, late 1850'ies during decades. The last remaining signal, where operated until 1960'ies or something. I think that was to protect a little siding or something similar.

This might be a little tricky......

Yes it might :-)
I think the keyword would be automation. A way to do it could be to code signs as signals for the player to put which would act as a normal signal/choose signal. Some graphical representation on either the station tile or on a platform would make up the signal itself.
The deluxe version would be that whenever a platform, a station house/signal box and such a sign is built, the signal would be automatically placed by the game on the tile in front of the station house/signal box or at the center of one of the platforms.

As to signalboxes being built into stations,

Well somehow it depends on how you foresee players to build their stations. In the old days, maybe it would be a staff member of the station that sends a guy out in the cold to operate the signals on that station.

"maintenance" parameter

Great! I will look into it :-)


Edit: In the signals.dat you linked, what is the entry "free_route=1"? Is that what makes it a choose signal?

[jamespetts]

Yes, free_route=1 refers to a choose signal: this is the same as in Standard, so I did not document it above.

Having a signal in one place and the graphical representation of it in another place is I am afraid totally alien to the code as it exists at present and would require a total rewrite. Having a T signal as a separate specific signal would be easier than this, but I am struggling to find a way to fit even this into the existing system without great upheaval.

Interestingly, though, the concept of a T signal might explain the curious signal that appears at Tan-y-Bwlch station on the Ffestiniog Railway in Wales (a preserved narrow gauge line) here:



The signal is now disused and preserved for posterity, the actual signalling being done by colour light signals. The line is single track and fairly lightly used and Tan-y-Bwlch is a passing place. I think that the Ffestiniog had somewhat unusual signalling arrangements in its early days, which might explain this.

[Ves]

Ok i see there might be a problem there. Maybe once in the future! :-)

Yes that definitely looks similar to what I found on Swedish websites. I don't know where this kind of signaling where invented, I would imagine England or Germany. The station looks little like a model train station with the strange camera angle and the narrow tracks! :-)

[jamespetts]

It is rather lovely. I went there a few years ago: it is very peaceful and the scenery is quite pleasant.

[Vladki]

That would be great to have some references! Also eventually to all other cool stuff you implemented :-)
Vladki, do you have access to the github? Can you "do" stuff there?

Hi, my git access seems to work. I'm now trying to play with the new signalling. I would like to implement the modern circuit-block/in-cab signalling, with the current graphics for light signals (white rim, black background). The signals would be:
- 2-aspect signal = 2 lights (red, green)
- 2-aspect presignal = 3-lights (green, white) - should be blinking
- 3-aspect signal = 4 lights (red, 2x green - caution, green+white - clear) - the bottom light should be blinking, but we cannot do that now. Any ideas how to distinguish them?
- 3-aspect choose signal = 5 lights (red, green+white - clear without choose, 2x green - clear with choose (non-bilnk) / caution without choose (blink), 3x green - caution with choose)

maybe also:
- 2-aspect choose signal = 3 lights (red, green (without choose) , 2x green (with choose))

Similar aspects could be for absolute block signals (semaphore and light signals), just without the 3-aspect 4-light signal. And 3-aspect choose signal would show clear with one green light/arm.

Dwarf signals as they were plus one more for end-of-signalling with diagonally placed lights

Do you have some evidence about using token block signalling in sweden and the related signals?

BTW James, I have a lot of questions about the new signalling. Where is the proper place to discuss it?

Well I have to get the questions and comments out of my mind.
<long stuff here>

I cannot resist comparing british and czecho-slovak (or even austro-hungarian and neighboring) signaling.

- permissive signals - we have those - modern circuit block signals on plain track that have the pole painted white are permissive. Those with red/white striped pole are absolute. But I think the reasoning behind was not to improve throughput, but to avoid blocking the whole line if one signal gets broken. At times there was a label on signals in uphill sections that allowed heavy cargo trains to pass slowly on danger without stopping (as they would struggle to start moving again.
- call on - we have a special aspect on signals within the reach of station (entry, exit) to allow trains enter the station if signalling is somehow broken, or if the train has to enter an occupied track. So this is different. There's no special aspect on perrmisive signals on plain track. It is only on otherwise absolute stop signals.

- absolute block signalling. I was looking for the closest equivalent here - it is old telephone signalling and half-automatic electromechanic signalling. The signalman had to communicate in similar way to their british colleagues:
A: I've a train for you
B: ok, let it in
A: there it goes
...
B: it passed through (complete)
and so on.
However there is one significant difference. Czech signalling distinguishes signalboxes at stations (where trains can pass each other), and intermediate boxes on plain track. This is important for operation on single, bidirectional track. The start of communication goes on between stations, with intermediates only listening and acknowledging that they have reserved their block accordingly. When the train passes the intermediate box, a next train can follow in the same direction. When there are trains for the other direction, the station signalmen have to agree on changing the direction (and wait for the track to clear of course). So I think the "blue" reservations described for circuit block, should be available for absolute block as well. However I have tried how it works, and I see that if there is only one intermediate signal box, then the whole path is reserved, which works just as expected. More then one could make deadlock, but that may be a design decision.

Another thought is about reservations. In real life all reservations go from one signal to another. If there are train stops in between (without track junctions), then the track is reserved through them. The train continues according to the last signal seen. Not in drive-by-sight. And the whole stretch of track remains reservered unitl the trains leaves the block completely. So I think that:
a) the reservation should go through any platforms and stops until the next signal
b) trains should be forbidden to turn around on platforms without signals (except for dead end tracks)
This will reduce the need for long/token-block signals on bidirectional tracks

Tokens and staff. I think there should be some indication where is the staff (in cabinet or not), or if a token can be released or not. Perhaps also if the train is in possesion of staff/token. Max_speed of staff cabinet or token box should be (almost) zero. The driver has to stop, and go for the staff/token. Also the token should be returned at box for opposite direction. After returning the token, the train should continue in drive by sight, if there is no other signal. Thus bidirections staff/token box makes sense - return one token and take another for the next section.

I think that the previously discussed T semaphores could have been used in combination with tokens/staff. While the staff/token secured the track between stations, the T semaphore (with entry signs), protected the station, allowing for shunting while there was a train on the track approaching the station. Their position and shape was IMHO just to save on installation costs and to keep is as simple as possible. Later the entry signs would be replaced by entry signals operated by wires or electricity. But the token would not be returned at the entry (choose) signal, but at the station.

[Ves]

Hi, my git access seems to work. I'm now trying to play with the new signalling. I would like to implement the modern circuit-block/in-cab signalling, with the current graphics for light signals (white rim, black background). The signals would be:
- 2-aspect signal = 2 lights (red, green)
- 2-aspect presignal = 3-lights (green, white) - should be blinking
- 3-aspect signal = 4 lights (red, 2x green - caution, green+white - clear) - the bottom light should be blinking, but we cannot do that now. Any ideas how to distinguish them?
- 3-aspect choose signal = 5 lights (red, green+white - clear without choose, 2x green - clear with choose (non-bilnk) / caution without choose (blink), 3x green - caution with choose)

and

- 2-aspect choose signal = 3 lights (red, green (without choose) , 2x green (with choose))

and

Similar aspects could be for absolute block signals (semaphore and light signals), just without the 3-aspect 4-light signal. And 3-aspect choose signal would show clear with one green light/arm.

sounds reasonable.

Do you have some evidence about using token block signalling in sweden and the related signals?

Sweden have heavily relied on a system called System-M, also called TAM, that is Tåg Anmälan.
This mean that two dispatchers, one on each station on each side of a peace of railway, communicate via telegraph, later telephone, with each other and agreeing on which train to send. They then prepared the station for the approaching train, and eventually set the T-signal, or later the entry signals to accept the train.
I found it difficult to find out definitively wheter another train in the same direction where allowed to be sent before the first train had arrived to next station, but several things suggest that this is the case. Then the trains where driving with reduced speed (20kmh).

One train staff and physical tokens, where aparently very rarely used, since the system-M with telegraphing the next station on the line where quite successfull. However, it did exist briefley on some tracks, and should therefore exist in Simutrans as well I think. The signals, I think, was just normal stop/drive signals.

(References (Swedish): http://www.idg.se/2.1085/1.591542/jarnvagens-signalsystem--principer-och-logik-del-1?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+idg%2FJYvw+%28IDG.se%3A+IDG.se+-+Senaste+nytt%29 and http://www.idg.se/2.1085/1.592328/jarnvagens-signalsystem--principer-och-logik-del-2?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+idg%2FJYvw+%28IDG.se%3A+IDG.se+-+Senaste+nytt%29, http://www.jvmv2.se/forum/index.php?id=88831)

If anybody reading this happens to have some knowledge (and knowledge in general about signals) you are most welcome to help clarifying!