Release 4.0 now available

Great news!

It is finally there!

As promised here the latest (and hopefully greatest) is now online

Please go here to the download page and here for the user manual.

To access our forum click on the menu item “Forum” just above this post.

Your WebRailRoaderTeam

Posted in CTC | Leave a comment

CTC Release 4.0 almost ready

Here’s a follow-up on the previous post

Hurricane Irma has passed, and while we had some strong winds here, everybody here helped to push the storm to move somewhere else. So we were spared the worst of it (others were not so lucky). Power was interrupted at this place for 55 hours. All things considered …

So it is back at work. We’re getting close to release the next update, which will be major, major, major. It is probably a bigger update than the one from 2.x to 3.0, so the new version will be 4.0

We’re putting on the final touches now. You can expect the release within the next couple of weeks.

Of course, the work is not done yet. But we will have something presentable. Documentation, however, is still behind, and work on that will continue afterwards. We’re also planning to put some videos together, as especially the editor is quite different than what you’re used to from the TDP Track Builder, and it may require some time to get familiar with. So the manual/videos will be quite important. There will be also more posts right here in this blog for background information and such.

This is still work in progress, and of course we’re open for suggestions. Don’t hesitate to comment e.g. for missing pieces (or bad explanation) of the documentation. We certainly know that pieces are missing, but it helps us to prioritize things. And also, if anything seems awkward to you in the software.

Feedback is really welcome!

Your WebRailRoaderTeam

Posted in Uncategorized | Leave a comment

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