Softrail’s Train Dispatcher (TDP) simulation software is probably the best known simulation software of its kind, and there are a number of clones out there that mimics TDP’s behavior.
The CTC project was also started with that in mind, but with some differences to address perceived shortcomings of the then-latest TDP version 2.x. In particular, the way to set routes by turning switches and setting the signals seemed to be awkward for a modern way of doing this, considering running a computer program that should really be smarter (to their credit, TDP is handling a dispatcher territory like a real-life CTC machine would), So this method was never implemented in CTC. Instead, we wanted to simulate a real-life electronic system in a signal/switch tower or box, where routes are set by selecting a start and an end block – and the software and electronics does all the checking and figures out what needs to be done (this method was later added in TDP version 3.x). On the other hand, the communication via phone and a more realistic runtime model for the trains were part of CTC right from the start. Finally, CTC can run in real-time (synchronous to the PC clock), thus allowing the simulation to start with a lot of trains already waiting because of the “late” start. CTC does not have an end time, so you can run the software as long as you want.
Other clones of TDP, at least the ones we are aware of, appear to be much closer to TDP than CTC is. Therefore we will use TDP as a reference in the discussion below.
The purpose of both games are of course the same. Here are the major differences:
-
Platform, Work area and Station Stops in Schedules: In TDP platform stops are structured such that for each platform you have an indication whether to stop there at all, and if so at what time. A particular schedule may have stops at every platform, but only one stop per platform. At run time TDP figures out from this time information where to stop next.
There is also a list of work area stops. Such stops don’t have a departure time, and you can have up to ten work area stops in that list. They don’t have to be different – in fact you can schedule 10 stops at just one work area by listing it 10 times. At run time the next work area stop is determined by working this list down from top to bottom.
In CTC platforms and work areas are combined to stations. The station list is processed at run time from top to bottom – much like TDP’s work area list. A station stop can have the characteristics of a TDP-style platform stop or a work area stop. A particular station can also be listed more than once in a schedule, except next to each other in the same section. For older territories, CTC supports separate lists for platform and work area stops – however it uses the list structure for both, and like TDP CTC processes them in parallel if a schedule has both.
-
Route monitoring: in TDP you can basically route the train wherever you want, and if you miss a destination or a platform or work area stop, you will get penalty points, but nothing else. In CTC the train operator will communicate to you if he detects a bad routing. If you order the train to proceed as signaled, the operator will do so, but at a later point you have to address the problem somehow, as a schedule is not considered done until all scheduled stops have been completed and the destination has been reached. If you send a train to a wrong exit or if the schedule is not considered complete, it will re-appear. You don’t get penalty points – the penalty is that you need to fix the mistakes you’ve made.
-
Route canceling: in TDP you cancel a route by resetting the exit signal of the start block, and if a train approaches the signal, TDP starts a running signal timer (but only then) – unless the simulator is stopped when you reset the signal (!). In CTC you can reset the signal as well, but, unless the option to cancel signals and routes in one stop is set, a separate step is needed to cancel the route – or any section – itself. CTC also sets a “running timer” when a signal is reset by increasing the “response time” from the signal – independent of whether a train is approaching it or not. This includes automatic hidden signals. The trick in TDP to bypass the running of the signal timer by temporarily stopping the simulator is not possible in CTC: the simulator needs to run in order to reset a signal.
-
Route setting: In TDP you set the routes by throwing the switches in the appropriate position, and then clearing the exit signal of the start block. In CTC routes are set by selecting a start block, then a destination block. If a path exists between these blocks, CTC will throw the switches and set the signals (In TDP 3.0 this method of route setting is also available but only up to 50 devices)
-
Communication with staff: In CTC you just click a button or menu option if you want to change a train’s behavior, e.g. to stop or reverse direction. In CTC you have to actually “talk” with the train driver via the CTC phone. (Note: the communication model is similar to Skype: anyone logged in into the network can be called; and of course they can call you).
-
Train speed, block speed depending on signaling: TDP has different block speeds depending on how many signals are cleared ahead of the train. CTC has only one block speed, and by default each signal acts as a home signal which also has a distant signal to the next home signal. In TDP it appears that the train “jumps speed”, e.g. from 30 to 0 just like that. In CTC the train engineer will accelerate or slow down the train, and make sure that all speed limits and signal indications are followed.
-
Traffic direction on blocks: Both TDP and CTC have indications which direction a block may be traveled. CTC, however, does allow to temporarily override this restriction so that a one-directional block can be traveled in the opposite direction. Trains running under caution can also travel blocks in the direction normally not allowed.
-
Entrance/Exit points direction: TDP as such does not have an indication whether an entrance/exit point can be currently traveled inbound or outbound. In CTC, except for foreign tracks, you can set these points to inbound or outbound (if linked to a bi-directional block) as needed. You can also set a favored direction if you like.
-
Automatic Signals: Both TDP and CTC have the concept of Automatic Signals. However, while TDP adds automatic signals by itself and hides them from you (you don’t have any options unless you place a regular signal there), CTC has the concept of hidden signals – they are like regular signals but not visible on the diagram. There is no direct control of hidden signals, but in CTC if you know where they are, you can create and cancel routes very much the same way whether the start signal is hidden or not. Any visible signal can be made automatic while hidden signals are always automatic CTC implements automatic signaling by way of automatic route extensions, which means if the route is not automatically extended, you can still change the path by manually throwing switches or clicking a route yourself that is different than the original path. Note, automatic signaling for visible signals may look like signal fleeting in TDP, which is less flexible. Signal fleeting is not supported in CTC.
-
Stop and Proceed: This is tied to Automatic Signals, in that they can be set globally to Stop-and-Proceed instead of the Absolute-Stop variant. Stop and Proceed does not exist in TDP.
-
Time Handling: TDP runs the simulator asynchronous to the PC clock, and you can only change the speed on how fast the clock is running. While this is also implemented in CTC, you can also skip time (fast forward) or put yourself into sleep mode until you wake up when the phone rings or the buzzer sounds. Furthermore, you can set the simulator time synchronous to the PC clock (“Real Time”). In TDP you can do quite a few things when the simulator is stopped; e.g. throwing switches, setting signals. In CTC it needs time for these devices to “respond” back (symbols flash during this time), therefore you cannot even initiate such actions when the simulator is stopped: the only thing you can do is to look around and familiarize yourself with the scene layout and the schedules
-
Schedule Change: TDP’s schedule change feature – in our view – is a bit convoluted: You can set a schedule to let a train to become another one (and also split) while also have a regular exit, and depending on whether you hit the station or head to the exit, it will become another train or leave the territory. Complicating things: you can have multiple entries, and if the train hits the station during one of the multiple entries, the train will become another one at that time. The original schedule is then finished – unless you have a setup that splits off a 2nd train without becoming a new train itself. In CTC there is a clear structure: you can also have multiple entries (called sections), but only the last one can have an “exit” to a station (or platform / work area) where you can transfer to another schedule or two (split the train). That means you have to run through all the sections – and do all the stops along the way – before the train is taken over by another schedule (and split). CTC also allows transfer to another schedule on an exit group (assuming the station for the schedule change is just outside the territory), with the trains returning on the same group – as entry, but not necessarily on the same track. TDP does not have that capability.
-
Merge and Split: Besides of splitting trains via schedule change, TDP supports a merge and split of trains outside of scheduling, and because of that you have to activate the functions via special commands at the appropriate times. When you did the merge, you still have two trains which are just coupled together, and you can separate them later via split command into the original parts. You cannot split this way if you don’t have a previously merged train to begin with. In CTC, split and merge is available as part of a schedule change. You can specify more than one schedule to transfer to at the end of the run, and the train will split. If you specify more than one schedule as a source to transfer from, you have a merge. Merge and split will happen automatically as per schedule if the conditions are met. As mentioned before, TDP supports a scheduled split, but it does not support a scheduled merge. Note: the helper function, which is like TDP’s unscheduled merge and split, is not available yet in CTC.
-
Search and Find: When searching for a particular object, TDP places the mouse pointer at the location of this object. CTC puts a visual marker at the object instead in a way you can quickly locate the object. Furthermore, an option allows you to zoom in on this object.
-
Limitations: TDP has various limitations on how many objects of a particular type can be maintained in a territory. CTC does not impose such limitations, and also does not restrict lengths of strings or the size of the territory except as imposed by overall limitations of the operating system and the programming language C#. Most notably, names of entries/exits are not limited to just 2 characters and therefore can be more meaningful.
-
Slow orders: TDP allows to setup a number of slow orders, which are active at the specified time every time. CTC’s slow orders are not setup in the territory but rather set when the track condition deteriorates over time or by heavy usage. Slow orders can be lifted only by sending a ground crew to make the necessary repairs. Slow orders can appear on any regular block.
-
Block Orders: Like for slow orders, TDP has a similar setup for block orders. In CTC block orders are not setup this way, but you schedule the block orders for necessary repairs at your convenience. You need to call the maintenance supervisor for him to send a ground crew to do the work. Blocks can be set to “maintenance blocked” for any reasons. An “administrative block” is also available to flag an occupied track where local switching takes place (the functionality will be expanded in future versions of CTC).
-
Dead End Tracks: TDP’s architecture does not support dead end tracks – any block must be connected to another block, switch, diamond, or an exit on both ends. Most designers resort to some kind of fake, hidden exits to have something that suggests an end-of-track scenario. CTC supports dead end tracks using a control point with one signal – the end-of-track signal – where nothing is connected at the other end of the control point.
There are various other features which TDP offers while CTC does not, e.g. faulty equipment and crew time These things are subject to potential future upgrades of CTC. On the other hand, CTC supports more track elements, such as single and double slip switches, simple switches in 24 variations (including Y-switches), signals for tracks running up and down, and drawbridges.
For differences between the TDP companion Track Builder and the built-in editor in CTC see the introduction to the editor.
There are notes throughout this manual which help you to understand some other differences between TDP and CTC.
Please check the WebRailRoader Forum for any developments.