Convoy re-combination

[jamespetts]

The idea of being able to re-combine a convoy as part of its schedule has been discussed intermittently for a while: see here and more recently here. This would have great advantages, particularly for railways, which for most of their history and until very recently operated on the premise of being able to exchange vehicles during a journey. Some of the vehicles in Pak128.Britain, for example, are premised on this idea: the Metropolitan Vickers electric locomotive for the Metropolitan Railway was only built because of the need to have electric traction in the central London tunnels where steam traction made things very unpleasant for passengers, and steam traction in the more rural parts of the line in Buckinghamshire where electrification was not cost effective. Were the trains to run in fixed formations as in Simutrans, no doubt multiple unit stock would have been built instead of an electric locomotive. The idea of a pick up goods train was fundamental to freight operations for over 100 years. Articulated lorries often exchange their cabs.

This has been a difficult idea to implement, largely because of routing. If the vehicles from convoy A combine with the vehicles from convoy B, is convoy A or convoy B destroyed in the process, and, if so, what happens to the passengers/mail/goods on board; when boarding convoy A, how will passengers/mail/goods know what destinations that it will serve once it has combined with convoy B?

From what I understand, no other similar game does anything like this. Railroad Tycoon did allow for changing of consists at stations, but only by adding or taking away empty wagons which would magically appear from nowhere and magically disappear into nowhere again when they were finished with. Transport Tycoon had nothing like this, and, having installed Open TTD this afternoon, it has nothing like it either. A recent feature request on the Open TTD forum along these lines met with the response, "no, that will definitely never work". Cities in Motion requires vehicles to visit depots frequently (as does Open TTD), but does not allow changing the makeup of a train (etc.) whilst it is running.

One possible solution to this is to allow multiple convoys to run together as if they were one convoy, but to retain their separate identities. This is, at present, just a germ of an idea, but it is an important issue that will have to be tackled sooner rather than later, and it is better if these things are canvassed as fully as possible as soon as possible.

Consideration will have to be given to the implications of this, and I should appreciate any feedback from any other developers on considerations that I may have overlooked which might present particular problems.

From a techincal perspective, each convoy could contain a singly linked list of attached convoys which could be iterated and actions performed on every other convoy on that list whenever actions are performed on the main convoy. Some possible implications of this, in no particular order follow.

   
• Graphics: how to draw the convoys? One possibility is to treat them as if they were a single convoy for graphical purposes, adding the graphics vehicles for all other convoys to the graphics of the lead convoy. The advantage of this would be that it would result in a consistent appearance, but it might be unintiutive, harder to maintain and more likely to introduce bugs.
• The information window: one per actual convoy, or one per set? The latter is probably better, although the question then arises as to how to indicate the differentness of the convoys to players. It would probably be easy enough to iterate through each convoy in the list to add information about the set of convoys in the information and detail windows.
• Railway signalling: this currently assumes one convoy in a section; some adaptation would be needed to allow for two. Consideration would also have to be given to a means of allowing a convoy to enter a section already occupied by another convoy.
• Combination order: how to achieve, semi-automatically, a correct order of vehicles (i.e. one that is allowed to proceed in that order according to the normal coupling rules) without allowing players accidentally to create situations in which convoys are coupled in a wrong order, preventing them from moving and causing frustrating backlogs and deadlocks?
• Schedules: the schedules would need new types of entry (similar to, but more sophisticated than, the "conditional jump orders" in Open TTD) allowing for this recombination. When multiple convoys travel together, the schedules of the convoys for the time that they are together must be the same; but how to enforce this in a way that is user-friendly?
• Other possibilities: a system of multiple convoys being linked might allow, e.g., a ferry with lorries or 'buses on board; but the graphics of those vehicles would then not be displayed on top of the ferry, unlike a train with multiple sections.

Any thoughts on any of this would be most welcome.

Edit: One other possible idea is to create a new class of a "convoy container", which is interacted with by many other methods in the same way as a convoy now, but consists of the list of the convoys in it, and calls to the functions of each of them in turn. This might avoid problems of determining which of multiple convoys' functions to call in circumstances where only one function should be called, and preventing functions being called more often than is correct.

Edit 2: Looking at the matter another way, convoys are already encapsulations of multiple vehicles (and, on looking at the code, I am reminded that signalling, for example, is a property of vehicles, not convoys). Another approach might be to have branching schedules, the difficulties of which in respect of the routing system may not be as difficult to overcome as I had first imagined, especially if a line could contain multiple schedules and if splitting and re-combining convoys switched to a different schedule in the line. The ferries might well require actual encapsulation, but that would be rather different.

[Aquin]

Another point will be the timing of merging convoys. Will the first half wait on the track until the corresponding second part has arrived? And some tool to synchronize the arrival times of the two halfes would be very usefull. Should the first part of the convoy be allowed to leave alone if the other part doesn't show up in time?

[jamespetts]

I should generally suggest that the answer to the last part will be "no", since the second part may forever be stuck if, for example, it lacks traction to go onwards. If the schedules are merged, it would also not know what its next stop will be: its final schedule item will be a special entry saying "merge with convoy of line X".

[Vladki]

What about having schedule for each vehicle, and forget the convoy of convoys thing? In most cases one would set the schedule for the whole convoy but coud set exceptions per vehicle. Some special commands in timerable would be needed - detach from current convoy, attach to other. All vehicles detached at the same time would form a new convoy.

Sent using recycled electrons.

[jamespetts]

How would that work for lines?

[Vladki]

Exactly the same. Line is just a timetable shared by some convoys. In this case it coud be shared by some vehicles. Or in other words vehicles that detach would form their own line.

Sent using recycled electrons.

[isidoro]

I can see a really interesting fresh application for depots there.  Change of composition of convoys is only done at depots now.  So it can be done by schedule there too automatically.

The idea works as follows:
1) You can insert a depot in the schedule/line of a convoy.
2) In that points of the schedule (depots) you can specify which vehicles remain, which will be dropped at the depot, and which new ones will join the convoy.
3) Loading/unloading is only done at stations, not depots.
4) If a convoy arrives to a depot and there are not available vehicles of the type required in the schedule to continue, it will stop there with a message (similar to the ones to signal "no route", etc.)
5) Goods/passengers ware (packets) are attached to vehicles, not convoys.
6) Each vehicle in a convoy has a property assigned telling if it will end in a depot (and which of them in the schedule) or will remain in the convoy forever.
7) A passenger/piece of goods will ride a vehicle only if that vehicle stays forever in the convoy or, if it is marked to be dropped, if the destination station is before the depot where that vehicle will be dropped.
As a direct consequence of 6) and 7) when a vehicle to be dropped at a depot arrives there, it will always be empty.
9) A so will be the vehicles picked at the depots when marked in the schedule of the convoy...

This can also be applied to locomotives, etc., although with less restrictions this time.  Since all the movements are done inside a depot, no traffic problem is generated, and a waiting time for the operation to be completed can also be simulated.

Hope my idea is clear, albeit not very sure about it...

[jamespetts]

Interesting idea, but this does not cover the many real life cases in which the makeup of a convoy (usually a train) is changed without it visiting a depot.

[kierongreen]

Edit: One other possible idea is to create a new class of a "convoy container", which is interacted with by many other methods in the same way as a convoy now, but consists of the list of the convoys in it, and calls to the functions of each of them in turn. This might avoid problems of determining which of multiple convoys' functions to call in circumstances where only one function should be called, and preventing functions being called more often than is correct.

This was the route I went down when I started working on this (I didn't get very far). The main aim initially was to allow for vehicles to be conveyed by ferries, but it would have worked for other transport combinations, as well as being the basis for splitting and joining services.

When you talk about splitting and joining though there are various different scenarios that need to be simulated - some of which appear simpler at first glance than they actually are. Two routes which I know reasonably well which have used splitting for many years are the Glasgow - Oban/Fort WIlliam/Mallaig and London Victoria-Littlehampton/Eastbourne/Hastings routes. At first glance these seem comparable - trains first split enroute, then one portion in turn reverses and some carriages continue through to a final destination.

On the West Highland Line  3 times a day trains leaves Glasgow made up of 2 or 3 Class 156 units. At Crianlarach the front unit usually goes to Oban, the rear 1 or 2 to Fort William, where 1 unit then reverses and continues onto Mallaig. In the opposite direction the reverse happens, with the same units recombining together (mostly in the same order). There are a few other services on this route - extra services just to Oban, and the Sleeper to Fort William for example but these don't interfere with the 3 splitting and joining services.

A much more complicated situation is the London Victoria routes (actually there are many splitting/joining trains out of Victoria towards the South Coast). Trains are twice hourly and formed from 3 4 coach units. Unlike the West Highland Line units do not remain in the same formations however. As far as I understand here is usually what happens - Hastings/Eastbourne and Littlehampton trains leaving London divide at Haywards Heath (front 2 units to Eastbourne, rear to Littlehampton). One train an hour continues to Hastings reversing at Eastbourne, with only 1 unit out of the two continuing to Hastings. The unit that remains at Eastbourne is attached to the previous hours service back from Hastings, arriving back in London 1 hour before the Hastings unit it had been coupled to. The unit that went to Littlehampton returns to London half an hour earlier than the Hastings unit it was couple to but half an hour later than the Eastbourne unit it was coupled to.

Simulating the first scenario is relatively simple, one convoi splits up and the recombines. Simulating the second scenario is much more complex - units don't join back to the original units they were coupled to, instead there's a wider pool of units which would somehow have to be grouped together (it would be interesting to see how Carl simulated these in his UK map!)

[Vladki]

Nice example. Lets see how it will work with my idea of per vehicle schedules. For starters you make three lines. Line L to littlehampton. Line H to hastings and line E to eastbourne. Build and assign some Dmus or Emus to these lines and let them go. Thats how it would work now. And here comes the fantasy.

Line H will get a new order for eastbourne station. Wait for any convoy of line E and join it. Line E will not get any such order thus allowing it to leave without waiting for H connection. (I assume the E line is more frequent than H).

On the way back they would split automagically because part of the train would have different next stop as the other part.

Line L would be similar to H. Just will get an order to wait for line E and join.

Hmmm. This took me to completely different idea. Real connections... Have an order in schedule to wait for arrival/departure of any convoy of line X. Wait could be limited by some max value.

Back to splitting... Freight trains would be much more complex. Lines would be esentially from one factory to another, plus loco only lines for main track and branches. Locos will go through all stations with nothing special in schedule and just pickup and drop off cars as they wish. Cars will have schedule like. Go to factory X siding, load 100%. Join loco line A. At some big station join loco line B. At another one join line C go only to your final stop (disconnect). wait for C to return, join B, join A, load...


There is a lot of loose ends regarding track reservation and platform usage, and schedule consistency...

Sent using recycled electrons.

[Octavius]

May work nicely with orders like "Transfer vehicles to line X", "Wait for vehicles from line Y" or "Pick up vehicles from line Z if available, else continue". Maybe one also needs orders to "Call convoy on line W" and "Wait until called".

3 examples:
X). This is how trains until recently (when a new line was opened) ran in the Netherlands. Line A has its terminus The Hague Central and runs from there to Utrecht Central. At Utrecht it has orders to wait for any vehicle from a line B convoy. Line B has its terminus at Rotterdam Central and also runs to Utrecht, where it has orders to join any line A convoy present. Line B terminates here. The convoy on line A, which now consists of 2 EMUs, reverses and runs to Zwolle, where it has orders to transfer the rear EMU (the one from The Hague, as it reversed at Utrecht) to line C. The convoy on line A continues to Groningen. Line C has orders to wait for a vehicle from line A at Zwolle. When the line A convoy arrives at Zwolle, a new line C convoy is created. This then runs to Leeuwarden. The line A convoy reverses at Groningen, the line C convoy reverses at Leeuwarden and both return to Zwolle. A has orders to wait for C, C has orders to join A. Combined they run to Utrecht, where the train is split in a similar manner. They used EMUs on which the passengers could move from one unit to the other whilst the train was in motion, although many travellers from Rotterdam to Leeuwarden (or the other way around, I don't remember) changed unit at a station. (Passenger trains have been dominated by EMUs here for the past 60 years.)

Y). Line A runs from Nijmegen to Alkmaar, consisting of either one or two EMUs. At Alkmaar station, it transfers the rear EMU, if present, to line B. Line B runs to Alkmaar reversing siding and, after some time, back to the other track of Alkmaar station, where it has an order to transfer to a convoy on line A. Line A continues to Den Helder and reverses there, before returning to Alkmaar, where it will pick up vehicles from line B if present (they will be coupled to the front). This allows running a shorter train at the ends of the line, but longer near the larger cities.

Z). Line A runs a goods train from Zürich to Erstfeld. In Erstfeld it calls for a convoy on line B and waits for vehicles from that line. We don't want waiting banking locomotives to wait at the main tracks, blocking the trains that don't need assistance on the mountain track. One of the banking locomotives stationed at Erstfeld and assigned to line B will come and the locomotive will be transferred to the convoy on line A. Merged into one convoy they move to Biasca, where the banking locomotive is transferred to line C. Line C just runs to the Biasca yard, where the banking locomotive will wait until called to assist a northbound train.

Would be nice to see car or rail ferries, rollende Landstrasse or channel tunnel shuttle services. Should give shorter loading times and allow any kind of goods on that ship/train. Could that also be with just the trailers of road vehicles, without the tractors? I've seen both on trains and ships that only the trailer was loaded on board, and it would be similar to recombining trains.