The WebRailRoader

The next release will address some issues that have come up, and also improve some performance.

One thing we didn’t get right is how to deal with schedules that run through midnight. It turned out that stops scheduled after midnight were handled as if the stop should have occurred the day before. This and also the difficulty how to deal with schedules that last even longer than 24 hours has lead us to introduce the relative time schedule. In short, for each schedule you have a reference time, and any other time information is relative to that. For instance, the reference time is 8 am. A scheduled stop at 8 am on the next day would be stored as 1440 – the number of minutes after the reference time. A stop at 9 am the same day would be stored as 60, and 9 am the next day as 1500.

Schedules for commuter lines quite often are separated into several tables like one for Monday through Friday, one for Saturdays, and one for Sundays – with a note that times after midnight belong to the previous weekday.
So in our scheduling we set the reference time to 23:59 (24 hr notation) while the train actually runs after midnight. It is listed in the Saturday schedule even though it would be Sunday already.

Another thing – not scheduled yet – is the possibility to set the reference time a little bit earlier than the arrival time on an entrance. Right now train are created from schedule and “activated” at arrival time, but with that there is no easy way to have the train running at full speed when entering the territory, which is a problem if the block is short and the signal at the end shows “stop”. With a reference time a little bit earlier, the train can be made “alive” then, and we have a better handle on the train dynamics even before the train arrives on the territory.

Speaking of scheduled stops with departure time: the status line will now contain time information, if the next scheduled stop has a departure time. It will show in relative time when the departure is supposed to take place – a positive number if it is still in the future and you’re good, and a negative number if you’re already to late and you haven’t even arrived yet.

One of the features that will be used in territories to be released soon is the schedule change while the train is on the territory, including splits and merges. Some of the issues we had here will be also addressed.

A little bit further into the future we will add the buzzer function which was suggested by a customer in our forum. We have already started to make some changes: the signal function will be enhanced to include additional functionality, one of which is the notification when a train passes that point. The signal function was chosen because signals are tied to the direction a train passes, and the signal display fits nicely for the new notification indication. And you can acknowledge the notification by clicking the signal. Another additional function will be to feature distant-only signals, including repeater signals.

As you can see, there are quite a few things to come, which makes CTC different than just being another Train Dispatcher or one of it’s clones.

CTC 3.14 was released a couple of weeks ago, which included the addition of the drawbridge feature, and a customer request to save the time factor along with other data when saving the status of the game. Even if the game was stopped at the time will be saved, too. This applies only to asynchronous mode.

One thing we’ve found is the tremendous amount of data that are saved and restored. This was especially noticeable when converting TD3 territories to CTC, where we use a streamlined method to generate the load data essentially the same way when you’re saving the game. But if you have a lot of start times, like every full hour for every weekday, you end up with a lot of load data. So we worked on that to at least reduce that amount by removing redundant data, e.g. a block to be initialized to free, when the load of the scene itself did the same thing already. That has reduced the data tremendously. While the reduced data already benefits scene loads with 3.14 (if re-generated), the reduction when saving user data will be made available with 3.15.

Another change for 3.15 is the addition of new signal types. Besides of the regular type, we added the switching type and the dual type – a combination of regular signal and switching signal. This reflects situations you may have in real life systems. We haven’t implemented the functional differences yet, so for now the new types document only the different intended purposes but work the same as the regular type.

There is also another signal type for a completely different purpose: the end of track signal. End of tracks are currently signaled with a hidden signal – a simple way to cause a train to stop at the end of the track. But there are real life systems, where routes are established by hitting a button at a start signal and another one at an end signal. For routes that can end in a stub track, there is a button at the end of the track that acts as an end signal. Our new end of track signal type covers this setup. End of track signals can never be cleared, and cannot be used as a start of route.

A picture is better than a thousand words. It shows a simple station at the end of a line with a run-around track.

End of tracks can still be equipped with a “hidden signal” – if that stub track is not intended to hold a train. Each of the signal types except for the end-of-track signal can be aligned to exit blocks heading left, right, up, or down.

Another item we’re working on is the merge of platforms and work areas.
Platform and Work area are very similar, in CTC more so than in TDP3. So we decided to add a new type, called “Station”, that features all of the above and then some. So, in a scheduled station stop you can specify dwell time, departure time (or not), new heading direction (or not), reverse direction (or not; here flip forward/backward), new length (or not). Exclusively to stations we will add a track number to station tracks and the schedule stop. This is to address a situation in large passenger stations, where a particular train is expected to use a particular track. The station is the same, but if you want to use another track as scheduled, you have to announce it ahead of time, so the people on the ground can prepare for the track change – if you don’t you can still do the stop, but you may have to wait a little bit longer before you can leave the station.

A CTC territory will feature either the station stops (which will be the default) or the platform/work area stops (as in TDP3), but not a mixture of that.

Sometimes things get a little mixed up of what you want to do, and what you’re actually doing, especially just shortly after a release update.

This is what happened.

There is one thing we haven’t mentioned here before at all, even though we have been working on this for quite some time. That is the CTC Editor.

There is not an official release of the editor yet, but we have been working on it “somewhere in between”. So consider the following a teaser.

We have all the elements of what one could call “low-level” editor. You can manipulate all components of each object type. This is simple enough for some, like switches and signals, but for blocks you have all the track elements (per grid square) that is part of the block description. And those elements are linked together in some way. That structure is reflected in how the editor works.

For instance, in TDP’s track builder, you select simple track elements and add as many as you want of this type just by clicking the grid squares. The TB will figure out which of the elements can be combined into a block.

In CTC you can do the same, but you have to define a block yourself first, and then add track elements within this block – these addition will not change how this block is related to other blocks for example. So this is actually more cumbersome than in TDP’s TB.

This is ok if you make only small changes, but if you start from scratch, it is not that great. Therefore the CTC editor has a drawing capability, where you would just draw a bunch of lines, like on a sheet of paper. Then you click a few buttons, and that bunch of lines will be converted to a list of blocks, switches, and what not, that makes sense for the lines you just have drawn. Then you can link them together, and you have a valid territory except for open-ended lines – blocks that link to nothing. With a few actions you can add group of signals at once, and open ends of blocks can be equipped with an entrance/exit, or just kept as a stub track with correct linkage. A – very technical – link maintenance tool is available to cover the rest, e.g. linkage of blocks that are visually separated but logically connected.

Much better, wouldn’t you say.

But that’s not the end of it. Especially for larger territories you can get lost what needs to be taken care of. On this we have been focusing the last few weeks.

For instance, the block lengths is one such thing. How do you make sure that the lengths are accurate – and you didn’t miss one? I have seen instances in TD territories where the lengths didn’t make much sense. So to help you with this, we added a feature into the CTC editor, where you can visually check the accuracy of the lengths. For instance, the 2 tracks of a double track line from A to B should cover the same distance. With this feature you build test routes from A to B with all the different variations you may have along the way, and you get a graphic showing all lines next to each other where the block length are accurately shown to scale.

Another sub feature of route testing is to get a graphic representation of all schedules that would touch some elements of the route. Here you can check if the times of platform stops make sense.

While working on the editor, we added the drawbridge object to CTC. This is something that doesn’t exist in TDP3, so we would not have to convert them from TDP3 scenes – in other words they are only handled by the CTC editor. While you cannot have simple lines cover drawbridges, you can place drawbridge objects on the scene that the lines from the drawing would be converted and linked such that the drawbridges are correctly linked to the other objects.

I know, all of the above is a little bit abstract without seeing an example. We’re going to make some videos so that you can see yourself how it works.

The drawbridge works now nicely in CTC, so with just some minor things to round it up, it will be included into the next CTC 3.14.

With this other things have been an a back burner I’m afraid to say. So unfortunately not much progress for helper function and enhanced signaling and routing. The reason I’m mentioning this here is that there was a recent suggestion to implement a route storage feature, in TB3 also known as route stacking. To set a route in advance and to activate it when it is possible after a conflict has been cleared, is indeed a nice feature we would like to add to CTC as well, so that is something we had in mind for some time as part of the enhanced signaling and routing package. The idea of numpad routing may be added as part of this package, too. The latter was also proposed in our forum, and that was definitely not on our idea list. But we’re always open to ideas and suggestions.

But for now, it looks like CTC 3.14 will have the drawbridge (almost finished) and some other more technical changes. It is the technical change that causes us to move ahead with an official update – it is needed for a territory conversion from TD3 to CTC.

As always, enjoy the game.

The WebRailRoader Team

First my apologies. Yes – we promised to have the helper function available for 3.13, and some pieces are already in, and while we got already trains pushed by a helper working, there are still things to do, like when to engage, when to disengage, communication, and some other interaction. The new territories that we placed in our directory (and another coming soon) don’t need helper function, but they make use of the foreign train feature. So we included the foreign train feature, and made some other corrections for 3.13.

The foreign train feature, by the way, works different than TDP3’s version. We don’t have the automatic feature, but our traffic is directional. So you can see from where the train is coming from. Not that important from the function point of view, but we think it is more realistic. When converting TDP’s numbers of train frequency, we split them in half between either directions of a single track crossing. For double track crossing, we assign the whole number of one particular track to one direction, while placing the number of the second track in the opposite direction.

The new territories have foreign trains running in the FULL version of the territory.

But for the next version of CTC we think we will have the helper function completed.

We also have started working of enhancing the signaling and routing function mentioned in my previous post. The first step is to define fixed route sections, which are regular route sections but with additional information to align switches which are not traveled by
the train using that route but rather protecting it. They will be used for train routing – as opposed to switch routing. Switch routing will continue to work as before – creating dynamic route sections as needed, however it will be possible to route into an occupied track, and the signal indication will be a steady yellow signal symbol.

We might throw in a drawbridge track element for the next release. Some territories in our library suggest some drawbridges on the scene, but only as a comment. But we all know, that it takes some time to lower and raise a drawbridge – more so than for street drawbridges. Also, railroad drawbridges are normally open for boat traffic, and lowered only if a train approaches the bridge. And there is ample advance warning for the boat traffic before a bridge is actually lowered.

Once we have the drawbridge feature implemented in CTC, we will modify the territories to make it real.

As always, enjoy the game.

The WebRailRoader Team

CTC 3.12 was mostly about adaption for TDP3 territories, e.g. possible multiple start times on a particular weekday – or even non at all, and pick a couple of trains of a regular schedule, and place them where you want. We actually run those trains – and only those – and maneuver them so that they get to the supposed starting blocks. Then we save that game status and incorporate that into the scene data that you can download.

The conversion of TDP3’s train schedule handling turned out to be tricky. There are some conditions where decisions need to be made to fit in our CTC scheduling scheme that are not so obvious. That involved some TDP3 investigations – we almost can open now a TDP support group – except for serial number lookup we probably can answer any TDP question you may have.

Anyway, because of this, we haven’t completed the helper function and the foreign train handling yet – we decided to delay that and do it for 3.13.

But we don’t want to do only what TDP does, we want to do something more.
For instance, we are thinking about expanding the signalling and routing by differentiating between train routing (from station to station) and switch routing (typically within a station) Switch routing allows routing into an occupied block and the train runs under caution – since this is switching. And you have – in a station – far more switching signals than signals for train routing. And while switching only signals have to be clear (or at least neutral) for a train route, the train’s behavior is really governed by the train signals as opposed to the switching signals.

Another thing we want to add is “more comfortable” routing, like pre-progamming a route that would not be possible at this moment, but would be set once it is possible, or automatic routing based on train types, destination etc.

As always, enjoy the game.

The WebRailRoader Team