Topic: Early single track railways - how?!

[AP]

Hi All


I can't help but notice the lack of signalling in the earliest days of the railways in the pakset. In particular, there is nothing to allow a single track railway to operate at all.


The Swansea and Mumbles railway was apparently single track (from 1807), I don't know how it operated, but clearly, they must have had a system to stop two trains entering a block from opposite ends at once.  The Whitby and Pickering was single track from 1836.


However in-game, absent any signalling, in 1829 for example, single track lines do not work because everything uses drive-by-sight.


It is really problematic, because building a single track line represents a substantial infrastructure saving and they can be very effective if well operated.




The only workaround I can see, absent signalling, is to use a rigid timetable, but unfortunately the simutrans system of nonstandard clocks and fractional wait times does  not make this straightforward at all, nor allow sufficient fine tuning, for anything beyond the simplest line. As soon as block sections are of uneven lengths, for example, the system isn't flexible enough to allow a timetable to be created which is reliable and robust. The inability to fast-forward for testing purposes in online play, further impedes that approach.


Can anything be done?

[jamespetts]

There were no signalling systems on the earliest days of railways. I am not aware of how the Swansea & Mumbles Railway operated in the very earliest days, but be aware that the line was closed for many decades before re-opening in the 1850s, so it might originally have been double track all the way. Certainly, the very earliest railways were double track where they had to run multiple trains, as there was no means of knowing when a train is coming in the other direction.

The very earliest system of single track working was "staff and ticket", but this was in the days of steam trains. When I was implementing the signalling systems two years ago, I considered whether this could sensibly be simulated, but decided that it would be extremely likely to lead to deadlocks if it were simulated in any way that gave it any meaningful distinction from the later token block system, which requires the electric telegraph.

In short, there is nothing within the confines of what is reasonably achievable in Simutrans-Extended that can be done.

[AP]

I think this is a real balancing problem James.  There were early single track railways.  They are much cheaper to build (50% less earthworks, 50% less maintenance), yet we can't have them until someone invents electricity? It's nonsensical.

We need simple staff working implemented in the game or we are forced to build double track which is unreasonable.  You've chosen to restrict it to dead-end scenarios only (so called One Train Staff) which isn't realistic at all, it works perfectly well for intermediate block sections on a long single line.

You say "there was no means of knowing when a train is coming in the other direction" - yet with a train staff - one per block - there most certainly is (possession of the staff!).  Staff working of single track lines is intuitive, it does not rely on the electric telegraph, I strongly suspect that is how they were operated.

There are certainly records of train staffs being retrieved on horseback.

[jamespetts]

The trouble, as I wrote, is with the staff and ticket system, either this would be indistinguishable from token block or would lead to deadlocks. This has been discussed extensively in the past.

Also, how many early single track railways actually were there (pre-1850 or so)?

[DrSuperGood]

either this would be indistinguishable from token block or would lead to deadlocks.

In which case make it an early token block just for mechanics. One could make it more expensive to maintain than the much later form to encourage people upgrading when available, or even have it automatically upgrade.

[AP]

Just did a bit of searching for early precedents:

The Stockton & Darlington Railway (1825) was single track as shown in artwork of it's early days:




The Little Eaton Gangway plateway (1792) was single track: "by 1825, there were nine passing places on the single-track line".
The Haytor Granite Tramway of 1820 was single track (much of the stone track remains in place on dartmoor).

The Lake Lock Rail Road (1798) was single track:

In which case make it an early token block just for mechanics. One could make it more expensive to maintain than the much later form to encourage people upgrading when available, or even have it automatically upgrade.

'Make it automatic' sounds smart (i.e. as though prescribed by a change in the law). Putting artifical financial penalties in place for use of what is, basically, an inexpensive system ( a train staff is just a nice wooden stick!) , would also be a balancing issue, unless they were very slight.

[jamespetts]

Thank you for the research. AP - do you have any idea how these early railways regulated themselves? Did they use the staff and ticket system?

The trouble with the staff and ticket system is that there is no sensible way of determining whether a train should use the staff or a ticket, and if it makes the wrong choice, deadlock would result. There is also no sensible implementation for a mechanic to decide at which point that the staff should start. The token block system is an absolute block derived system, so will not be sufficient to simulate early working (as trains heading in the same direction would be regulated either by time interval, or, in the early days, drive by sight). In any event, an arbitrary financial penalty would be unbalanceable.

[Rollmaterial]

Could it be possible to simulate fetching the token on horseback? The game would map a section of track limited by staff cabinets and calculate the distances between them. A cabinet would then only let a train past it when the time necessary to ride back and forth to the one where the token is has elapsed.

[jamespetts]

Could it be possible to simulate fetching the token on horseback? The game would map a section of track limited by staff cabinets and calculate the distances between them. A cabinet would then only let a train past it when the time necessary to ride back and forth to the one where the token is has elapsed.

That would be fantastically complex, as it would involve route finding to the other end of the section (and what happens if there is no road?). Also, how would the game know when to fetch the token on horseback and when to wait?

[Rollmaterial]

Also, how would the game know when to fetch the token on horseback and when to wait?

When the token is returned at one cabinet, it would start a timer at all other cabinets of the cleared section.

and what happens if there is no road?

I would assume riding along the line.

[AP]

Also, how would the game know when to fetch the token on horseback and when to wait?

It would rely on the block section or equipment knowing the direction last travelled. And enforcing a strict alternating of directions.  or adding a delay to a train wanting to breach that (consist with waiting for the horse) ). Where it gets awkward though is if the horse is dispatched,  then a oncoming train arrives and takes the token before the horse arrives to collect it, in which case the token reaches the waiting train sooner than expected. 

If the oncoming train arrives after the horse has collected up the token,  the oncoming train has to wait for the original train.


I'm not sure it's worth the effort to simulate it 'properly' like that. Maybe just enforcing rigid alternate direction and let players build accordingly. The extra horseback feature could be added later.

I agree with James there is no easy way to simulate the ticket portion of Staff and Ticket without timetabling functions we don't have.

In terms of how those early lines regulated themselves,  I've tried unsuccessfully to find info on this
 But given they existed, and operated as single track systems somehow,  I strongly suspect they used a Train Staff or other unique physical token system,  which would have evolved into early staff and ticket system later. Staff working meets the KISS principle.

I will try to find the quote about transferring tokens on horseback.

[Vladki]

From what I have found out about early central european (Austro-Hungarian empire) railways, all of them were single tracked from the beginning. Only if they proved to be busy and profitable, they upgraded to double track. Sometimes, the earthworks (tunnels), were built wide enough for double track in advance, but some of them remained single track to this day. For example Kaiser Ferdinand Nord Bahn (Wien - Břeclav - Přerov - Ostrava - Bochnia near Krakow) the earliest steam operated railway in Austria, started in 1837. It was upgraded to double track in 1895, at least in the section between Přerov and Ostrava, where single track tunnel was abandoned at that time, and the track made a detour). Maybe some parts were double tracked earlier, but I could not find any info about that.

Before the advent of electric telegraph, optical telegraph was used:
https://www.flickr.com/photos/31724156@N02/3003040732/
http://www.laenderbahn-forum.de/journal/heldenzuege_1859/heldenzuege_1859.html
https://www.mdc.sk/stranka/strucny-vyvoj-zeleznicnej-techniky-na-slovensku-zeleznicna-oznamovacia-technika/

Unfortunately, I was not able to devise the exact communication protocol from the information on the above pages. All I know it was used to signal the direction in which trains are allowed to travel. Single signals are explained there, but I am not sure how the information propagated, when they wanted to change the direction of travel. There was also some sort of code with flags carried on train (engine) that were used to signal if this is the last train in this direction or not. But what is for sure, is that there had to be watch (guard) houses along the track so often that you could see the the optical telegraph signal from one house to the other. Lets say one per km or one per mile. That was very expensive, and introduction of electric telegraph allowed the early railways to reduce staff considerably. On the other hand these signals allowed the above mentioned KFNB to establish an early absolute block working (3-state signals) on double tracked parts, even without the use of electricity.

Also the horse-drawn railways, like the Budweis-Linz railway (1825) were single tracked. There the operation was managed by strict adherence to timetable, and regularly spaced passing loops. Other than that it was just drive by sight, so several trains could follow after each other in a given timetable slot. However the carriages were light enough, so that they could be derailed manually if two trains in opposite direction met in the middle of the track (too far from passing loop).

[jamespetts]

There is real difficulty in implementing section staff working (even without tickets) because of the way in which signalling in Simutrans works. Players just place signals, and the trains calculate the block reservation with nothing other than their position and route, the position and state of signals and block reservations.

Junctions are a particular issue: at a junction, it is possible (in Simutrans terms) for a single cabinet to be an entry point into what would in reality be two separate sections, diverging in entirely different directions. The actual code for signalling has no concept of sections as such: just a list of tiles along a train's planned route. It does not have any way of knowing whether there is an entire diverging route (and, if so, where that route goes): the best that it can do is detect whether any given tile along the route is a junction or plain track (as used in time interval and track circuit block signalling for various purposes). Thus, there is no way (without a very major rewrite) of the code knowing how many staffs that each individual cabinet should have, and which staffs should be given to which trains.

Also, there is no way of the code knowing which cabinets should be paired with one another so that, from the start, only one cabinet has the staff.

[Ves]

I believe timetables where extensively used.
Trains know they have to wait until the known trains in the opposite direction has passed.
But I do not believe that such logic would be anywhere easy to implement?
It’s “kind of” a token block, but where the time is the token...

Thinking about it, since more advanced timetables is quite off the table, we could instead turn the entire thing around and say that wherever the trains are IS according to the timetable. Then you could create a very simple signal, or post, where trains arriving will create a directional reservation, much like longblock signal does. The directional reservation would last according to existing rules up to a one way sign or choose signal.

[AP]

Could a cabinet not be created,  coded,  such that one must place them in pairs? Similar to how you place track, you must click in two locations. Then they would,  like industry links, forever know which their partner was.

It would then be possible for them to at that moment find the shortest valid route between them (on track tiles) and make and remember a list of every such tile.  And each track tile could remember it is controlled by staff cabinets x & y, and has a status associated with that.  Similar to how they remember wear factor.

Then when a train interacts with the staff cabinet, it talks to the paired cabinet,  and switches the status of the track tiles within the block.

The record just needs to be that the staff is at cabinet x, cabinet y, going from x to y, or going from y to x.

I suppose you could also have the train 'know' it possesses the staff as well, the track tile status would mean it already knows that possession is required to pass

[jamespetts]

The trouble with that (AP's) system is junctions - in reality, a cabinet at a junction would have multiple staffs for each route. Being paired with one other cabinet would cause problems if a train wishes to take a route that does not pass that other cabinet.

[Ves]

I edited my post without noticing both of you had replied! :-)

Thinking about it, since more advanced timetables is quite off the table, we could instead turn the entire thing around and say that wherever the trains are IS according to the timetable. Then you could create a very simple signal, or post, where trains arriving will create a directional reservation, much like longblock signal does. The directional reservation would last according to existing rules up to a one way sign or choose signal.

[AP]

The trouble with that (AP's) system is junctions - in reality, a cabinet at a junction would have multiple staffs for each route. Being paired with one other cabinet would cause problems if a train wishes to take a route that does not pass that other cabinet.

How are junctions a problem.  if you mandate that junctions have to occur at passing loops, ie not inside the token block section, just as in reality.  You just have three block sections, meeting at the junction loop. With a cabinet for each.

If you want the cabinets to occur on the loop, not on the single track bit, you'd be looking at a pair of cabinets at each end.  And therefore that junction loops would have to be double tracked for 1 train length past the junction in each of the three directions.  But that isn't terrible or too unrealistic.

[jamespetts]

I am not sure that I understand - how would the game know which tiles of track form part of the loop and which do not?

Edit: As to Ves's suggestion - how is this meaningfully different from time interval with telegraph?

[AP]

It would know by the fact that all of the cabinets associated with any given block were placed at the same time,  as a set.  Anything not in a block,  is therefore drive by sight.

Time interval with Telegraph allows multiple trains to pass in the same direction,  this requires strictly alternate direction operation.  Time interval with Telegraph allows multiple trains in the block at the same time given a long enough block and sufficient spaceing, this is absolutel block.

[Vladki]

How about just allowing time interval with telegraph, (which IMHO works same as staff+ticket), in earlier years, with different graphics - optical telegraph pole instead of electric telegraph pole. These early optical signalboxes would have much higher maintenance costs to match the fact that there had to be signalboxes all along the way just to relay the signal. Also carrying the staff on horse could be considered as a sort of telegraph communication (although very very slow one).

[jamespetts]

AP - the trouble is that it would not know what the extent of "a given block" is - the best that it would have is a list of cabinets, which would, by itself, tell us nothing about which tiles of track constitute a block and which tiles of track constitute a passing loop.

Vladki - I wondered about this, but it would not be suitable for the British pakset because, as far as I am aware, the optical telegraph system was not used in the UK. Also, the signalling at junctions is different with time interval with telegraph; it works similarly to the absolute block system, and does not have the sighting distance restriction of 7 tiles that the plain time interval system has when reserving tiles at a junction. Further, doing it this way, the extra cost of signalling using this system would be fixed and would not depend, as it would in reality, on the distance between each end of the section.

[AP]

James, no, I mean the cabinets when placed should run a routing check and record in themselves a list of all the track tiles on the shortest route between them.

At the same time,  flip a setting on each track tile so it knows it's part of the block. And possibly where the token is.

You want to ensure all the tokens start at the same end of each block,  so the first train along has one waiting at each loop. Maybe the end which has its cabinet placed first. Otherwise the first train could gridlock.

[jamespetts]

But then how would that work where the track diverges?

Edit: And also, what happens when a given tile is calculated as being in more than one section?

[AP]

The track should not be diverging within a block section.  A block section can only have two ends. That's part of the definition.

[jamespetts]

The track should not be diverging within a block section.  A block section can only have two ends. That's part of the definition.

How would that be enforced?

Also, how would this actually work? Surely the train would always need to stop inside the passing loop - at a point before the line re-converges into single track. That means that the cabinets would always have to be on track that converges and then diverges again at the next passing loop, and thus even in the simplest arrangement, there would always be two independent routes between two different pairs of cabinets on each single track section.

[AP]

If as was mentioned earlier,  you want two cabinets at each end, so they can be just inside each loop, clearly they will be in obvious geographical pairs. So you only need to find those pairs (by proximity of coordinate),  then a route between one of each pair. Or find routes between all 4 if you want to comprehensively define the block.

How would a prohibition on junctions mid block be enforced: by the signalling system breaking.  Players want it to work, ergo behaviour that is both unrealistic,  not as the tutorial, and disruptive to their own interests ,  seems unlikely.

[jamespetts]

I am asking these questions because I am trying to envisage the exact algorithm for this system, and I am still not able to do so from the information provided. You refer to geographical pairs by co-ordinates; how wide would you envisage the search area being? Remember, passing loops in Simutrans have to be much longer than in reality because of the relationship between the length of vehicles and the tile length, so, for long trains, one might imagine very long passing loops indeed. Now imagine every cabinet checking a radius of the maximum sensible length of a passing loop: this would give rise to two problems. Firstly, it would be very computationally expensive. One train staff cabinets check a radius of 1 tile. That is a total of 8 tiles to check. Increasing that radius by n would increase the number of tiles to be checked by n squared. Secondly, such a large radius could easily catch cabinets that are not intended to be caught, either on unconnected lines, branches, or even the next passing loop along in cases where the distance between passing loops is less than the maximum sensible length of a passing loop; given the proximity of passing loops on some early single track railways (1 mile, i.e., 1.6km on the Stockton & Darlington, for example), this can readily be imagined.

As to enforcing not having branching, the trouble is that players might want the signalling system not to function correctly if the incorrect functioning is beneficial, for example, allowing the far cabinet on a branching section to know whether the line ahead is clear without a train having passed it to give it the token, which I can imagine as one possibility.

The degree of complexity that one would need to overcome all of these difficulties would be very great, making this a seriously huge project to implement this one signalling system. Even if a workable algorithm could be found, it would be many years before I had the time to implement it, given other priorities. It would be different, of course, if another coder could be found to work on this; but the signalling system is very hard to work on, so an experienced coder would be required.

[AP]

The cabinets should automatically know where each other are, because they are placed as a set, 4 sequential clicks. It should be recorded at that time.  As for finding routes between them,  I assume that Simutrans has a very efficient system for that already!

If cabinets must be placed in sets of 4, then an in block junction and branch (which only requires an additional two)  could not be created as the cabinets should only be placed on the 4th click.

Since setting up a successful block marks each track tile as belonging to block A,  if they try to place the spare cabinets elsewhere,  to circumvent the issue, the routefinding check should fail if via a tile already controlled by another token.

[jamespetts]

This does sound as if it would require a huge amount of work to implement; and I am not sure how the requirement to have exactly four cabinets would work on a terminus section with multiple platforms at the terminus (for a single platform terminus, one might use the one train staff system).

However, one interim solution might be to bring forward the introduction date of the time interval with telegraph from 1848 to 1839. This website gives the date of the earliest railway electric telegraph installation as 1839. This was the Cooke & Wheatstone system, which was more expensive than later telegraph systems, so what I propose to do is introduce an earlier version of the railway policeman's cottage with telegraph equipment that costs more to build and maintain than the the current version introduced in 1848, but that is introduced in 1839.

Edit: I have now committed the above change, allowing time interval with telegraph signals (using the vane signal graphics) to be built from February, 1839. I have doubts that there was any significant use of the staff system before 1839 in any event; I suspect that timetabling and drive by sight was used in those days.

[AP]

Bringing it forward 10 years helps a little,  but doesn't help for the 40 or so game years before that.

If you're right and strict timetable working,  not staff working,  was the norm in that period,  Simutrans doesn't make any real provision for that. Which means that a chunk of the economic options to build cheaper industrial or light passenger railways,  is missing entirely.  Which may cause balancing issues. Maybe a bit of time needs to go on improving the timetabling functionality....

[jamespetts]

Bringing it forward 10 years helps a little,  but doesn't help for the 40 or so game years before that.

If you're right and strict timetable working,  not staff working,  was the norm in that period,  Simutrans doesn't make any real provision for that. Which means that a chunk of the economic options to build cheaper industrial or light passenger railways,  is missing entirely.  Which may cause balancing issues. Maybe a bit of time needs to go on improving the timetabling functionality....

I suspect that that would actually be much easier than the complexities involved in section staff signalling. What do you think that the minimum viable addition to the current timing system would be to allow for this?

[Vladki]

Hmm, what about allowing simple train staff cabinets for normal line, not only dead end. Perhaps it works even now, although a bit unintended. Passing lopps signalled like this:
.
I have that running fine, although now it is the only passing loop on the line (2 trains only). But I have an extra staff box on one dead end, at the entry to depot. But it works just fine. I think it works almost as token block.

In simple train staff system (without tickets), one would have to ensure that trains go in alternating directions to bring the staff forth and back. To enforce that, there would have to be a way to know where the staff really is. As the cabinet does not have any aspects like other signals, the staff presence could be encoded as an aspect (full/empty). Of course deadlocks will might occur, which would have to be resolved somehow. Maybe using the reservation clearing tool - first click will take the token from one box and second click will put it into another. Then a timer would run to simulate a courier carrying the staff (along the railway - either riding a horse or using a draisine). After the elapsed time, the staff will appear at the other box available for pickup.

This system is used even now: https://en.wikipedia.org/wiki/Kirnitzschtal_tramway
Just what I do not know how do they handle the train staffs in the morning, when whole line is empty and there is no tram in opposite direction to bring the staff back. And the same in the evening, when trams go to the depot. Either they cheat with the first few trams, or carry the tokens back by car - there is a road all along the track.

[jamespetts]

The one train staff system was intended to simulate one engine in steam working, rather than staff and ticket working: the idea is that the train reserves the whole route until it gets back to the (same or an immediately neighbouring) one train staff cabinet again.

I should note that the one train staff system already does use its aspect data to encode data about whether it is in use, albeit I cannot now recall the details.

[Ves]

This turned out to a lengthy discussion. Just to elaborate my point earlier in the thread:
The distinction between time interval with telegraph and my proposal is that my proposal is making directional reservations with drive by sight. There would be no timer in the signal to enforce spacing between the trains. The datfile would be:
Working method=drive by sight
Longblocksignal=1

I think this actually was suggested once a while ago too.