Status of CTC, Editor, and Hurricane Irma

I admit I haven’t posted much recently. But this is not because I’m lazy. Ok, sometimes I am. However, the focus has been on the editor, which turns out to be a bigger challenge than expected.

There are a lot of functional changes for editor support. E.g. to support an undo-function (and not to automatically save the whole scene every time you click the mouse button) one needs to register significant events into a log file in a meaningful way, but you need to read and execute the log file to make undo and redo work. This, however, adds an additional layer or way to input data to manipulate the scene, which is rather script based – like a comment file – on top of the way to change data via keyboard and mouse, and of course the coded file to read the scene data when you load it.

Then we want to make it all user friendly – we want to make a consistent feel among various parts, and you need to make decisions about behavior that you, the user, expect when manipulating anything. This is a challenge since the editor was started years ago, and over time early functional behavior sometimes seem to be out-fashioned.

And lets not forget that obliviously you need some documentation, a manual that explains everything – or at least try to.

Since one can get crazy with dealing with editor stuff all the time, other things have been addressed just for my minds sake.

So, the next release of CTC will have a different way to process purchases. In the future you will be able to view all available scenes within CTC, and you can select more than one item and put it into a shopping cart and pay for all of them at one. This was a suggestion from one or our users, and is a significant improvement over the current system where you can pay only for one item at a time.

And then there is this: we are located in an area that Hurricane Irma sets its eyes on. So it is possible if not likely that we may not have power or access to the internet for some days. Now, the website itself is not affected by this. So, unless you’re affected yourself, you can run CTC and access the website, even purchase things. However, registration codes may not be produced for a while. But don’t worry – you will get them once we’re back online.

Your WebRailRoaderTeam

Posted in CTC, Uncategorized | Leave a comment

CTC 3.20 about to be released

It wasn’t planned that way, but there were developments that caused us to release yet another non-editor version of CTC.

What happened is the speed issue. As some of our customers have noticed, the trains are somehow sluggish as far as acceleration is concerned.

The handling of that is based what we called the brake factor and acceleration factor. These are rather abstract numbers. We’re still using them, but it is now derived on parameter that can be better explained, and will be used for the editor. The territory files will have now these data instead of the factors.

One of our customers suggested that we implement the stop-and-proceed option, i.e. after a stop at a red signal a train may proceed with caution without the need to get an order from the dispatcher. Of course, if you take advantage of this feature, you have many more incidents of having more than one train in one block, and this revealed a few problems within CTC. There were unintended collisions – with problems on their own when trying to cleanup.

In short, a lot of debugging was going on. And we wanted to fix as many problems as we came across them.

So, besides the speed issue, a lot of other corrections went in.

As for the new feature, we decided to make it available only for the full version of the territories. Here you will have an option the stop-and-proceed feature for invisible signals only, or for all automatic signals – which includes the invisible signals and the visible ones where you set the automatic signal option on. If, however, such a signal would be able to clear a route running over switches, crossings etc., the stop-and-proceed function will not be applicable (this information is stored in the territory files). In a way, stop-end-process works very similar like pass-on-red, however, you don’t have to watch out for conflicting movements (except trains moving in from the other end into the destination block).

We have now updated all our territories and we expect to have everything released and uploaded in a couple of days.

Your WebRailRoader Team.

Posted in Uncategorized | Leave a comment

CTC 3.19 almost there

Just an update to my previous post:

First of all, we moved our headquarters. It is a pain, but we’re back on track.

The things I talked about the last time have been fine tuned. For instance, the blocks will degrade over time, and the system will put slow orders on sections if the conditions are too bad. You will have to schedule maintenance work for repair the track – but it is up to you when you want to do it.

The handling of train collisions will be different in CTC 3.19. Up to now we had the trains sit idle for some hours and have them “disappear” – as if the wreckage has been removed by truck or some other means. Now in 3.19, you will have to call in a ground crew to work on that. They will make the necessary repairs so that the train can be removed, presumingly under its own power. Just send the train to the nearest exit, and the schedule is done for the day. Since the trains have only the repairs to keep it moving, it will travel under caution speed.

The communications upgrade will allow you to call any train that is on the scene. So you can order to stop the train right where it is and give some further instructions. Also, if you have told an engineer to take a break, you can call him to cut the break short and start moving again.

This alone, the capability to call the train, should help tremendously if you like to play messy situations, where many trains are stuck and the train engineers call you pretty much every second. You might just miss the call from the engineer you really want to talk to, or the line is so busy that he cannot get through. In CTC 3.19 YOU can now give him a call!

As said, a few things need to be wrapped up, but the release 3.19 should be coming in the next few days.

Your WebRailRoader Team.

Posted in CTC | Leave a comment

What’s more coming for CTC 3.19

While we have completed most work for this, there is more to come which will have more direct effects on how to play the game.

Continue reading

Posted in CTC | Leave a comment

What we’re working on (between 3.18 and 3.19)

If you’re in the computer business, you probably know about some natural laws, for instance, there is no such thing as a last software bug – if you think you found the last possible one, there is another one around yet to be discovered.

Another rule is – and that is probably true for any business that delivers products and services – if everything is perfect and the customers love it, you do a re-design.

And we’re going to do just that. Not the whole thing, mind you, but for CTC’s routing feature.
Continue reading

Posted in CTC | Leave a comment

Coming up in CTC 3.18

The up-coming release 3.18 will include a feature, that has been requested by our customers – not that we didn’t think about it ourselves, but customer feedback is important to us, so we can prioritize our work, not to mention to correct occasional errors we may have overlooked.

Beginning with 3.18 you will be able to store routes for later execution. When the conditions are right, those “stacked” routes will be executed automatically.
Continue reading

Posted in CTC | Leave a comment

What’s next for CTC 3.17

The last couple of releases were addressing issues in schedules changes, i.e. when a train finishes a schedule at a station and takes over another schedule. This includes splits and merges. Believe it or not, there still was one error affecting trains in a block just a little bit larger than the train length, and the scheduling calls for a split. We’re not aware of such a problem in an officially released territory, but it came up during testing of one or our upcoming territories. The correction is verified and will be in 3.17.

Another thing is that we want to allow schedule changes outside the territory. There is one upcoming territory, where the dispatcher controls most of the tracks – except the tracks leading the end station for most schedules, because that station is handled by another dispatcher as part of another territory. So the trains would leave the territory to get to the end station, only just to come back for their return trip.
There are two ways to address this (similar to TDP): either create multiple entries, which means you put both trips into one schedule – which will make the stop list quite large if the train needs to stop at every station, or you let the train leave the territory which finishes the schedule, and the return trip would be just another independent schedule. This, however, is not realistic: when a train is late and has not left the territory yet, the return schedule may be activated and you get a new train coming onto the territory. Now you have two trains running when you really should have only one.
If you allow a schedule change outside the territory, this would fix this problem. The database structure permits such a setup, the checks have been modified to allow contents like this. Now we just need to setup a schedule and see how it works out.
Splits and merges would be allowed, too. There is no reason not to, but the handling is different if you deal with this within the territory or outside.

The numpad function is now complete and will be available in 3.17. The numpad function is another convenient way to setup routes by typing something like “123-456” into the numpad section of your computer keyboard.

Also in 3.17 we added the trigger function (aka buzzer function). It is not complete yet, as we have not added to play the sound yet. Furthermore, while the triggers are configurable, we haven’t added yet the saving and loading of the configuration data. We decided to keep that separate from the normal game status, since we believe it makes more sense to store it on a territory bases. That way whenever you start a new run (select date and time) you don’t need to re-configure the triggers again. We will also add (visible) automatic signals there and favored directions of entries/exits. The time factor will be added there as well, but it will be effective only in asynchronous mode.

Finally, we added a TDP-style running time if you cancel a route manually. This is done technically by extending the response time from the signal to 1 minute (visible signals will flash during the time), during which a route cannot be created that would be in conflict with the route just cancelled.

Posted in CTC | Leave a comment

What’s next for CTC 3.16

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.

Posted in CTC | Leave a comment

What’s next for CTC 3.15

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.

New Signal Types

New Signal Types


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.

Posted in CTC | Leave a comment

What we are working on (between 3.13 and 3.14)

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

Posted in CTC | Leave a comment