Topic: Discussion of new signalling system

[jamespetts]

Thank you for that. To implement time interval signalling for single track railways (and to consider whether doing so is feasible) I will need quite a bit more detail on precisely how this worked in practice; are you able to assist with this?

[Vladki]

With the help of Leartin, I got some nice source of information: https://archive.org/stream/geschichtedereis03aust#page/56/mode/2up
Now I have to refresh my knowledge of German and pick up the relevant info from there. However at quick blick, it seems that many of the incomplete sources I came upon earlier were referring to this book.

[jamespetts]

That looks interesting - it is rather a shame that I know only a minuscule amount of German. However, I have since realised that a similar thing existed in the UK (time interval working with telegraph). I am considering whether to add this as a distinct working method, although that will take some time, and I will have to finish the pending pakset work and fix existing signalling systems before I make a start on that. It might be a useful transition between full time interval working with line of sight signalling only and the later, more sophisticated telegraph worked absolute block, however.

[Spenk009]

I speak German, I could assist here. What sections were you thinking of?

[Vladki]

I think that the first two sections have the most interesting info, especially the second (from page 57 to 118)

[jamespetts]

I speak German, I could assist here. What sections were you thinking of?

That is helpful - a summary of the way in which the telegraph was used with time interval signalling (especially on single lines and at junctions) would be useful. Thank you.

[Spenk009]

This is the gist of up to around page 63, at which point the author delves deep into his fascination for the bell operated signalling. I know it's not a summary, but I decided to retain as much informations as possible.


In 1851 under orders from the emperor it was decreed that the crown lands were to follow a collective of regulations governing the operation of railways. The signals "drive slowly" for sections in poor condition, "front and rear lighting" on trains, "whistle", "points", communication signals between driver and train guard, staff at stations ("clear", "slow" and "stop"), for the driver "engage brakes" and "release brakes", and finally line signalling informing of  a train having departed, was not departing and locomotive assistance required. All these signals must be communicable even by telegraph or in the event of this being broken without it.

Because these clever regulations only governed the terms of signalling and the types of signals without further establishment of signage and design of the signs (except for "whistle"), the development of signalling was little impeded. But as the years passed, the increase in traffic and convoy speeds naturally required an equivalent increase in signals and signalling assemblies, which necessitated a further batch of regulations that found their inauguration in 1877.

In this set of regulations the successor to the optical telegraphs is cited, this being "electrical, through line signalling". Page 40 (image 3) shows the evolution of these, which emerged from the unreliability of optical signalling that wished for a second signal that could be viewed at night, fog, etc. and was not affected by viewing distance. This is for the signal guards to ensure that the signals had operated correctly. In 1854 & 1855 (Semmering & Karst), electric bells were introduced next to the electric line signals. Due to this, the amount of guards along the track could be reduced significantly. An engineer named Schnirch suggested using the telegraph poles to anker the steel wires that were used to transfer the optical signals across long distances. This simultaneous working of optical and electrical signals was generally used until 1861 and in some cases kept for far longer until 1877. Due to the hilly nature of Austria, the signals "stop all trains" and "track unusable" were added. Unlike in Germany, where the amount of rings the bells give matter, these signals were ascertained by constant ringing of the bell. All other signals are given by telegraph communications or telephone lines. The fact that in Austro-Hungary every guard post must be able to communicate bell signals necessitated the operation with batteries.

[Vladki]

Spenk: thanks for the summary. I'm also slowly getting through it.

However I have more thoughts about singalling. From my tests with circuit block signals in experimental, I fell there is something fundamentally wrong. So this is gonna be long and theoretic post.

I have read a lot about various signalling methods recently. There is lot of differences between countries, and also between real world and simutrans. E.g. czech railway rules have strict distinction between station (where trains can pass and overtake), and running line - with or whithout signals and singalboxes that split it in multiple blocks. There is no such distinction in simutrans, but perhaps may be useful. Perhaps for UK absolute block I could say that a station is between home and start signal (or entry and departure on the continent), and that singalboxes on the line have home and start as one signal (block signal). Well at least that's how it works in CZ. (And the home signal can be in the form of combined signal acting as distant for the next start signal, both operated from the same signalbox). Maybe an example savegame with signals arranged as they are usually on UK railways may be useful. And I will provide one with CZ examples.

I think that for the needs of simutrans we should distinguish between signalling methods used on uni-directional track (i.e. double track where directions are fixed), and bi-directional track. At least in czech practice there are two signalling layers. One is used to negotiate the direction of traffic, and second to ensure safe distance between trains in the same direction. Let's first look at the second - safe distance in the same direction. There are probably the same options as in simutrans now:
- drive by sight (used by trams)
- time interval (obsolete now, but may be used combined with drive by sight in case of total failure of communications between stations)
- absolute block (either telephonic, or semi-automatic, used with both mechanical and color-light signals. Perhaps morse telegraph was in use as well. In all cases it depends on visual check by signalman that the train passed completely)
- circuit block (improvement of absolute block by removing the human factor - track clearance is checked electrically, signals return to clear automatically)
- cab signalling (improved circuit block - there are two different implementations - one that just shows the next signal in drivers cab, thus increasing the visibility of signal. For trains without the necessary equipment it is just like circuit block. Second that has no track-side signals, just signs as block-delimiters, cab signalling equipment is a must on such track.
- moving block (further improvement, driver has only the speed indication in cab, no signals along the track, blocks (beacons) are quite short. could be emulated as multiple aspect signalling with very many aspects.

- side note about speed signalling - there are two of them: one that is defined by path over junctions and switches, and tells the driver max. allowed speed over the switches for his specific path. The second that is defined by the lenght of clear track ahead. Simutrans trains do not need either, they always calculate their allowed speed over turns and breaking distance automatically. Path speed signals can be used at choose signals with has_selective_choose=1, distance speed signals can be used as multiple aspect signals. In some countries the rules define the speed at which signal at caution (or preiminary caution) may be passed, and in some not - it is the drivers responsibility to brake accordingly.

All these methods can be nicely described, and perhaps well implemented if the track is used only in one direction. If the track is to be used in both directions, we need first to negotiate the direction of movement before using the above described methods. These methods are (at least in CZ) used also for double (or more) track lines, when one of the tracks is not usable (accident, maintenance, repair) or, when a fast train has to overtake a slower commuter train in the same direction. To negotiate the direction, devices that are used for absolute or circuit block signalling are extended with button for "track permission" (CZ: traťový souhlas). There is one permission for each track, and only the station that has the permission can depart trains in that direction. The permission can be given to the other station only if the whole track is clear. When the permission is given-up, all signals in one direction become locked at danger, and signals for the opposite direction are unlocked. Circuit block signals on czech railways are usually unlit (eh I wanted to say turned off, but that may be confused with pull off = clear) in the opposite direction, but the meaning of such unlit signal is the same as danger.

Interesting stuff I found is the method used by CZ railways in case of comunication failure. If stations cannot communicate (not even by phone) with each other, there is a paper form of track permission. That is normally locked at one of the station and not used until necessary. This paper permits the station to dispatch trains in time intervals (10 minutes), train drivers have to get written order to proceed in drive by sight, ignore signals until the next station, and tell all the signalmen along the track that signalling is broken. The paper permission can be sent to the other station (by train or any other means) to allow trains to proceed in opposit direction. So - it is just the classic staff & tickets method.

Anyway, if you look at absolute block and all the modern methods, it is just a token block system with virtual tokens, that are transferred by electric wires between signalboxes. Also Direct traffic control (CZ rule D3), or RETB (CZ rule D4) are just a virtual (verbal or electronic) token methods. Even if you think about the electric token machine system - the token "returns" immediately, there's just a limited amount of them If you think more about it, you find out that token block and absolute block are very close - there is just a limit on the number of trains in one direction - you run out of tokens and have to send some of them back.

For ancient signalling, the direction was negotiated either by telephone, morse telegraph, ring (bell) signals or optical telegraph. I found a note that trains were carrying flags that told the signalmen if another train is following in the same direction (during that half of day....) Hmm, perhaps there was some timetable saying that trains go "up" in the morning, and "down" in the afternoon perhaps they carried not only flags but also some sort of token for the next station.

I think that in simutrans the directional (blue) reservation should be used on top of all above mentioned methods using the staff+ticket method. I could imagine it so that the directional reservation is more "persistent" and is still in effect, when train has passed. When a train in opposite direction is needed - the whole line has to be checked for clearance and then the direction can be swapped. The question is where should be the limits of directional reservation - I would think that each section delimited by junctions could do.

I feel It would be better to discuss all this live with pen and paper (and beer). Maybe you already solved lot of the things I'm thinking about and that are hard to describe (and even harder to describe in foreign language).

To put it short, something like staff & ticket method should be used on top of the others (drive by sight, time interval, absolute, circuit, cab sig, moving block) to provide the direction of movement, while the other methods deal only with spacing of trains in the same direction.

[jamespetts]

Thank you very much both for spending the time and effort to translate the very interesting Austrian signalling history and to set out your thoughts on the signalling system (respectively): it is much appreciated.

Replying to those points that seem to merit a reply: Vladki, you write that you think that there is something fundamentally wrong with the signalling as it is, but it is not clear from what you have written what you think that the fundamental problem is. Can you elaborate?

The current situation is that drive by sight, absolute block, token block, track circuit block, cab signalling and moving block working methods are (subject to any specific bugs that have yet to be found) complete and one train staff and time interval still need significant work to bring them into operation fully (they both exist, but do not work properly at present).

I did consider adding staff and ticket working when I was first deciding what working methods to implement, but realised that this system is one in which deadlocks can very easily arise (if the staff is at the wrong end of the section) and would thus create innumerable difficulties for players in working out with great mathematical complexity which trains to tell to take the staff rather than a ticket in order to avoid problems.

However, one additional working method that may well be worthwhile considering, as discussed a few posts ago, is time interval with telegraph. There are records of that being used in the UK. It may well be able (for example) to reserve a section over a junction greater than the sighting distance, and to allow directional reservations along single track lines (as denoted by the use of bidirectional signals, as with other working methods). I shall have to give some consideration to quite how to implement this once I have finished working on the left over pakset work from the Christmas period, which is taking me longer to process than I had anticipated. I shall at the same time look into the question of reserving through beyond non-reversing stops for absolute block, track circuit block and cab signalling as previously discussed.

[Ves]

From the other thread:

As to directional reservations, do see my reply in the other post to Vladki regarding these in the earlier signalling systems. Do I understand correctly that your issue is regarding the use of bidirectional signals? The system was designed thus to be relatively simple: anything that uncouples bidirectional signals with bidirectional track would take a huge amount of time and effort that could better be spent on other things. The basic principle is that a directional reservation is made from the first bidirectional signal on a train's route to the first unidirectional signal after the first bidirectional signal on that route. That should be simple enough to remember. The reason to use bidirectional signals at the North station is to start the directional reservation for trains heading towards the single track section: the deadlocks occur when trains enter that single track section without having made a directional reservation because they have yet to encounter a bidirectional signal.

Yes, It is regarding the need to use bidirectional signals.
Ok, I understand that separating the two again (after you have first coded it) is not nessecarily the optimum. Also I agree that a simple way to distinguish between directional and nondirectional reservations is to use single and bidirectional signals, like the way it is currently.
However, in some occasions, it can get a bit unflexible, for instance in some of the examples in the other thread. A (maybe easy, I dont know ) way to add flexibility could be to introduce a "Bidirectional reservation sign" which would force any signal behind the sign to behave as if it was a bidirectional signal in the sence of reservations. Whenever a signal tries to reserve through the sign, it will check if its possible to create directional reservation from the next signal (or at the end of the current moving block). If not, then the signal in front of the sign will remain at danger (the moving block may not proceed behind the sign).

The sign should be placed on any of the tiles between the first signal on the bidirectional line and the last signal on the onedirectional line. The first signal would then behave as if it was a bidirectional signal. In the sence of moving block, the stretch behind the currently reservated area will become direction reserved.

[Ves]

I was considering to use the "spoken" token block system because, to my knowledge, this is a good representation on how early trains are operated in Sweden:
When a clearance is given, nobody (except the train it self) will know where it is along the route. If there are crossing tracks, the dispatchers at the stations on those tracks would also be contacted to make sure a train can be sent (in real life, I guess there would not really be any ungarded junctions like this, but that cant be prevented in Simutrans..). A train cannot be sent if not the former one had arrived at its next station.
If there are ungarded platforms (with no dispatchers) along the route, the trains would still keep their clearance through those, even when stopping.

Problems with using token block signals is that if they are put on platforms, they will keep reserving the platform after leaving the station. Therefore they must be placed "behind" the station, although, that would risk to create a deadlock if a head on train is released at the same time.

I did not think it through about creating directional reservations with the other working methods, but I guess it would not make much sense if directional reservations are to be made only with double faced signals.

And yes I guess you have a valid point about track circuit signals not unreserving behind the train.

However, a solution could maybe be to reintroduce the Simutrans old fashioned "2 block signal" (signal will only clear if next signal is also clear)?
In fact, that would probably solve all the issues described I think:
Exit signal is token block: If token cant be released, signal will stay at DANGER on platform
Exit signal is track circuit block: If exit signal cant create a directional reservation (after the bidirectional signal on the line) it will remain at danger, thus the 2 block signal at the platform will also remain at DANGER.
Exit signal is a one train staff: Same as with token block, if the staff is not inside the cabinett, the signal will remain at DANGER.

[Vladki]

I think there could be another solution to the directional reservation problem. Binding it to bidirectional signals is maybe easy to code, but bound only to circuit block and not practical in many cases. E.g. Bidirectional exit/entry signal would need to be choose signal in one direction, but normal signal in the other. Also 2-block pre-signal (like in standard) would be needed to avoid deadlocks.

My proposal is to extend the use of long block signals, so that they are no more synonym for token block signal. Long block signals would be the explicit boundary for directional reservation. So a train approaching a longblock signal would attempt to make directional reservation up to the next longblock signal, possibly passing many "normal" signals on the way. If it succeeds, it will try to reserve the next block as normal signal according to its working method - drive by sight, time interval, absolute block, track circuit, cab signalling, moving block. Problem is with choose signals - how would directional reservation behave on choose signal? Simplest solution would be to end directional reservation at choose signal too.

Choose signals for all methods - even the early ones (time interval, drive by sight, tokens) should work similar to absolute/circuit block. In reality - entry to stations was secured differently to line blocks. It was decided by signalman by visually checking clearance of tracks, ensured by some locking mechanism - track ahead of choose signal should be in any case reserved at least up to the halt point or end-of-choose sign (or the next signal ahead).

I'm not really confident how token/staff methods are implemented, but what about this:
- token can be picked up and returned only at long block signal (only with token/staff method, not others)
- choose signal does not affect token ownership.
- normal signal would not exist at all (or would act as long signal)

[jamespetts]

Thank you for your feedback, and apologies for not having had time to reply earlier: I am afraid that I have been rather busy with work of late.

Can you both clarify the working methods for which the current system relating to directional reservations (or lack thereof) is problematic? Do you see this as problematic even when emulating UK signalling, or is this an issue specifically for emulating Swedish/Czeslovakian signalling systems? Where, in track circuit block with appropriately placed double facing signals, can deadlocks occur as a result of this? I seem to remember seeing a deadlock in an example uploaded that could be cured by changing one particular signal from unidirectional to bidirectional. The idea of the directional reservation was to reserve it for modern signalling systems, since only modern signalling systems have the concept of a directional reservation, which allows much more flexibility of track usage than older signalling systems that either require strict directional separation of tracks or cumbersome methods such as token block. Directional reservations might be useful to simulate the old time interval with telegraph system discussed above, which was in fact used on single lines before token block systems were invented.

I am afraid that it is not always easy to keep up with what is being discussed if one only has an opportunity to consider it briefly after long breaks and remembering all the (very detailed) context and previous information is not easy, so forgive me if I am asking things that I have asked before.

I see that the discussion has moved beyond track circuit block to token block systems. Is the problem that the current token block system, as implemented, does not properly represent UK signalling (or otherwise causes significant game-play issues when so used), or is the issue that it cannot properly be adapted to represent Swedish/Czeslovakian signalling systems? I should note that token block signals should clear the reservation of a platform for which they are the starting signal once a train has passed it (provided that the signal is actually on a platform tile, not beyond the station). Can you confirm that this works? If this has ceased to work, I should be grateful if you could start a new thread with a bug report, as I am afraid that I shall not remember to look back at this thread to remind myself of all the bugs that need fixing when I return to coding signalling. The idea is that the token block signals are used as the starter signals on platforms, with normal (uindirectional) distant and stop signals on the single line section itself.

As to choose signals, is there an issue with these in any method other than time interval (which is currently not working)? It is important to separate the concept of a choose signal (one which tells a train to take the next free platform at its destination station even if its chosen platform is not free, and is specifically placed by a player) and a signal protecting a junction (which does not tell the train to alter its platform, and which is detected automatically by the code). The currently stalled upgrade of time interval is intended precisely to make junction (not just choose) signals work somewhat like junction signals in absolute block, except that the reservation will only be able to be made within the sighting distance set by the pakset (750m in Pak128.Britain-Ex for now). Beyond this limit, there will be no reservation, and the train will be free to travel to its speed limit (or half the track speed limit if another train has passed in the last 10 minutes) until the next signal. The time interval with telegraph system that I plan will not have this limitation (on the assumption that pointsmen can telegraph each other from different sides of the junction if it be a long one). As to choose signs (not signals) in the drive by sight method, these should work in the same way as road choose signs, as it is implicit in drive by sight that there is no signalling of any type at all. As for token block systems, one should not have a token block choose signal as such: one should use the absolute block choose signal facing a station on a single line, and only use the token block signals facing out of stations (i.e. as platform starters) on single line sections.

Note that the current implementation of the token block and one train staff system does not rely on the concept of the game actually simulating the staff directly or storing the location of a staff or token: they work merely by setting up rules about when certain segments of track are to be reserved and unreserved. The one train staff system is not currently working and needs fixing, once I have worked my way thorough a large queue of other Simutrans tasks.

[Ves]

Ok, throwing in an effort of mixing this down, joining two parallel discussions:

It is important for me to know whether any given reported problem is common to all implementations, including British implementations, or whether any such problem is only a problem in so far as implementing other signalling systems is concerned, as I need to know whether I am likely to need to change the existing system or add further options, leaving the existing system in tact.

As far as I can tell, most of the issues that Vladki and I are pointing out relates to "our" countries (sweden and czeck), not to the way the signals works in England.
I have not had time to study english signalling, but I trust that you know that subject and have coded the current system accordingly (A small note to that: there should be a guide where to place the signals according to ENGLISH practice inside Simutrans. I think my documents are (still) too vague on that subject).
However, see the example below regarding the token block signals.
 

This may have been different in the days of time interval signalling, but I have not had any success in finding detailed information about how stations, in particular, were signalled, save that smaller stations often had a single “T” shaped signal (similar to the Swedish practice previously discussed) for all trains departing from that station. I cannot find any information about what signalling was used for arriving trains.

Was the T-signal not used for the arrivals too? Otherwise, maybe just hand signals where used?
 

I am not entirely sure that I understand the reference to time interval and token block not making much sense in the context of line block signalling and signalling at stations. As stated on the public forum, time interval signalling in the context of junctions (including those at stations) is not currently working and awaiting being fixed: I am in the process of making this work as I have discovered it worked in reality (but have been distracted by pakset works since December and have not had the chance to finish this). As to token block, this should work correctly for stations if it be used correctly (the token block signals as the starter signals, absolute block signals (including choose signals if appropriate) as the home and distant signals).

- and -

I see that the discussion has moved beyond track circuit block to token block systems. Is the problem that the current token block system, as implemented, does not properly represent UK signalling (or otherwise causes significant game-play issues when so used), or is the issue that it cannot properly be adapted to represent Swedish/Czeslovakian signalling systems? I should note that token block signals should clear the reservation of a platform for which they are the starting signal once a train has passed it (provided that the signal is actually on a platform tile, not beyond the station). Can you confirm that this works? If this has ceased to work, I should be grateful if you could start a new thread with a bug report, as I am afraid that I shall not remember to look back at this thread to remind myself of all the bugs that need fixing when I return to coding signalling. The idea is that the token block signals are used as the starter signals on platforms, with normal (uindirectional) distant and stop signals on the single line section itself.

As stated earlier, Im talking out from a swedish perspective, however the situation explained below, I find difficult to imagine how it would work also in an english enviroment with the current implementation.

Imagine a station on a line with a branching line going out from that station:

Code: [Select]

                                            / /
              _____________________________/ /
West   ______/_____________________/_\______/             East
       _____/_____________________/___\________________________
        [station house]
This illustrates a station with three tracks on a double tracked line, with a single tracked line branching out to the east.
The double tracked line outside the station is equipped with track circuit block signals (or absolute block signals), and choose signals facing towards the station. The single tracked line also has a choose signal facing towards the station.

The single tracked line has stops along the way, so token block signals are needed on the east side.

With the token block signals placed at the platform ends on the east side of the station, a train departing from the station heading out on the single tracked line will reserve the junctions and keep them reserved until it arrives at the next signal, possibly after a LOOOONG distance, blocking acces to the platforms from the other tracks. Trains going on the double tracked line would also have this problem, however a reservation could be much earlier resolved by placing signals quite close to the station facing from the station.

This cannot be resolved by putting a single token block signal on the single tracked line outside the station as that would create another problem: trains will be released from the track and held at that signal (if it is in danger), possibly blocking the junctions and possibly creating a deadlock if another train is released from the other end of the line.

If this is too complicated in written text, I can upload a savegame to illustrate what I mean.

Note: This would be a problem also for the one train staff, as you want the train to stand still at the station until the staff is returned.

[jamespetts]

Apologies for the delay in progressing this topic: I had been rather busy with some other things, including bug fixes and pakset work, as well as non-Simutrans matters. I am now turning my attention to signalling again. As some may have noticed, I have now fixed time interval signalling, which should, at least for the most part, work correctly.

I am having some trouble with the time interval with telegraph mode at this juncture: in particular, finding a way of making it usable for single line working whilst retaining a reason for the player to upgrade to token block working when that becomes available. The difficulty is made all the greater by a lack of material about the details of how time interval signalling actually worked when accompanied by the telegraph.

The material that I have found so far is from rule books of the Eastern Counties Railway from 1848 and 1856, which do not go much further than stating that the signalman must send a telegraph message to the signalman at the other end of the single line section to check whether the line is clear, and, if it is, may send a train along it. I had thought that this might work in a similar way to token block, but without reserving beyond a station stop (as there would always have to be a signal at the end of the section), but this is problematic when used with double track running as it reserves rather too much rather too soon.

As to the diagram drawn by Ves above, does anyone have any idea as to precisely how such a layout might have been signalled in the days of time interval signalling? I am trying to avoid if possible having to create any significant new abstractions or mechanisms, which would involve a very significant amount of work and may possibly have adverse performance implications.

Finally for now, I have implemented an earlier suggestion on this thread of having a signal's working method visible in the tooltip and the signal's information window, and also having a train's current working method visible in the convoy detail window, which I hope is helpful.

[Ves]

Don't worry, take the time that is needed! :-)

As to the diagram drawn by Ves above, does anyone have any idea as to precisely how such a layout might have been signalled in the days of time interval signalling? I am trying to avoid if possible having to create any significant new abstractions or mechanisms, which would involve a very significant amount of work and may possibly have adverse performance implications.

I don't have any concrete Swedish or English example at the moment, but I would assume that, whatever the signal system is used, the train would be held back at the platform/siding until the entire trip to next station/siding can be booked. In other words a combination of absolute block and whatever working method on the line it self.

Finally for now, I have implemented an earlier suggestion on this thread of having a signal's working method visible in the tooltip and the signal's information window, and also having a train's current working method visible in the convoy detail window, which I hope is helpful.

That is really great news! This will help troubleshooting and add some clearance as to what is happening on the tracks I think!


Sent from my iPhone using Tapatalk

[jamespetts]

Don't worry, take the time that is needed! :-)
I don't have any concrete Swedish or English example at the moment, but I would assume that, whatever the signal system is used, the train would be held back at the platform/siding until the entire trip to next station/siding can be booked. In other words a combination of absolute block and whatever working method on the line it self.

From what I have read of UK practice concerning diverging single and double track other than at stations, there was generally a short stretch of double track (about a train's length) on what was otherwise the single track line just beyond the junction. If replicated in Simutrans, this would allow for a mix of token and absolute block signalling to work as currently implemented. In more modern times, this practice has largely been discontinued (and it is not necessary in the current implementation of track circuit block, cab signalling or moving block).

This is why I asked for detailed examples: I do not know whether there were any junctions signalled in this way without a short stretch of double track until modern times and, if so, how they were signalled. One thing that would be very difficult to achieve in the current implementation of signalling is having a signal behave differently depending on the route beyond the signal that the train takes. This is (in simple terms) because the code iterates over the route tile by tile, and triggers the signal's behaviour when it gets to the tile with the signal on it, without yet having checked what tiles are ahead. It is also conceptually very difficult for the code to determine which tiles belong to a stretch of double track and which tiles belong to a stretch of single track.

That is really great news! This will help troubleshooting and add some clearance as to what is happening on the tracks I think!

I am glad that this is helpful.

Edit: I have now fixed the issue with reservations clearing behind a train that is entering a platform and scheduled to reverse there.

[Vladki]

That's good news

I'm trying to set up a testing server (thank to Isaac), where we could test various layouts. Do you have any sugesstions or hints how to compile (without SDL) or just any useful tips for running a experimental game server?

As I said earlier, Czech railways do not use token block too much. The transition went from time-interval to absolute block. The only reason to use token block is to save on infrastructure and operation costs (signals, signalmen). But you lose on throughput, so now something like token-block is used only on very low traffic branches.

For implementing telegraph + time interval, I think that the directional reservation could be used for that - reserve as far as next junction, clear right after the train. Similar method cloud be used to enable sigle track operation with absolute block. Or you could reconsider my earlier sugesstion on changing how longblock signals work: Do not make them an alias for token block, but make them as explicit markers for directional reservations in all working methods. (Or at least time interval, absolute, circuit block, cab signalling, movng block). E.g. for absolute block - normal signal would make "red" reservation up to next signal, long singal would make "blue" reservation up to the next long singal (in addition to normal "red" reservation to next signal). Choose signals pose a little problem so blue reservation could end on choose signal to make it simpler.

Junctions out of station: Most of railway junctions (I know about) that are not within a station, are usually not far from the station (a few km at most) - and were for long time operated in absolute block mode (even on single tracks). To avoid deadlock, the direction of traffic had to be agreed between stations on both sides of junction (just as if there was no junction at all). It certainly needed a smart signalmen (and timetable) to avoid deadlocks.

Combination of token-block with other methods. In real life, the drivers and signalmen know whether a token is needed for particular stretch of track or not. But we do not have such information in simutrans. Neither the token itself is simulated (if I recall correctly what James said). I have played a bit with token block and find it quite unpractical and non-intuitive how to use at all. Consider a simple line with passing loops (two tracks with one-way sings on one side and token-block signal on the other. Trains arrive from both sides, stop, and wait forever because the track behind is still reserved for them. I can fix that by putting an entry signal in front of the station, but then next train can follow in the same direction, while the passing loop is occupied. Deadlock again. Unfortunately I have no good idea how to solve that.

[jamespetts]

I'm trying to set up a testing server (thank to Isaac), where we could test various layouts. Do you have any sugesstions or hints how to compile (without SDL) or just any useful tips for running a experimental game server?

I am not sure that I fully understand the question - are you having any trouble compiling? If you are, it might be better to start a new thread about it.

As I said earlier, Czech railways do not use token block too much. The transition went from time-interval to absolute block. The only reason to use token block is to save on infrastructure and operation costs (signals, signalmen). But you lose on throughput, so now something like token-block is used only on very low traffic branches.

In reality, token block was used as a safety system: to ensure that no two trains were ever simultaneously permitted to be on a stretch of single track at the same time, all trains entering the section needed to have a token, and the machines at either end of the section would only release one token at a time. This was, in effect, a more efficient and semi-automatic implementation of the earlier staff and ticket system.

What I am having trouble finding out is exactly how single line working actually worked in the days of telegraph based signalling before the invention of the token block machines.

Another problem is, as stated in the previous post, to give players an incentive to upgrade to token block when it becomes available. We cannot have a possibility of a head-on collision as an incentive, as that would result in a deadlock which could cause problems for an unattended player in an online game, and in any event, Simutrans has generally preferred to avoid simulating disasters of any sort.

The other theoretical alternative would be to simulate staff and ticket working, but, as discussed before, the possibility of a deadlock with such a system (and the degree of micromanagement required in players telling trains when to take a staff and when to take a ticket) is too great to be practical.

Do you have any idea how time interval or absolute block actually worked in practice on single track lines in Czeslovakia (or whatever it was called at the relevant time)? In particular, do you know where the signals would be placed, and where the trains would have to be relative to the signals for a section to clear? Would only one train be allowed in the section at once, or would multiple trains (in the same direction, separated by time intervals) be permitted?

A problem with the latter system would be that it would actually be preferable for the player than token block signalling, so there would be no incentive to upgrade.

For implementing telegraph + time interval, I think that the directional reservation could be used for that - reserve as far as next junction, clear right after the train. Similar method cloud be used to enable sigle track operation with absolute block.

This raises quite a number of complexities. Firstly, reserving to "the next junction" is ambiguous. The code needs to determine at precisely what tile that it stops reserving further. What counts as a "junction" here: the first tile with tracks of more than one direction on it (which would include a line merging into the single track section one or two tiles after the signal at the start of the single track section), or some other tile, and, if so, which one? The normal thing is for a reservation to end at a signal, so that a train has a means of being signalled beyond the end of the point to which it has reserved. The signal is usually not on the same tile as the junction, so it is unclear what ought to (or sensibly could) happen if a train were to reserve to a junction rather than a signal. The difficulty is that there is no way of defining an area in Simutrans: a junction in a station area is treated identically by the code to a junction a long way from a station or one in the next station.

Or you could reconsider my earlier sugesstion on changing how longblock signals work: Do not make them an alias for token block, but make them as explicit markers for directional reservations in all working methods. (Or at least time interval, absolute, circuit block, cab signalling, movng block). E.g. for absolute block - normal signal would make "red" reservation up to next signal, long singal would make "blue" reservation up to the next long singal (in addition to normal "red" reservation to next signal). Choose signals pose a little problem so blue reservation could end on choose signal to make it simpler.

Is the idea here to have a signal that can be used to instigate a directional reservation that only affects trains travelling in one direction?

Junctions out of station: Most of railway junctions (I know about) that are not within a station, are usually not far from the station (a few km at most) - and were for long time operated in absolute block mode (even on single tracks). To avoid deadlock, the direction of traffic had to be agreed between stations on both sides of junction (just as if there was no junction at all). It certainly needed a smart signalmen (and timetable) to avoid deadlocks.

There are plenty of junctions in the UK that are some distance from stations - at least, far enough that they had to have their own signalbox in the days of mechanical/absolute block signalling; they would typically have the sort double track section described in my previous post.

Combination of token-block with other methods. In real life, the drivers and signalmen know whether a token is needed for particular stretch of track or not. But we do not have such information in simutrans. Neither the token itself is simulated (if I recall correctly what James said). I have played a bit with token block and find it quite unpractical and non-intuitive how to use at all. Consider a simple line with passing loops (two tracks with one-way sings on one side and token-block signal on the other. Trains arrive from both sides, stop, and wait forever because the track behind is still reserved for them. I can fix that by putting an entry signal in front of the station, but then next train can follow in the same direction, while the passing loop is occupied. Deadlock again. Unfortunately I have no good idea how to solve that.

I have just fixed a bug with token block reservation that caused unreservation incorrectly. See this saved game file for a demonstration of how to set up a single track railway with a passing loop using token block signalling. Does this make things any clearer?

Edit: I have investigated the way in which junctions were designed from stations on double track lines with a branching single track line. From what I have found, these, too, like the junctions away from stations, had a length of double track line immediately beyond the station before reverting to single track. I suggest that the token block signal should go on this stretch of double track line.

Edit 2: I have rigged up a test and demonstration track for a mix of single and double track running using a mix of absolute and token block signalling: download it here. This appears to work as intended. Does this answer any questions on how to signal this sort of arrangement?

[Vladki]

I am not sure that I fully understand the question - are you having any trouble compiling? If you are, it might be better to start a new thread about it.

Right now I have to sort out cross compiling (my PC is 32-bit linux, and server is 64-bit linux), but that is off-topic here. I'll google more...

In reality, token block was used as a safety system: to ensure that no two trains were ever simultaneously permitted to be on a stretch of single track at the same time, all trains entering the section needed to have a token, and the machines at either end of the section would only release one token at a time. This was, in effect, a more efficient and semi-automatic implementation of the earlier staff and ticket system.

Sure it was a safety system, but it is also a low-cost solution, with lower throughput, if compared to absolute block signalling.

Another problem is, as stated in the previous post, to give players an incentive to upgrade to token block when it becomes available. We cannot have a possibility of a head-on collision as an incentive, as that would result in a deadlock which could cause problems for an unattended player in an online game, and in any event, Simutrans has generally preferred to avoid simulating disasters of any sort.

Token block machine is the logical upgrade to one-staff method. It allows you to run more trains in the same direction. The logical upgrade from time-interval is absolute block. If you do not consider security, there's little to no reason to upgrade from time-interval to token block. (maybe to cut costs, if traffic has declined).

Do you have any idea how time interval or absolute block actually worked in practice on single track lines in Czeslovakia (or whatever it was called at the relevant time)? In particular, do you know where the signals would be placed, and where the trains would have to be relative to the signals for a section to clear? Would only one train be allowed in the section at once, or would multiple trains (in the same direction, separated by time intervals) be permitted?

I can describe quite exactly absolute block with telephone communication, as it is still in use. I suppose that telegraph communication was almost the same, it just took more time to negotiate. Let's have a track with stations A,B and signalbox X half-way between them. The communication is something like this.

• A->B: Train 1 has arrived to A. I have a train 2 for B, do you accept it? (X is listening to this)
• B->A: Yes I accept (switching direction)
• X->A: Acknowlege

...

• X->A: Train 2 has passed X
• A->X: Ack

Then the communication continues between AXB just as at dual track absolute block. Station A can dispatch next train after it passes X, until station B asks to change directions. Then they have to wait until the track is clear and can switch directions.

German and Swedish description (if it can help you): https://de.wikipedia.org/wiki/Zugmeldebetrieb  https://sv.wikipedia.org/wiki/T%C3%A5ganm%C3%A4lan

Signal placement: on approach to a station there is distant signal, then entry signal, then switches and platform. At the end of platform (or beyond) is departure signal and then switches, end of shut sign, and the line. Train arrival is acknowledged when it passes the entry signal. Train cannot pass departure signal if the line is not clear (except for shunting). When the train stops at station it must fit between the departure signals in opposite directions.

---Distant>---Entry>---<end-of-shunt---|switches|---<departure---|platforms|---departure>---|switches|---end-of-shunt>---<Entry---<distant---

(Maybe you can assume entry=home signal, and departure=start signal, but I'm not really sure it is so.)

For time interval I suppose the "direction switch" was very similar to absolute block. They had to acknowledge the arrival of the last train in sequence.

Without telegraph they had to use ticket+staff system, or something similar. I found in some articles, that trains had colored flags or lights telling if there are more trains following or not. But this has the same implementation problems as ticket+staff. Also I found a note about a departure signal that was electrically controlled from the next station, and was locked at danger if train(s) was coming in opposite direction. However it was not described in much detail, so I don't know when one could clear the signal in safe manner.

A problem with the latter system would be that it would actually be preferable for the player than token block signalling, so there would be no incentive to upgrade.

Sure, you could reduce the max_speed for time interval signals. But I would do the same for token block. You cannot catch a token at 100 km/h. (but you can accelerate afterwards). I know I repeat myself, but the upgrade path from time interval is to start using absolute block.

This raises quite a number of complexities. Firstly, reserving to "the next junction" is ambiguous. The code needs to determine at precisely what tile that it stops reserving further.

You can do it in the same way as for circuit block. I'm not really sure how far the driectional (blue) reservation goes in circuit block, but it should be the same for any method. At least you could share the code and it will behave consistently for players, but read further:

Is the idea here to have a signal that can be used to instigate a directional reservation that only affects trains travelling in one direction?

Yes, that is. In real life there is distincion between stations (passing loops), and signalboxes on the line. Directional reservation is always from one station to another, while absolute reservation is only up to the next signal. So I think it would be better if player had explicit control of the endpoints of the directional (blue) reservation. Actually I do not like the way the directional reservation is implemented for circuit block, because there are places where bidirectional signals are not desirable. This would remove the automatic directional reservations completely and will put the player in full control.

There are plenty of junctions in the UK that are some distance from stations - at least, far enough that they had to have their own signalbox in the days of mechanical/absolute block signalling; they would typically have the sort double track section described in my previous post.

The czech junctions are also far enough to have their own signalbox, but it was more like the signalboxes along the line, than the signalbox at station.

I have just fixed a bug with token block reservation that caused unreservation incorrectly. See this saved game file for a demonstration of how to set up a single track railway with a passing loop using token block signalling. Does this make things any clearer?

I have a problem with that save - I cannot see the token block signals, but when I click at and of platforms/loop I get an info box about token signal being there. Have you made any changes to pak that are not in git yet?

Edit: I have investigated the way in which junctions were designed from stations on double track lines with a branching single track line. From what I have found, these, too, like the junctions away from stations, had a length of double track line immediately beyond the station before reverting to single track. I suggest that the token block signal should go on this stretch of double track line.

Edit 2: I have rigged up a test and demonstration track for a mix of single and double track running using a mix of absolute and token block signalling: download it here. This appears to work as intended. Does this answer any questions on how to signal this sort of arrangement?

This example looks as useable workaround. Though I have not seen such layout in real world, I can deal with that in a game. And I have the same problem with disappeared token signals in this save. Debug output:
ERROR: roadsign_t::finish_rd:   roadsing: way/ground missing at 228,165 => ignore

[jamespetts]

Right now I have to sort out cross compiling (my PC is 32-bit linux, and server is 64-bit linux), but that is off-topic here. I'll google more...

If you have full terminal access, you can compile on your server, can you not? That is what I do.

Sure it was a safety system, but it is also a low-cost solution, with lower throughput, if compared to absolute block signalling.
Token block machine is the logical upgrade to one-staff method. It allows you to run more trains in the same direction. The logical upgrade from time-interval is absolute block. If you do not consider security, there's little to no reason to upgrade from time-interval to token block. (maybe to cut costs, if traffic has declined).

That is not how it worked in the UK - absolute block was used for unidirectional track (i.e., double track or above), whereas token block was used for single line sections. It was used for single line sections to prevent head-on collisions. Time interval with telegraph was also used on single track sections (plain time interval could not be so used, but staff and ticket could be and was used on single track sections in conjunction with time interval signalling). Single track sections would thus have the following upgrade path:

Time interval/staff and ticket > Time interval with telegraph > Token block > Track circuit block (etc.),

whereas double (or more) track sections would have the following upgrade path:

Time interval > (at busy junctions only) Time interval with telegraph > Absolute block > Track circuit block (etc.).

The token system was the additional layer over the normal absolute block signalling necessary for single line working.

I can describe quite exactly absolute block with telephone communication, as it is still in use. I suppose that telegraph communication was almost the same, it just took more time to negotiate. Let's have a track with stations A,B and signalbox X half-way between them. The communication is something like this.

• A->B: Train 1 has arrived to A. I have a train 2 for B, do you accept it? (X is listening to this)
• B->A: Yes I accept (switching direction)
• X->A: Acknowlege

...

• X->A: Train 2 has passed X
• A->X: Ack

Then the communication continues between AXB just as at dual track absolute block. Station A can dispatch next train after it passes X, until station B asks to change directions. Then they have to wait until the track is clear and can switch directions.

German and Swedish description (if it can help you): https://de.wikipedia.org/wiki/Zugmeldebetrieb  https://sv.wikipedia.org/wiki/T%C3%A5ganm%C3%A4lan

Signal placement: on approach to a station there is distant signal, then entry signal, then switches and platform. At the end of platform (or beyond) is departure signal and then switches, end of shut sign, and the line. Train arrival is acknowledged when it passes the entry signal. Train cannot pass departure signal if the line is not clear (except for shunting). When the train stops at station it must fit between the departure signals in opposite directions.

---Distant>---Entry>---<end-of-shunt---|switches|---<departure---|platforms|---departure>---|switches|---end-of-shunt>---<Entry---<distant---

(Maybe you can assume entry=home signal, and departure=start signal, but I'm not really sure it is so.)

For time interval I suppose the "direction switch" was very similar to absolute block. They had to acknowledge the arrival of the last train in sequence.

Without telegraph they had to use ticket+staff system, or something similar. I found in some articles, that trains had colored flags or lights telling if there are more trains following or not. But this has the same implementation problems as ticket+staff. Also I found a note about a departure signal that was electrically controlled from the next station, and was locked at danger if train(s) was coming in opposite direction. However it was not described in much detail, so I don't know when one could clear the signal in safe manner.

This is very interesting, thank you. I wonder how the directional telegraph system actually worked: did the signllers have to remember the direction (or write it on a piece of paper or something), or was there a solid state telegraph instrument showing the currently set direction (perhaps interlocked with the starting signals at the entrance to the section on either side so that neither could be pulled off unless the direction were set correctly)? Were two trains allowed in the same direction? If so, how would the signaller at the receiving end know how many trains to wait for before reversing the direction?

Sure, you could reduce the max_speed for time interval signals. But I would do the same for token block. You cannot catch a token at 100 km/h. (but you can accelerate afterwards). I know I repeat myself, but the upgrade path from time interval is to start using absolute block.

The time interval signals already have a lower maximum speed than absolute block signals (135km/h rather than 160km/h), but this is unlikely to make any practical difference on steam operated single track branch lines, and so unlikely in and of itself to be an incentive to upgrade. Token block signals need not have a lower maximum speed: remember, trains need to slow down and stop momentarily just before the token signal to collect the token, so there is no further need to restrict the maximum speed beyond the token signal.


You can do it in the same way as for circuit block. I'm not really sure how far the driectional (blue) reservation goes in circuit block, but it should be the same for any method. At least you could share the code and it will behave consistently for players, but read further:

The idea of having this working only in track circuit block (and later) is that this easier to use, more sophisticated and more flexible system is only available later when track circuit block becomes available: there would be little incentive to upgrade to this on single track lines if it were possible to do the same thing in absolute block (and no incentive to use token block at all).

Yes, that is. In real life there is distincion between stations (passing loops), and signalboxes on the line. Directional reservation is always from one station to another, while absolute reservation is only up to the next signal. So I think it would be better if player had explicit control of the endpoints of the directional (blue) reservation. Actually I do not like the way the directional reservation is implemented for circuit block, because there are places where bidirectional signals are not desirable. This would remove the automatic directional reservations completely and will put the player in full control.

The czech junctions are also far enough to have their own signalbox, but it was more like the signalboxes along the line, than the signalbox at station.

I will have to give this idea some further thought. However, it is very difficult to have a distinction between a station area and a signalbox off a station for the reason given in the previous post.

I have a problem with that save - I cannot see the token block signals, but when I click at and of platforms/loop I get an info box about token signal being there. Have you made any changes to pak that are not in git yet?
This example looks as useable workaround. Though I have not seen such layout in real world, I can deal with that in a game. And I have the same problem with disappeared token signals in this save. Debug output:
ERROR: roadsign_t::finish_rd:   roadsing: way/ground missing at 228,165 => ignore

That is odd - the pakset should be complete on Github. Are you sure that you are using the latest half-heights branch? I cannot reproduce the error that you report.

[Isaac Eiland-Hall]

If you have full terminal access, you can compile on your server, can you not? That is what I do.

The server in question is set up as a shared server, so it might not be possible right now, but I can perhaps figure out how to give permissions. Offhand, this is something I don't know how to do, but I can always google. heh

Not sure if I need to grant sudo or something else…

[jamespetts]

The server in question is set up as a shared server, so it might not be possible right now, but I can perhaps figure out how to give permissions. Offhand, this is something I don't know how to do, but I can always google. heh

Not sure if I need to grant sudo or something else…

You shouldn't need to grant sudoer rights unless the executable or any of the files needs to be in a place where only the superuser can access. You do need to install Git on the server, however, as well as a number of libraries and developer tools (e.g. libpng, bzlib, gcc, etc.), and installing those requires sudoer access; but you can do this yourself.

Thank you, incidentally, for agreeing to host the test server- this is most helpful.

[Vladki]

The server in question is set up as a shared server, so it might not be possible right now, but I can perhaps figure out how to give permissions. Offhand, this is something I don't know how to do, but I can always google. heh

Not sure if I need to grant sudo or something else…

Installing g++ and libstdc++6-dev should be enough. Thank you in advance.

[Ves]

Guys, you are posting in a tempo I cant catch up

I got some more time to read and wrote a bit more detailed response:

I am having some trouble with the time interval with telegraph mode at this juncture: in particular, finding a way of making it usable for single line working whilst retaining a reason for the player to upgrade to token block working when that becomes available. The difficulty is made all the greater by a lack of material about the details of how time interval signalling actually worked when accompanied by the telegraph.

The main incentive to upgrade to token block signals from time interval signals could be the cheaper labour (in game maintenance) costs. Somehow, many things where better and easier in the past but have been changed to the worse due to it being cheaper for the ones paying the bill.
The choice the player make is wether to pay more for the more effective and "easy/intelligent" working method or pay less for the new and rather "square" system that removes some flexibility.
Rising labour costs should take care of that.

Regarding vladkis suggestion of having directional reservations up to the last junction being difficult to implement, could maybe get solved this way: The signal will check if there are any junctions between this and the next signal on the trains route, and then if true, create a directional reservation up until the next signal. If there is no junction after the signal, it behaves as a normal time interval signal. Otherwise, since it is actually equipped with telegraph, it could direction reserve the entire route until the first one way sign or another working method signal.

The material that I have found so far is from rule books of the Eastern Counties Railway from 1848 and 1856, which do not go much further than stating that the signalman must send a telegraph message to the signalman at the other end of the single line section to check whether the line is clear, and, if it is, may send a train along it. I had thought that this might work in a similar way to token block, but without reserving beyond a station stop (as there would always have to be a signal at the end of the section), but this is problematic when used with double track running as it reserves rather too much rather too soon.

What you describe from the rule book sounds quite a lot as the practice done in Sweden at that time.
What do you mean with it is reserving too much too soon?

As to the diagram drawn by Ves above, does anyone have any idea as to precisely how such a layout might have been signalled in the days of time interval signalling? I am trying to avoid if possible having to create any significant new abstractions or mechanisms, which would involve a very significant amount of work and may possibly have adverse performance implications.

Regarding my example, I think I have already somewhere in the depth if this thread tried to describe how to place the signals in Sweden, however in this specific example:
A signal/flag man on each platform end (6 signals) and a signal outside the station at all ends (3 signals) as well as an entry signal facing toward the station from all ends (also 3 signals),  (and then the famous T-signal in front of the station building, depending on the era).

From what I have read of UK practice concerning diverging single and double track other than at stations, there was generally a short stretch of double track (about a train's length) on what was otherwise the single track line just beyond the junction. If replicated in Simutrans, this would allow for a mix of token and absolute block signalling to work as currently implemented. In more modern times, this practice has largely been discontinued (and it is not necessary in the current implementation of track circuit block, cab signalling or moving block).

This is why I asked for detailed examples: I do not know whether there were any junctions signalled in this way without a short stretch of double track until modern times and, if so, how they were signalled. One thing that would be very difficult to achieve in the current implementation of signalling is having a signal behave differently depending on the route beyond the signal that the train takes. This is (in simple terms) because the code iterates over the route tile by tile, and triggers the signal's behaviour when it gets to the tile with the signal on it, without yet having checked what tiles are ahead. It is also conceptually very difficult for the code to determine which tiles belong to a stretch of double track and which tiles belong to a stretch of single track.

I can see that if laying the tracks like in the savegame, many problems would actually get solved, however I dont think that is something that is widely used in Sweden. Obviously I can't say for sure, but the plans I have found with single tracked lines branching out of a station is that there is no double track going along with the single tracks. The signal that physically allows the train to enter a single tracked line is also used to send trains onto the other tracks in that general direction. Outside the station, there is the exitsignal but there are no passing possibilities there.

I'm trying to set up a testing server

Sweet!

I have played a bit with token block and find it quite unpractical and non-intuitive how to use at all. Consider a simple line with passing loops (two tracks with one-way sings on one side and token-block signal on the other. Trains arrive from both sides, stop, and wait forever because the track behind is still reserved for them. I can fix that by putting an entry signal in front of the station, but then next train can follow in the same direction, while the passing loop is occupied. Deadlock again. Unfortunately I have no good idea how to solve that.

I think that if you put an absolute block signal close in front, so any train length will be longer than the distance between token block signal and the absolute, the previous reservation will be terminated upon approach of the absolute block signal. Maybe not the best solution, but it might work!

A->B: Train 1 has arrived to A. I have a train 2 for B, do you accept it? (X is listening to this)
B->A: Yes I accept (switching direction)
X->A: Acknowlege
...
X->A: Train 2 has passed X
A->X: Ack

Sounds like swedish practice as well, save for that there might not be anything like "X".

Signal placement: on approach to a station

Also almost the same, with this minor adjustment:

---Distant>---Entry>---<Exit---|switches|---<departure---|platforms|---departure>---|switches|---Exit>---<Entry---<distant---

where the departure signals only will show clear when the exit signal shows clear. The Exit signal is by default the "end of shunt".

Without telegraph they had to use ticket+staff system, or something similar. I found in some articles, that trains had colored flags or lights telling if there are more trains following or not

This is true also for swedish signalling, but that was still used along with the telegraph: If there was an extra train outside schedule, extra flags where mounted on the first train (which is in the schedule) then all the posts along the tracks which dont have the telegraph equipment will know that there is an extra train coming outside the schedule. The stations at either ends would know about, and approve, the extra trains departure.
However, this is not feasable to implement, as there are no such thing as a schedule in this context.

Yes, that is. In real life there is distincion between stations (passing loops), and signalboxes on the line. Directional reservation is always from one station to another, while absolute reservation is only up to the next signal. So I think it would be better if player had explicit control of the endpoints of the directional (blue) reservation. Actually I do not like the way the directional reservation is implemented for circuit block, because there are places where bidirectional signals are not desirable. This would remove the automatic directional reservations completely and will put the player in full control.

However, it is very difficult to have a distinction between a station area and a signalbox off a station for the reason given in the previous post.

I support this! Maybe not necesarily to unchain directional reservation from bidirectional signals completely, merely adding the option to create a directional reservation from a single faced signal.
One can say that you already have created a distinction between "station area" and "line stretch", due to the different working methods. Frankly, the only working method that really works inside a station is the absolute block and also the track circuit (and cab signal. The moving block behaves as cabsignal after a choose signal). All other working methods are not really practical inside a station with more than one track and I think one should aim to keep them outside the "station area". Please read my suggestion further down with regards to a 2 block signal which could keep absolute block (or track circuit or cab signal) inside the station and let the other working methods work from outside the station.

This is very interesting, thank you. I wonder how the directional telegraph system actually worked: did the signllers have to remember the direction (or write it on a piece of paper or something), or was there a solid state telegraph instrument showing the currently set direction (perhaps interlocked with the starting signals at the entrance to the section on either side so that neither could be pulled off unless the direction were set correctly)? Were two trains allowed in the same direction? If so, how would the signaller at the receiving end know how many trains to wait for before reversing the direction?

For Sweden, I think there was an interlocking machine inside the signalbox to choose the direction, otherwise it was done by pen and paper. No troubble with counting trains, the two stations would communicate and at all times agree on how many trains there should be on the line. Upon arrival, the recieving station would telegraph back again to the previous station and tell everything is ok. Of corse there are emergency protocolls if one station is not answering, but that is not needed in simutrans!

The time interval signals already have a lower maximum speed than absolute block signals (135km/h rather than 160km/h), but this is unlikely to make any practical difference on steam operated single track branch lines, and so unlikely in and of itself to be an incentive to upgrade. Token block signals need not have a lower maximum speed: remember, trains need to slow down and stop momentarily just before the token signal to collect the token, so there is no further need to restrict the maximum speed beyond the token signal.

I remember we have talked about a "spoken token block" signal, I dont know how far you are in those thoughts? If there was the possibility to remove that the train must stop next to the signal the paksetauthor could treat the working method as a set of "logics" and use it as a modern signal system. The original token block signals (the one intended to actually have a token cabinet) should then have maxspeed=0 (zero) to force the train to stop as it currently does.

My impression from reading about real world signalling in general is that it rely heavily on logic (if this signal is green, then that must be red etc). In Simutrans, the working methods decides the overall logic rules and then much of it is simulated automatically behind the scene like tracks only can be reserved by one train at any time and junctions are automatically interlocked and directional reservation etc.
However, the player cant really create more specific interlocking, such as a signal that only can be green if the next signal also is green. I mentioned it briefly earlier, but what about implementing the 2 block signal from Standard?
It would solve, I think, many of the issues that Vladki and I are talking about. Also due to the fact that the Experimental signals are unidirectional, the "two block signal" will not be as clumpsy as it might be with Standards bidirectional signals.


Sorry for the long post

[jamespetts]

The main incentive to upgrade to token block signals from time interval signals could be the cheaper labour (in game maintenance) costs. Somehow, many things where better and easier in the past but have been changed to the worse due to it being cheaper for the ones paying the bill.
The choice the player make is wether to pay more for the more effective and "easy/intelligent" working method or pay less for the new and rather "square" system that removes some flexibility.
Rising labour costs should take care of that.

I am afraid that this is unlikely to work economically, and also has no historical precedent: it does not take more people to work a time interval with telegraph system than it takes to work a token block system: it is just that the token block system is safer and more reliable. After 1889, all passenger railways in the UK were not allowed to use time interval signalling. Many had already upgraded to absolute/token block decades earlier. There really needs to be a line capacity difference.

Regarding vladkis suggestion of having directional reservations up to the last junction being difficult to implement, could maybe get solved this way: The signal will check if there are any junctions between this and the next signal on the trains route, and then if true, create a directional reservation up until the next signal. If there is no junction after the signal, it behaves as a normal time interval signal. Otherwise, since it is actually equipped with telegraph, it could direction reserve the entire route until the first one way sign or another working method signal.

I had attempted to implement something similar to this, but using the block rather than the directional reservation, as what I read indicated that this was closer to the actual practice. However, I have now discarded that code because it did not work well in practice, and, in particular, could not be made to work effectively for single track working. I shall have to think of whether a modified/simplified version of this might work (and I have just had an idea for a simpler implementation that might be workable for time interval with telegraph).

I support this! Maybe not necesarily to unchain directional reservation from bidirectional signals completely, merely adding the option to create a directional reservation from a single faced signal.

Can either of you think whether there are any situations in which you would want a bidirectional signal that is not one that creates a directional reservation in the track circuit block method, or will having either bidirectional signals or "longblock" signals creating directional reservations suffice?

One can say that you already have created a distinction between "station area" and "line stretch", due to the different working methods. Frankly, the only working method that really works inside a station is the absolute block and also the track circuit (and cab signal. The moving block behaves as cabsignal after a choose signal). All other working methods are not really practical inside a station with more than one track and I think one should aim to keep them outside the "station area". Please read my suggestion further down with regards to a 2 block signal which could keep absolute block (or track circuit or cab signal) inside the station and let the other working methods work from outside the station.

I am not sure that I entirely follow this. Not all stations use choose signals, so what is "within the station area" is not the same as the area behind a choose signal. Also, because the starting signals are on the platforms, whether the station throat is "part of the station area" on the basis of the placement of signals will depend for each train on the direction in which it is arriving, with the station throat before the station being part of the "station area" in this definition, but the throat the other side not being so part.

As to the working methods that work in stations, it is helpful to look at them one by one.

Drive by sight: this should work in stations as well as anywhere else.
One train staff: currently not working at all, so not applicable.
Time interval: this should now work in stations after the recent improvements - if this is not working in stations, can you elaborate?
Time interval with telegraph: currently incomplete, so not applicable.
Absolute block: confirmed to be working
Token block: this is intended to be used in conjunction with absolute block such that all passing places (including stations with more than one track) are signalled in the absolute block method, although token block should work for stations without passing places (and has been specifically designed to do so).
Track circuit block: confirmed to be working
Cab signalling: confirmed to be working
Moving block: this should work in stations even if the behaviour resembles cab signalling when a choose signal is used

As to the "2 block signal", do you mean one that reserves two blocks ahead? I am not clear on how you imagine this interacting with working in stations; can you elaborate?

For Sweden, I think there was an interlocking machine inside the signalbox to choose the direction, otherwise it was done by pen and paper. No troubble with counting trains, the two stations would communicate and at all times agree on how many trains there should be on the line. Upon arrival, the recieving station would telegraph back again to the previous station and tell everything is ok. Of corse there are emergency protocolls if one station is not answering, but that is not needed in simutrans!

I remember we have talked about a "spoken token block" signal, I dont know how far you are in those thoughts? If there was the possibility to remove that the train must stop next to the signal the paksetauthor could treat the working method as a set of "logics" and use it as a modern signal system. The original token block signals (the one intended to actually have a token cabinet) should then have maxspeed=0 (zero) to force the train to stop as it currently does.

My impression from reading about real world signalling in general is that it rely heavily on logic (if this signal is green, then that must be red etc). In Simutrans, the working methods decides the overall logic rules and then much of it is simulated automatically behind the scene like tracks only can be reserved by one train at any time and junctions are automatically interlocked and directional reservation etc.
However, the player cant really create more specific interlocking, such as a signal that only can be green if the next signal also is green. I mentioned it briefly earlier, but what about implementing the 2 block signal from Standard?
It would solve, I think, many of the issues that Vladki and I are talking about. Also due to the fact that the Experimental signals are unidirectional, the "two block signal" will not be as clumpsy as it might be with Standards bidirectional signals.

The way in which signalling logic works in Simutrans is that a train will try to reserve a route ahead whenever it first moves off. Whether it succeeds in reserving that route ahead will determine whether it is allowed to move off. It will iterate through each tile on its route until its next stop, and decide whether to reserve the whole way to its next stop, part of the way, or not at all. If it reserves the whole of or part of the way, it will start moving, and note the tile at which the reservation ends as a tile at which it will have to stop. It will prepare to start braking in time for that tile. As it approaches that end tile, it will check whether it can reserve further on, and the process is repeated until it gets to its next stop. The signals along the way, as well as reservations by any other train, just influence in various ways the logic used by the train in determining where it can reserve.

What I described is the way that signalling works in both Standard and Experimental. The only differences between Standard and Experimental are, in general terms, that there is more variety and realism of the signal based logic in Experimental than Standard.

However, this basic way of working does constrain the sorts of things that can be done without a very major rewrite of a large and fundamental part of the code that would probably take years to finish. The signals do not communicate with one another: the signals remember no more than their position, what sort of signal that they are and their current state. All the logic is in the trains (specifically, the leading vehicle) and the signals are entirely passive. The signalboxes are also entirely passive and do no more than remember where they are, what type that they are and what signals are connected to them, the only logic being to allow connected signals to be built, transferred into or out of them, and to delete all connected signals when the box is deleted.

This means that it is not really possible to have custom logic at pakset level except by implementing all the logic into the code itself and having signal parameters of various sorts influence the logic that a train passing a signal with those parameters will adopt.

What you describe as the "2 block signal" is, I believe, the same as the pre-signal from Standard (which, of course, is not a pre-signal at all in real world terms). Does this method of signalling actually reflect any real life use case, or is it intended as a workaround for some Simutrans specific issues? I am still a little unclear on how this type of signal would help in stations.

[Vladki]

Oh, this discussion is getting more complicated, to answer to you both

I think many of the issues stem from different history in our countries. It seems that Czech (or Austro-Hungarian) and Swedish practices were in fact quite similar, while UK was in a bit different situation. The most important is, that all Austro-Hungarian railways were first built as single-track. The funding and revenues were not so big as in UK. Lines were upgraded to double track, only when the traffic was too high.

The first continental (horse-drawn) railway Budweis (CZ) - Linz (AT), was built in  1827–1832, long before Morse's Telegraph (patented 1847). The first operation was on strict adherence to timetable at passing loops, and drive by sight on the line. In case there were two trains in opposite direction too far to get back to passing loop, one of them had to be derailed... Well this is not possible to simulate in simutrans....

Later they used optical telegraph http://www.laenderbahn-forum.de/journal/heldenzuege_1859/heldenzuege_1859.html, these baloon signals, are sometimes described as signals for the driver, sometimes as a means of communication between signalboxes. In either case, they informed about the current direction in which the traffic is allowed. Some sources say that these were used also as time-interval signals (clear, slowly, danger).

In 1855, electric bell signals were introduced to replace optical telegraph. They were clearly a means of communication between signalboxes. Optical telegraph was abondoned in 1877. To remember the agreed direction, perhaps pen & paper were used, later some sort of needle telegraph. Somewhere I read about some sort of departure signal that was interlocked with the agreed direction, but it was not very detailed, and now I cannot find it. I suppose that multiple trains in the same direction were allowed in time-interval, otherwise there would be no difference between time-interval with telegraph and token block (or absolute block with signalboxes only at stations/loops). Unfortunately, there is not much info I could find on the details how time-interval signalling worked. In essence the dialog between stations was probably close to absolute block signalling. The stations had to count or somehow identify the trains and get confirmation that it arrived, in order to be sure that the line is clear. But the exact method would be just a speculation.

To the incentive to upgrade from time-interval to token block. Safety is not simulated. If multiple trains are allowed between stations, then you need a few signalboxes on the line. These will be removed in token block - as a result you cut costs, but reduce throughput. Maybe that's why this transition did not happen in Austria-Hungary, and absolute block was used instead - safety improved, while costs and throughput remained roghly the same. However, there was a big cost saving with the transition from optical telegraph to electric bells (and other electric devices). Signalboxes for optical telegraph had to be in sighting distance to each other. Introducing electric communications allowed big reduction in signalboxes. But this change was independent of time-interval vs. absolute block.

When absolute block was introduced in 1880's, the electromechanical devices that were used, had a provision for setting the direction of traffic - so they were a bit more complex than their british counterparts. In absolute block, the departure signal was locked at danger, if the traffic was agreed in opposite direction, but I have no evidence if that was so in time-interval as well. If only telephone/telegraph communication was used, the direction probably had to be put on paper, and doublechecked by the other side when negotiating next train.

As to the described dialog, and Ves's comment. Most of the sigle tracked lines have signalboxes only at stations (passing loops), with a few stops in between, but busier lines (or where the stations are too far) have an intermediate signalbox. Perhaps even more intermediate signalboxes were possible, but according to this map, the current practice is to have only one (on single track line): http://provoz.szdc.cz/PORTAL/Show.aspx?path=/Data/Mapy/TZZ.pdf
If there are no intermediate signalboxes, then the whole dialog is much simpler, especially in regard to direction of traffic - there can be only one train between stations, and it does not matter in which direction.

I have not encountered any notice about using token machines in Austria-Hungary or Czechosolvakia. Perhaps staff and ticket+staff were in use somewhere, either to cut costs (no signals at all), or as a fallback if the communication between signalboxes is broken (that's even the current practice). However if you imagine a token machine as an upgrade for one-train staff - where the token can "magically" reappear at the other end of line, then you can think about the needle telegraph (or improved absolute block machine) as an extension to ticket and staff, where the staff (permission to dispatch trains) can be handed over to the other signalbox instantly. I acknowledge that UK practice is different, but the game should be country independent. You can then limit the available signals at pakset level.

On czechoslovak railways, there is almost no difference between absolute block a and circuit block. It is just improved safety, faster negotiation, reduced manpower - fully automatic signalboxes on the line, remotely controlled stations, and the integration with cab-signalling. But the procedures, e.g. to switch direction on single tracked line is the same as with electro-mechanical absolute block:

Back to the idea of special signals for directional reservations: Even in circuit block, you can think of the line as being split into small blocks - signal to signal, where only one train is permitted, and longer blocks - station to station, where multiple trains in the same direction are permitted. Making these blocks explicit (e.g. by redefining the use of long-signals), could help to solve also the problem of junctions without passing loops. No need to have two levels of signalboxes, just two levels of signals: block, and long-block. Is that description clear?

Can either of you think whether there are any situations in which you would want a bidirectional signal that is not one that creates a directional reservation in the track circuit block method, or will having either bidirectional signals or "longblock" signals creating directional reservations suffice?

I have no problem with bidirectional signal creating directional reservation. It is the other way around - I need a one-directional signal (usually ahead of platform - departure signal) to create a directional rerservation up to the next passing loop. As the passing loop is also not easily detected by code, the end could be marked by the same signal (and aditionally by choose signal to aviod the choose platform logic in directional reservation). Moreover I find too little use for bidirectional signals anyway. Even in places where they could be used I would like them spaced further apart (so that a stop with platform fits in between), or to put them around road crossing so that they are back to back, rather than face to face as they are now.  So if you implement the proposed "new long block" in addition to keeping directional reservations from bidirectional signals, it is ok for me. Just that the bidirectional signals would not be necessary for me any more.

Ves: as to the spoken token block (D3 in CZ) - I think there is no need for different behavior to physical token block. I remember that at one such line, the driver had to get out of the engine, go to the station building and get the permission to continue by phone. Nowadays they can get it over radio or mobile phone, or a special radio device (RETB in UK, D4 in CZ), but that usually happens on places where those trains stop anyway. At least it would be an incentive to upgrade to proper signalling.

What you describe as the "2 block signal" is, I believe, the same as the pre-signal from Standard (which, of course, is not a pre-signal at all in real world terms). Does this method of signalling actually reflect any real life use case, or is it intended as a workaround for some Simutrans specific issues? I am still a little unclear on how this type of signal would help in stations.

As I undertand Ves, yes 2-block signal is the pre-signal from standard. Read further on real use:

2-block signals (hand signals). We have those in CZ as well. Some smaller stations have one departure (exit) signal common for all tracks, and the signalman has to give the departure signal to particular train. Perhaps this was even more common before WWII. German occupation introduced the 2-block signal - visually similar to UK banner signal - that could be put at every track and allow shunting as well as departure (then it had to be in sync with the main signal). There was also a color light version, but they were not very widespread and later replaced by full-featured main signals at every track. Nowadays there are only a few stations in CZ/SK with those signals. I do not consider them as essential (but I dont know how common they are in Sweden). If directional reservations would be resolved by explicit (long) signals, then these may not be needed (but nice for extra reality). Otherwise these 2-block signals may be useful to get single tracked lines working.

In real use - if the "banner" signal was pulled off it allowed either shunting or departure from the particular track, but for departure you had to obey the main signal as well. The color light version has 3-aspects: danger, shunting allowed, departure allowed. In simutrans it would solve the need for bidirectional signals. Look at the graph I posted yesterday. To get directional reservations in current circuit block, I would have to make the entry signal bidirectional. But then a train could depart and get stuck in switches. So a 2-block signal at the platform would be handy. But I think that a long-signal with explicit directional reservation would be a better solution to that.

Uff sorry if it is not consistent, It took me too long to write this (lots of interruptions like family lunch, etc...)
I hope to get the server working tonight - will be back at 64-bit machine...

And for the test game, it does not work. Here is what I did:

git clone --branch devel-new git@github.com:jamespetts/simutrans-experimental.git     
git clone --branch half-heights git@github.com:jamespetts/simutrans-pak128.britain.git 
cd simutrans-experimental; make;
cd makeobj; make;
cp build/...../makeobj-experimental ~/simutrans.pak128-britain
cd ~/simutrans.pak128-britain; make
etc, etc...
In the pak directory I have:
roadsign.lq-semaphore-token-narrow.pak
roadsign.lq-semaphore-token.pak
roadsign.lq-semaphore-token-white.pak
roadsign.two-aspect-colour-light-token-narrow.pak
roadsign.two-aspect-colour-light-token.pak
roadsign.uq-semaphore-token.pak
In game I cannot build any token signal, only plain signal, permissive (with disc), distant, combined, choose signal and one-staff cabinet.

[Isaac Eiland-Hall]

Installing g++ and libstdc++6-dev should be enough. Thank you in advance.

g++ installed, but couldn't find libstdc++6-dev. Will one of these do? http://addled.us/libstdc.txt If so, which?

[jamespetts]

I have been working on the time interval with telegraph working method to-day. I think that I now have something workable committed to Github. In short, it has the following properties:

(1) signals that have no junction of any sort between them and the next signal on a train's route behave exactly like ordinary time interval signals;
(2) signals that do have a junction between them and the next signal reserve a path to the next signal (no matter how far away that it is, unlike plain time interval signalling, where this is limited by line of sight) and will not allow a train to pass unless that route is free;
(3) tiles unreserve behind trains as with absolute block, track circuit block, etc.; and
(4) signals that have a junction between them and the next signal will never show a clear aspect, only a caution or danger aspect, and will restrict the working speed to half line speed (which is better than restricting working speed to the drive by sight maximum speed of (by default) 35km/h for junction signals in ordinary time interval working; this feature of junction signals, requiring slowing, is based on historical research).

Thus, to get full line speed on straight sections, players will need to place a signal a train's length beyond a junction. This requirement to slow at junctions should be a major reason to upgrade to absolute block/token block, which has no such requirement and can support full line speed at junctions (subject to any curvature based restriction).

As to single line working, this should be possible provided that all intermediate stations and the terminus station have signals and a passing loop. Unlike token block, this working method will not allow unsignalled stations or termini on single track sections. This, coupled with the speed restrictions, should be enough to give players an incentive to upgrade from time interval with telegraph to token block when it becomes available.

For players wishing to have a blind end to a single track section in the early days, one train staff would be the appropriate way of signalling this, and making that working method work properly is the next job (after fixing any bugs in this that anyone finds, at least).

I think that I will have to increase the signalbox radius limits as well as the number of signals that can be accommodated, however, to take account of the need to have these extra signals outside junctions not necessary in the absolute block working method and also the fact that trains are much longer (relative to the world scale) in Simutrans than they are in reality; I shall probably have to make this modification to other signals in the pakset, too.

As to the idea of allowing unidirectional signals to create a directional reservation, can I get an idea of which problems that this would solve if I were to implement this and which problems would therefore remain? How much more of Czech/Swedish practice could be simulated by this expedient than is currently possible?

Also, I should be very grateful for any testing that anyone is able to do of the time interval with telegraph working method for both single and double track running.

In respect of the compilation problems, these mystify me: I do not understand why things are not consistent on different computers. Can you make sure that you have the latest pakset sources from the half-heights branch on Github compiled with a version of makeobj-experimental compiled from the latest sources on devel-new in Github, and that it is a totally clean installation of the pakset (i.e., all old sources deleted)?

[Octavius]

I think many of the issues stem from different history in our countries. It seems that Czech (or Austro-Hungarian) and Swedish practices were in fact quite similar, while UK was in a bit different situation. The most important is, that all Austro-Hungarian railways were first built as single-track. The funding and revenues were not so big as in UK. Lines were upgraded to double track, only when the traffic was too high.

Yes, and mostly a matter of Britain and areas heavily influence by that country versus continental Europe. As far as I can tell, on most of the European continent (Germany, Switzerland, Benelux, Italy) railway practices have always been more similar to Austria and Sweden than to Britain. Or maybe one should say those countries were all influenced by Germany.

Back to the idea of special signals for directional reservations: Even in circuit block, you can think of the line as being split into small blocks - signal to signal, where only one train is permitted, and longer blocks - station to station, where multiple trains in the same direction are permitted. Making these blocks explicit (e.g. by redefining the use of long-signals), could help to solve also the problem of junctions without passing loops. No need to have two levels of signalboxes, just two levels of signals: block, and long-block. Is that description clear?

That's exactly the difference between automatic block signals (fully automatic, decentral, often permissive) and centrally controlled signals (human controller in a control centre, or a computer with manual override). That would be very intuitive to use for those somewhat familiar with real world signalling practices.

[Vladki]

g++ installed, but couldn't find libstdc++6-dev. Will one of these do? http://addled.us/libstdc.txt If so, which?

Thanks Isaac. Some libstdc++*-dev is already installed, and it seems to be sufficient. But compilation fails on missing zlib-dev (or libz-dev) and libbz2-dev.

In respect of the compilation problems, these mystify me: I do not understand why things are not consistent on different computers. Can you make sure that you have the latest pakset sources from the half-heights branch on Github compiled with a version of makeobj-experimental compiled from the latest sources on devel-new in Github, and that it is a totally clean installation of the pakset (i.e., all old sources deleted)?

I was trying that on clean install (as noted above):
git clone --branch devel-new git@github.com:jamespetts/simutrans-experimental.git     
git clone --branch half-heights git@github.com:jamespetts/simutrans-pak128.britain.git 

Now I'm trying with previously cloned tree and it is the same. But at first try I got all signal replaced by 4-aspect permissive signal. Though I could not replicate that. Now only the token block signal is missing.


Found the bug... Narrow gauge token signal had the same name... here is the patch:

Code: [Select]

$ git diff
diff --git a/makeobj-experimental b/makeobj-experimental
index fdde4c9..bfa2e4b 100755
Binary files a/makeobj-experimental and b/makeobj-experimental differ
diff --git a/ways/signals-narrow.dat b/ways/signals-narrow.dat
index 833c29d..318c2b1 100644
--- a/ways/signals-narrow.dat
+++ b/ways/signals-narrow.dat
@@ -871,7 +871,7 @@ Cursor=images/signal-icons-ex.5.5
 ---------------------------------------
 obj=roadsign
 copyright=JamesPetts-narrow
-name=lq-semaphore-token-white
+name=lq-semaphore-token-white-narrow
 waytype=narrowgauge_track
 cost=10000
 signal_upgrade_cost=5000

So now I have tested the token block example a little. I must say that the token block signals behave differently than I would expect. Reservations go ahead to the next token signal or end of line, if the passing loop is clear. In case the loop is occupied the reservation goes only to the loop entry signal. What I do not like about this setup is that it allows next train to start in the same direction, while there is a train in opposite direction waiting in the loop - this has a potential for deadlock, or at least long delay for one direction and bunching of trains.


Well I have managed to compile 64-bit version of server, but It fails. I try to run it with the following command:
./simutrans-experimental -load signalplacering -lang en -freeplay -noaddons -nomidi -nosound -objects pak128.Britain-Ex/ -server_admin_pw **** -server  -debug
And the last lines of output say:
Reading speedbonus configuration ...
Reading private car ownership configuration ...
Reading electricity consumption configuration ...
Reading menu configuration ...
Warning: create_simple_tool():  deprecated tool [27] requested
Reading object data from pak128.Britain-Ex/...
Segmentation fault (core dumped)

I have tried to comment out all menuconf items numbered 27, but it did not help.

[Ves]

Yeah it tends to get complicated when we are talking about three different systems, all very similar, yet very different!
I too apologize if im repeating myself or are unclear or contradicting myself, as this is a big subject and I tend to get blind by all the text

I am afraid that this is unlikely to work economically, and also has no historical precedent: it does not take more people to work a time interval with telegraph system than it takes to work a token block system: it is just that the token block system is safer and more reliable. After 1889, all passenger railways in the UK were not allowed to use time interval signalling. Many had already upgraded to absolute/token block decades earlier. There really needs to be a line capacity difference.

Ok, however (if we fail to find another reason) the lesser safety using time interval signals could be repressented with it being a higher monthly cost due more manual control is needed?


I have been trying out the time interval signals, and I think there are some issues:
Look at this savegame: https://www.dropbox.com/s/tj6eqm6gpsa5253/Time%20interval%20test.sve?dl=0
Let it run in fast forward for a minute and deadlocks will soon occur. Save for that I have understood and placed the signals correctly

Look at the station called "Sackfield Red Lane Railway Station" (sorry, forgot to rename the stations to something simpler before uploading..).
At the west side, when a train exits the station towards "Meningport Portley Park Railway Station", it will make a red reservation to the next signal after all the junctions, and at the same time, reserve a path from the choose signal onto an empty track at "Meningport Portley Park Railway Station"

However, the second train following the first one, will not make that reservation from the choose signal, allowing the first train to reserve the exit junctions on its returntrip. The train will depart and crash.
One could fix it by remembering how many trains are attempting to go out in one direction and always keep a reservation at the arrival station.
Another way could be to always make directional reservations between some or all slotted signals. That would actually be my favorite, as this would also make a clear distinction between slotted signals and non slotted signals.

Can either of you think whether there are any situations in which you would want a bidirectional signal that is not one that creates a directional reservation in the track circuit block method, or will having either bidirectional signals or "longblock" signals creating directional reservations suffice?

No, it is perfectly fine for me too to have bidirectional signals creating directional reservations! As Vladki writes, it is the possibility to create a directional reservation without bidirectional signals that is requested.


Regarding the working method at stations, I dont think I really cleared my thoughts before writing. Apologies, it was late in the evening over here

However, what I mean:

Drive by sight: Works fine on very small stations, where there is no risk of encounter head traffic, eg tramstop along a road. It doesnt work on big stations.
One train staff: Even if it is not currently working, this workingmethod will only work at end pieces of tracks, not associated with other traffic. If put at a bigger station, it will keep its reservations blocking other traffic.
Time interval: The choose signal of this working method behaves a bit similar to the absolute block. If no track is free, train will wait at the choose signal. Works for all stations
Time interval with telegraph: Same as Time interval
Absolute block: confirmed to be working
Token block: This working method works as intended through stations and on lines. However, it is very clumpsy to use at platformends at (bigger) stations, and as a choose signal (if there where any choose signal tokenblock) as the reservations will block other traffic. Therefore it is useless at bigger stations.
Track circuit block: confirmed to be working
Cab signalling: confirmed to be working
Moving block: The choose signals of moving block signals works as normal track circuit block choose signal.

The conclusion is that most working methods apply an "absolute block" mentality to their choose signals.

I did not ask for the program to define an area which is considered "station area", I merely concluded that with the available working methods and their choose signals, it might be possible to define a "station area" by your self. The challenge is to signal out from the station, as it is not always possible to use absolute block signals (or other station friendly signals) due to the station layout (for example my example diagram in an earlier post).
Hence the argue about a 2 block signal.

How I imagine 2 block signals to work:
2 block signals should only be possible to code as "absolute block", "track circuit block" and "cab signalling".

When a train approaches the signal, the signal will find the next signal of any working method in the trains path.
The 2 block signal will attempt to set the next signal to CLEAR by whatever rules the other signal follows. If the other signal cannot be set to clear, eg due to unable to create a directional reservation or not enough time has passed since its last train, the 2 block signal would remain at DANGER.
If the next signal is another 2 block signal, I suppose the logic has to stack, that would effectively become a 3 block signal.
If there is no signal before the next stop in the trains schedule the 2 block signal would act as a normal signal.
The "end of choose" sign could also terminate the 2 block functionallity, making the signal act as a normal signal.

2 block signals are to my knowledge commonly used in Sweden. The signals themself looks like any other signal, but they are wired to only show green if the following signal is also green. The "2 block signal" it self are used as end of platform signals, and are connected to the "exit" signal outside the station.

Ves: as to the spoken token block (D3 in CZ) - I think there is no need for different behavior to physical token block. I remember that at one such line, the driver had to get out of the engine, go to the station building and get the permission to continue by phone. Nowadays they can get it over radio or mobile phone, or a special radio device (RETB in UK, D4 in CZ), but that usually happens on places where those trains stop anyway. At least it would be an incentive to upgrade to proper signalling.

Yes, the spoken token was probably delivered like that. However, I am speaking of token block signalling as a concept rather than a practical use. In modern days, it is not difficult to program a signal imitate the "rules" of token block signalling and even one train staff. However in Experimental, the only way to simulate that is to use the said working methods but then your trains will stop at the signal.

As to the idea of allowing unidirectional signals to create a directional reservation, can I get an idea of which problems that this would solve if I were to implement this and which problems would therefore remain? How much more of Czech/Swedish practice could be simulated by this expedient than is currently possible?

It would feel more consistent and it would make it possible to create proper Swedish signalling from stations when using track circuit block signals. It would not completely solve the issues that the 2 block signal would solve, eg together with token block.

Now, my eyes ar blinded by all the texts 

[jamespetts]

Vladki - thank you very much for the bug fix: that is much appreciated. The fix is now pushed to the Github repository.

In relation to the token signals, this was designed to reflect real signalling practice at stations, where, on single lines, there was always a signal on the single track section outside a station facing into the station so that a train could start from the previous station even if there was a train in the next station. I do not know (and it is hard to find out) whether the same practice was used on passing loops without stations, but this would not seem unlikely given that they were functionally very similar, and, in any event, Simutrans cannot easily tell a station and a passing loop apart for signalling purposes, and any differential in treatment would probably be difficult to make clear to players.

As to your segmentation fault, this is difficult to diagnose without a debug output. Are you able to run this with GDB attached? (Also, may I ask that you post this crash bug report to another thread)?

Yes, and mostly a matter of Britain and areas heavily influence by that country versus continental Europe. As far as I can tell, on most of the European continent (Germany, Switzerland, Benelux, Italy) railway practices have always been more similar to Austria and Sweden than to Britain. Or maybe one should say those countries were all influenced by Germany.
That's exactly the difference between automatic block signals (fully automatic, decentral, often permissive) and centrally controlled signals (human controller in a control centre, or a computer with manual override). That would be very intuitive to use for those somewhat familiar with real world signalling practices.

This idea of a new form of long-block signal that would assist with simulating continental signalling practice: can anyone give a brief summary of how, in Simutrans terms (remembering how Simutrans works with signalling, as explained above)?

Actually, it would be very helpful to have a summary of problems and missing functionality necessary for at least the basics of German/Czech/Swedish/Austrian signalling practice, as this thread is very long and has a lot of long discursive posts that, whilst entirely appropriate in the context of the discussion as it has progressed, has made it very time consuming for me to distil the current wish-list so that I can give consideration to the suggestions at intervals when I have time.

It would be especially helpful if it were set out in the format:

Description of the problem: explain here why none of the existing working methods can accurately simulate a relevant part of  German/Czech/Swedish/Austrian signalling practice or why the system causes significant gameplay problems (such as unavoidable deadlocks in certain reasonable situations);

Description of the relevant real-world signalling practice: where this is relevant, explain here in summary (if appropriate, with links to outside material and diagrams, or to previous posts on this thread where this was explained more fully) how the relevant German/Czech/Swedish/Austrian signalling system worked;

Illustration of the problem: a detailed description of a specific set of circumstances in which the problem in question arises, preferably with diagrams, screen-shots and/or one or more saved games; and

Suggested solution: describe here what you think is an efficient solution (if you can think of one; this can be omitted if you cannot) working within the confines of the way that signalling works in Simutrans (do feel free to copy and paste descriptions of such things from posts above).

If I am able to spend less time searching through this thread and more time thinking of and implementing solutions to the issues that we have discussed, that will be preferable for everyone, I think. Thank you all for your feedback on this: it is much appreciated.

[Isaac Eiland-Hall]

Thanks Isaac. Some libstdc++*-dev is already installed, and it seems to be sufficient. But compilation fails on missing zlib-dev (or libz-dev) and libbz2-dev.

Installed: zlib1g-dev and libbz2-dev

Please do let me know if anything else is needed; of course I'm glad to do this as soon as I see.

[Vladki]

Installed: zlib1g-dev and libbz2-dev

Please do let me know if anything else is needed; of course I'm glad to do this as soon as I see.

Compiled sucessfully. Thank you very much.
Edit: one more install please libpng-dev is needed to compile makeobj. Thanks.

About the "new" long-block signals:

The way in which signalling logic works in Simutrans is that a train will try to reserve a route ahead whenever it first moves off. Whether it succeeds in reserving that route ahead will determine whether it is allowed to move off. It will iterate through each tile on its route until its next stop, and decide whether to reserve the whole way to its next stop, part of the way, or not at all. If it reserves the whole of or part of the way, it will start moving, and note the tile at which the reservation ends as a tile at which it will have to stop. It will prepare to start braking in time for that tile. As it approaches that end tile, it will check whether it can reserve further on, and the process is repeated until it gets to its next stop. The signals along the way, as well as reservations by any other train, just influence in various ways the logic used by the train in determining where it can reserve.

The long signal will do all of the above but before that it will try to make a directional (blue) reservation along the route (ignoring stops, junctions and ordinary signals) up to the next long signal, end of track or reversal point. If a reserved block for opposite direction is encountered, search fails and train has to wait. Reservation in the same direction is OK, search ends successfully, even if only a part of the route is reserved. It is questionable, what to do when the reservation reaches a choose signal. For simplicity I would end the reservation there as if it would be a long signal.

This may require a small change in the unreserving tiles behind the train. If the tile right behind the train is directionally reserved (i.e. another train is following in the same direction), then the recently freed tile should copy the directional reservation, so that there is no gap of completely free tiles. The following train would not have another chance to make another directional reservation. However tiles should become completely free behind the last train in sequence.

To the qouted algorithm, I have already proposed a change, that the regular reservation should reach to the next signal on the route, or reversal point, ignoring stops. Yes it would be somewhat similar to token block, but that is the way how reservations work (at least in Czechoslovakia). In contrast to token block, the track shall be freed immediately, although in reality, the track remains reserved behind the train up to the previous signal in either direction.

One more interesting observation from real world tram signaling: Normally trams run in drive by sight on double track, each track for one direction. However when the track is repaired, they have to pass a long stretch of single track. A simple solution would be to use one-train staff, but the traffic is so high that it is necessary to allow two or even three trams in one direction at once. So there are signals on the entry to the single track part. If the track is occupied by tram in opposite direction, it show danger. When the last tram leaves the single track, the signal goes off (clear), and trams can pass in the other direction. The still have to drive by sight, the signal is only about allowed direction of travel. If the above long-signal is implemented, this could be the long-signal for drive by sight. Or a hybrid signaling of track circuit and drive by sight.

I'll describe more, when I get the server up and running, together with a save game.