Suggestions to improve gameplay and UI

[wrrplayer]

There's been a long time since I was involved in railroad operation, but I still remember very well what I enjoyed about dispatching. I have no idea how dispatching systems works in other countries like Germany or the US, these suggestions may therefore not be correct in the existing territories. I've used the program only a few days, there might be that the suggestions already exists.

The "Buzzer"
The most irritating, but still important sound you can think of. When working dispatching only a station, the buzzer (which in my time probably was bought at the local hardware store) made a terrible noise every time a train approached the station borders.

The numpad
The numpad is what I miss most in the game. We didn't use keyboard or mouse, but a numpad directing trains. When typing "123-543" on the numpad, a route was laid from block 123 to 543. This makes the UI easier, and to me, more realistic. It's much quicker too.

Storage
If a route couldn't be laid because parts were occupied, the order 123-543 is stored in a priority list (where the first one stored has the first priority). When the occupied blocks are released, the stored route will activate, and be removed from the storage. On "my" station, we had 5-8 stored routes at each time, being 20-30 minutes ahead of time. The fun began whenever there was a delay or other unexpected events. Then you really had to be careful so stored routes didn't activate when canceling active routes. Canceling a route meant you got a "penalty time" (as a safety measure), and when canceling 2-3 routes because you didn't had control of your storage, the penalty time could cause even more delays.

Ordering trains
I would like to get a call when the adjacent stations are sending a train. It's important to know from the adjacent dispatchers that trains are leaving according (or not) to schedule. Which means I have to call the next door dispatcher when a train is about to leave my area.

Misc.
- When enabling Fast Forward, the setting is saved when exiting the program.
- The phone is excellent! But when I click the show me button, the phone hangs up as well. I have to give an order without knowing where the guy are, or I have to see where he is, but I can't direct him further.

The game is great! This is my 5 cents about the gameplay and user interface. It might be other priorities the developers have, and I'm exited to see the next update!

[DPump]

First, thanks for the nice response. Looks like you enjoy it already with what we have.

Whether Germany, U.S., or any other country, we try to cover several aspects that are in practice in those countries. So while it may not be exactly like in one particular country like Germany, at least you get a look and feel how it is like there.  It always can be refined, even the look of the display, but of course we don't know everything, and sometimes there are limitations you have to work with. Flexibility is the key.

(1) Buzzer: That is probably not difficult to do. It was not on my wish list, but I know other software have an alarm sound. TDP has this alarm sounding a female voice, which I personally didn't like - I don't think any real life system has it -, but a "bing" or "bzzz" sounds ok and realistic.

(2) Numpad: Well this requires a setup which makes sense. As of now, block numbers like "B21" that you see is really an internal key given by the system when the scene is created. While we can use that, it is probably not the best way to do that since there is no apparent structure in the numbering system. The name field does not provide uniqueness for addressing purpose. It would have to be a user-specific number that can be administered
Another possible solution is to make the key modifiable in the editor - something that can be applied to switches and signals, too.
I don't know it it really makes it easier. You still need to know what number to enter, and if you don't remember, you still need to navigate the mouse to find out what it is.
So, what we can do in a short term is to allow routing by entering the numbers on a keyboard (where you can use the numpad) like "123-543" as you said using the keys in the blocknumbers without the letter "B". You would not be able to use signal numbers (keys) that way.

(3) Storage: This is in the works. We will upgrade the routing system to include "predefined routes" for train routing (as opposed to switch routing) where switches not traveled by the train need to be aligned for protection of the traveling train, automatic routing of trains on approach depending on type of train, and storage or stacking as you mentioned. Penalty time is currently not a feature in CTC - the penalty you get is train collisions if you're not paying attention - well, not a safety measure, but if a route is activated it is not like the next train will run into it the next second, since the signal was indicating "stop" for that train just before. The penalty time is only important if you drop a signal on a train approaching that signal - and you set another route that would be in conflict with the originally set route. In CTC, dropping a signal does not cancel a route - that is a separate step you would have to do (only routes protected by hidden automatic signals can be effectively cancelled with signal in one step in CTC).
We'll going to think about implementing a delay timer, that delays the execution of a manual cancellation of a route, that would prevent the setting of a conflicting route.

(4) Ordering trains We think about it, but for now we put it little bit down in our priority list.

(5) Fast forward setting save: Hey, you're the customer.

(6) Phone: If you hit the show me button, the focus will be on the main panel. The phone conversation is still active, but don't hit the red phone symbol in the main panel there - this is indeed indicating you want to hangup!  To return to the phone conversation, you can either activate the form with the phone conversation  from the Window's task bar, or you can hit the <ESC> key. The Escape function will work as long the indicator marking the object is still shown, and you haven't done any other action on the main panel that would make it disappear (navigating with the mouse wheel is ok). The <ESC> key works the same way if you invoke the "Show me" function from other panels, e.g. if you look activate the detailed train information form. You can hit "Show me" where it is, <ESC> on the main display, "Show me" where the exit destination is, <ESC> again, "Show me" where the next stop is. You can go back and forth like that.

[DPump]

An update to (5):

Starting with 3.14, when you save a game that you want to re-load and continue to play some time later,  the time factor of the asynchronous mode is saved there as well as the fact that you have actually stopped the simulator at that time.

It makes more sense to put it there, not in the settings affecting everything globally when exiting the program. Time factor is something you usually like to be different for each territory. Furthermore, depending on time of day, at busy times you may want to use a lower time factor so you can keep up with the task.

Your WebRailRoader
Detlef

[DPump]

An update ...
(1) We have been working a trigger function in CTC. They can be added (by the scene designer) to a scene at any point, and the user can decide how to use it. Besides of hearing a sound, a symbol similar to a signal symbol will flash on the scene, and by clicking on it you can acknowledge it and silence the alert. You can set up how long the alert is active - including "indefinitely". Triggers can be added e.g. at entry points, but also at places where you have a very long block, and you want to be alerted when a train approaches the end of that block.
(2) We're also working on a numpad function. As mentioned on my post earlier, a block number (key, without the "B") will be used, but it will be possible to use also the signal number (key, without the "S") by hitting the '*' key on the numpad before the digits to indicate start and destination.
And finally a note to (3):
Sometimes you don't see the easiest solution: We already have a delay timer when the signal indication changes - the time needed to get a response from the signal that the indication has indeed changed and confirmed. This timer can be increased if a signal is manually cancelled. With this you essentially get a running signal like in TDP - or like in real-live CTC machines.
As you may know, in TDP the running signal starts only if a train approaches (not if the block is not occupied yet) - and you can avoid the running signal altogether if you stop the simulator, cancel the signal, and resume the game.
In CTC we won't allow such trickery. Not sure whether real-live CTC does not set the running time if there is no train in the block, but we will make no distinction.
Anyway, until the signal has "responded back", routes previously set with the signal cannot be cancelled, while trains approaching the signal would receive a "stop" indication. That is already there.
I'm wondering why I didn't think of it earlier ...

Your WebRailRoader
Detlef

[DPump]

The buzzer and the numpad function are now available in CTC 3.17.

Buzzers, as I mentioned before, are user-configurable, so you can have individual settings for each of the trigger points. The settings can be saved in a configuration file - also new for 3.17 (standard and premium only, same criteria as game status file). The settings are not considered part of the game status, so they won't be saved and loaded when you resume the game later. This way you can setup your preferred settings one time and load them every time when you start a new game or resume one.

Trigger points have been added at all entry points to all our territories, even free versions (except BNSF Alliance, where it is premium version only).

Penalty times have been added to the cancel signal function. You may cancel routes while the penalty time for cancelling signals is not over yet, but you cannot activate routes that are in conflict with the previously set route. If you have a drawbridge in the route, it will remain lowered - as a safety measure of course.

Storage is still in the works, and ordering trains is a possible part when we re-work the communication feature, which will include the capability of the dispatcher making calls (right now he can only receive ones) to train crews, other dispatchers, and maintenance crews.

Your WebRailRoader
Detlef

[DPump]

We are happy to announce that in CTC 3.18 we added the storage function to CTC.

It took a little while since we had to re-visit the routing function and to make some changes, not just for the route storage, but also in anticipation of additional routing types, e.g. switch routing on top of regular train routing, which is of importance in some real life systems. Switch routing will depend on the territory and will be phased in over time, but we wanted to make sure that route stacking fits nicely into the scheme of things.

The new feature is available across the board.

We have now implemented all suggestions in this thread except for "Ordering trains". As mentioned in my previous post, this will be part of a communications upgrade, as it is a prerequisite for the part to allow you to call the next door dispatcher. And then we have to think what to do if you don't call. Or if you send a train to the wrong exit. And how to synchronize with the inbound/outbound indicator. This is not settled yet, but we'll figure it out eventually.

In the meantime, enjoy the game and the new feature.

Your WebRailRoader
Detlef

[tve]

Just a couple of little suggestions:

Telephone conversation:
Could you revert to the normal, instant messaging style where the whole telephone message appears at once. The message text appears on the screen so slowly that I actually feel dyslexic - I (and I suspect most users actually) read faster than the text appears on the screen. Anyway, most of the messages are simply repeating the same format...

Cancelling signals:
There should be no requirement to set the signals to stop separately before running time. In several modern CTC interfaces the command to cancel the route also cancels the signal(s) automatically.

"Flashing" items/icons:
Any chance of getting an option to customise the rate at which the icons flash when a route is set or switch thrown? Depending on interface, I'm used to seeing indications flashing twice or four times faster, so slow flashing seems almost like nothing is happening.

NumPad:
When the from-to blocks have been entered, could the route flash on the screen before enter is pressed (so that it can be checked to be correct before command is sent?)

For the future versions with editor, I hope there will be a possibilty to give individual numpad codes for each route, and to also codes that can be used to cancel routes (individual code is required to set each route, but a single cancel code can be used for a group of routes that cannot be set simultaneously)

[DPump]

Phone conversation: The message appearance was changed to mimic the fact that in real phone conversations it takes time to convey a message when you need to say it. Reading is faster than listening (in most cases). We are thinking to even use sound to convey a message, so that you can listen to it (similar to the MS Flight simulator)

Cancelling signals: OK. Can add this as an option. We already do cancel signals automatically if they are hidden, so to do this for visible signals as well shouldn't be a problem.

Flashing: The rate some thing is flashing is tied to the refresh rate of the whole simulator action, which is 1 per simulator second. To make things flash faster would require to refresh the simulator action more often, or separate the display refresh from the simulator refresh. There is also the fact that the display refresh takes quite some processor time when you have a large territory with a lot of elements on it. So it is not as trivial as it might look, but it is worth thinking about it - I do like the idea to flash things faster as they do right now.

Numpad: When you enter the from/to blocks the route is by no means unique. For short routes it mostly is but for longer ones it is not. For this reason the only thing you can highlight is the from/to blocks - that we can possibly do.

As for giving codes for routes, we have been thinking about making it available for the user to configure this to predefine routes and show them in a popup menu when clicking on the start block. This would be a way to speed up route setting for the most frequently used. If you give them a numpad code we could use a prefix "/" to distinguish them from anything else you can enter. Use them to cancel this on the numpad is possible, provided that the cancel route option is on, and we cancel all signals automatically (as per your suggestion above).

Your WebRailRoader
Detlef

[tve]

Phone conversation: The message appearance was changed to mimic the fact that in real phone conversations it takes time to convey a message when you need to say it. Reading is faster than listening (in most cases). We are thinking to even use sound to convey a message, so that you can listen to it (similar to the MS Flight simulator)

It is actually easier to read and understand the message when it is all there. And you really do not need to simulate the outgoing part of the conversation, since the time it takes to select the correct answer is the time a person would spend speaking on the phone giving this answer.

Numpad: When you enter the from/to blocks the route is by no means unique. For short routes it mostly is but for longer ones it is not. For this reason the only thing you can highlight is the from/to blocks - that we can possibly do.

As for giving codes for routes, we have been thinking about making it available for the user to configure this to predefine routes and show them in a popup menu when clicking on the start block. This would be a way to speed up route setting for the most frequently used. If you give them a numpad code we could use a prefix "/" to distinguish them from anything else you can enter. Use them to cancel this on the numpad is possible, provided that the cancel route option is on, and we cancel all signals automatically (as per your suggestion above).

How about letting the territory author to decide whether to use the current numpad routesetting or predetermined routesetting codes by default (and possibly allow the end-user to switch freely between the two)? Adding another prefix or suffix kinda eats away the realism... If there's some sort of pop-up menu to show predetermind routes (and their codes?) when using the mouse, the user is likely to learn the syntax and logic of numpad commands at some stage if he/she finds the territory interesting.

I have sat at the desk of a 200-mile single-track territory, and all dispatching was done via relay-based system with 4-digit codes: two first digits were the station ID and the last two were the command. Two digits were enough to control stations up to eight tracks, but none had more than five (since the control matrix had no room for more than eight turnout control codes per station). The logic for this system was extremely simple to learn (it took about ten seconds), since the routesetting codes were the same for every station, with only minor exceptions.

Long routes were not supported with the older systems, but entering two routesetting commands as start and end, separated by a dash or a slash, would do the trick.

Also (and honestly, I cannot remember if this was implemented already), numpad plus and minus (in place of enter; or as a suffix/prefix to command) could be used to set and remove routes from storage. 

[DPump]

Phone conversation: It is all a matter of preference, but I do get the point about readability, so to display the text all at once could help (maybe as an option). However, I still like to mimic the time, which could be done by still offering the answering option after the message was "heard" completely. On the outgoing side, you can hang up any time you want, but if you have not waited until your message is out completely, your message will be ignored - you have to wait for the OK to come back. By the way - does it really take to much time to select an answer? It may take some time to provide a parameter, but most of the answer options don't have any or the parameter may be already populated (depends how you originate the call)

A route list is already part of the upcoming editor (of course without the code you suggested), and the route editor would be a good place to put some numpad code there (and the station id can be placed on the scene as plain text) The list is rather large, but I already checked that you can select a route in the list and it shows up active on the scene, so that certainly can help to configure route codes before you do anything else. Sometimes things just fall into place...

An option to require a prefix on route codes and none for regular entries or vice versa is certainly a possibility.

Re storage: if an entered route is not possible due to current condition, a message in a yellow bar appears just above the scene. If you right-click the yellow bar, the route will be stacked. With the mouse you can put a route into the storage without attempting to set it first. This is currently not possible via numpad, but we could make it by allowing a suffix "+". To remove a route from the storage, you have to go to Data->Stacked Routes menu. If we would add a remove to the numpad function, e.g. with a suffix "-". I don't know if it is useful - besides if you can have the same route stacked more than once, so either you mean to cancel the first or all of them.

[tve]

Sorry to dig up an old thread...

Main view zoom/scroll lock
Perhaps you could introduce some sort of "Lock the view" feature, so that once you have zoomed in to the territory you could lock the screen right there, and it would not zoom in/out nor it would scroll unintentionally. Perhaps it's just me, but every once and awhile I miss the element I was going for and accidentally move or zoom the view, and then having to re-adjust the view at some point. Just a thought though.

Entrance/Exit
The way entrances/exits are handled are a great improvement from TD3, but I am still a little baffled...

What my brain tells me that when I set a favoured direction to OFF, it should work just like a TD3 exit: there's no favoured direction so therefore it should be available in both directions. If you need to block an entrance there should be a clear statement like "Block this exit".

Also, single blocks that have a platform and are only used for scheduling can most likely live without entrance/exit direction.

In special commands there are options "Turn all links in/out" and "Set all links to favour in/out". There seems to be no difference in behaviour wheter I use "Turn" or "Favour", both react the same way when I try to create a route into an exit that has inbound arrow, ie. they won't let me create the exit route. 'Favour inbound' should allow exit routes, and then there should be a separate 'inbound only' setting.

[DPump]

Main view zoom/scroll lock:
The issue would be to introduce a quick function to toggle it on or off without the need to hit too many keys or even move the mouse around - and not to create a conflict with other operations. Perhaps we can look to introduce something like <crtl>-L. Yes, it happen to me too to accidentally move around, e.g. holding the mouse button too long and jerking the mouse.
Entrance/Exit:
It was never intended to make entrance/exit work like TD3, as I felt that in the real world you need to have some control who has the authority to send trains, you or your neighbor.
The favored direction is just a way to simply the operations. Lets say you have all entrances set to allow the trains to come in. But once in a while you need to let a train leave, so you set the direction to outbound and let the train pass. If the favored direction is set to inbound, CTC will set this exit to inbound a few seconds after the train is gone - so you don't have to do it yourself. The few seconds delay are there for the case you want to send another train to this exit just after previous is off the grid.
So, the favored direction is set if there is no traffic on the exit for a while.
If the favored is OFF, CTC will leave the directions completely up to you.
The difference between "turn all links in/out" and "set all links to favour in/out" will be apparent when you have set to IN on one and to OUT on the other. Lets say favored is OUT, and you hit the button to turn the links to IN.
Assuming there is no train on the exit, it will turn it to IN, let one in if there is one waiting, and later turn it back to OUT when the train is trough or if there was no train waiting to come in.
If you have a train on the exit, the exit will turn to IN as soon as possible, e.g. after that train left. That is the difference between "turn all links" and "toggle all links": the latter will not change the direction if a train is currently on the link, not even after the train is gone.

As for the block used for scheduling only not needing an entrance/exit direction: that depends on the scheduling, and the track configuration cannot be made dependent on the scheduling. You need to think about it this way: a block with an exit needs to be represented for your virtual neighbor as well - and this block would appear on both sides. In fact, to get the train out of your exit requires your neighbor to have a route from that block to wherever he needs (in CTC it is assumed this is the case). That's why you need permission from your neighbor to use the shared block.

This is also why you need to have the exit turned outbound for a route using the exit. You can always turn the exit the other way around (except there is a train right there), either with the special commands or by clicking on the triangle directly. Also you can stack the route and turn the exit afterwards. Even if the track is one-directional, you can manually override that temporarily before turning the exit (Exits that are prioritized to not allow to enter trains at all cannot be turned to inbound).

In this thread there is a point about ordering trains, which we still haven't done but are thinking about it - it would change the philosophy about the handling of the links a little bit, especially with our handling of the favour attribute of the links. One way to handle this is, if you don't call your neighbor about a train you want to send to him, you can send a train to the block with the exit as much as you want, but it would sit there and not really leave unless you make the call.

[tve]

This is also why you need to have the exit turned outbound for a route using the exit.

All I am hoping for is a bit more flexibility. If the arrow can be flipped manually, then setting a route should also flip it (and once the train is gone, it should flip back if not commanded otherwise). I see no point for the extra step.

If the arrow cannot be flipped for some reason (train entering, manually locked, oneway line, etc.), then the route, of course, can't be cleared.

Also, there really are situations in which the dumb TD3 entry/exit point is sufficient. The arrows are a great tool, but there are situations where one can live without.

For example, TD3-type entrances/exits at minor unmanned yards are sufficient, since a) there's no one there to give you permission to let the train enter the yard, and b) the crew would have to call you to get a permission to leave (which is beautifully realistic).

The arrows are a great tool for multiple-track exits in controlling the flow of trains, but for single-track exits they are useful only when you have a situation in which you need to prevent train from entering.

And what comes to those single platform blocks, such as the one in BNSF Stockton-Fresno Bakersfield, please make it so that the both ends are allowed to favour inbound at the same time and will automatically flip to outbound when a train enters. That way there's still manual control when needed, but at other times it's on automatic (I'd like to think that the platform is on someone else's territory and it is up to him to deal with it, except when I need him to rearrange the train lineup due to delays).

[DPump]

Flexibility is always good.
We will consider to have exits turned automatically (if possible) when laying a route towards the exit, possible as an option. This will be also effective if a stacked route is available for execution.

As for the unmanned yards, I believe that CTC has the flexibility right now. You just set the favored direction to outbound, and every once-in-a-while request to let a train in can be handled by toggling the exit to inbound - and when the train is through, CTC will turn the exit to outbound for you. In the future, when we have the capability to communicate with the neighbor about how to interchange the trains, some exits may be "unmanned", and the crew have to call you (instead of your neighbor), and some exits may be grouped together (one level higher than the group of exit tracks we have today), so you have to talk to that man responsible - this is a proposal of a fellow CTC user.

From what I know, in the real world you need to communicate to the other side whether you're allowed to send a train, especially if the connection to the other side is single-track. For double track this is not the case, unless you want to use a track typically used in the other direction. But for single tracks there is a handshake mechanism in force to prevent two trains heading towards each other on a single track (called a cornfield meet). Sometimes though it happens, when the system check is bypassed by some kind of special order.

The single platform blocks with exits on both sides - sometimes I wonder why somebody puts them on a territory. There isn't really anything that a dispatcher can or would have to do. Are there examples like that in the real world? I share your thoughts there, except there is not really much you can do to re-arrange trains, especially in TD3. In CTC, although both exits can be favored inbound, only one can actually be inbound. Otherwise it would be theoretically possible that two trains enter the same block from opposite ends in exactly the same moment. This, by the way, does give you some control by holding up trains so that they would not come back for a while on the rest of the scene because of the bottleneck.

I will think about your suggestion here. It is, however, not the same thing as the exits turning to outbound as earlier mentioned - because there is no routing involved.

[westdetroit]

Maybe it could be possible in the future to have trains listed in Data>Train Data in order by all arrival times. Sometimes it's busy enough that a train gets overlooked trying to "piece together" what order the next train will arrive. Also, their train lengths which would be helpful in determining if a train will fit in certain situations. P.S. And, I too agree about "locking the zoom". Keep up the great job!