[charland]

Hi James,

I did have an idea you might think about. The other day while testing I was running on a double track mainline that eventually reduces to single track. The display in the current track monitor shows two lines representing the tracks, that could be the display for a double track main and then change to single track where appropriate, even showing the upcoming switch so you know if you're staying on the main or going through the switch.

Just a thought.

Paul :-)

[James Ross]

markus_GE, on 11 June 2014 - 05:05 AM, said:

On I side note, yes, it is a simulator, but why should we have driver aids that are not part of the cabview but that are modeled to reflect a real thing, specific (in this case) only to Europe? Personally, I´d rather go for something they way we have it now, generic and applicable to every route, no matter where it is located. Just with the indication of the currently next few mileposts added, to what we have now.

This is why I'm not committing to using any of these things exactly as-is. They have had a lot of design and testing input, however, so are reasonable designs to base things on. I'm not sure what about their designs might be Europe-centric but we'll sort those issues out testing the new UI. :bigboss:

[gpz]

James Ross, on 11 June 2014 - 03:42 AM, said:

This is interesting. It actually reflects a number of ideas I am including in the new UI (grade changes, for example). I suppose it makes sense, but I did not expect a full 'track monitor' like system to be defined. Anyway, like the speed gauge, these will serve as inputs in to the design process and may not be followed exactly.

Whatever the future track monitor will look like, it might be worth looking at the specifications of ETCS DMI on the link provided by Serana, or saved here. When one is unsure about how to show a specific information, it is easier to follow the spec. And when the outlook is close to the spec, then it might be better to be exactly by spec. Most probably a team of specialists worked on it for years, developing what and in what way to represent to the driver.

It is just a thought though. Most probably comes from my work as engineer: when there is a standard, follow it to the finest details, no matter what you think about it. This is the only way to get permissions and certificates for the plans. Of course there is no need for a game program to be certified by authority. :bigboss:

[gpz]

markus_GE, on 11 June 2014 - 05:05 AM, said:

On I side note, yes, it is a simulator, but why should we have driver aids that are not part of the cabview but that are modeled to reflect a real thing, specific (in this case) only to Europe? Personally, I´d rather go for something they way we have it now, generic and applicable to every route, no matter where it is located.

I'm not arguing to use exactly this design. But please note, it is very similar to our current track monitor, and is capable of displaying all the information we need for the simulator. It is not specific to only Europe (used/planned also in China, Australia, North Africa), although I doubt it is used in this form in North-America. But if there is no such "track-monitor-like" display used in NA at all, then it is even more reasonable to use this one. It is also more fun (at least for me) to use something that is known to be used by real drivers too. As you said, this driver aid is not part of traditional locmotive's cabview, but so isn't the original track monitor too. And if there is to choose between something fictitious and real in a simulator, for me the selection is trivial. Just a couple of arguments...

[James Ross]

gpz, on 11 June 2014 - 06:00 AM, said:

Whatever the future track monitor will look like, it might be worth looking at the specifications of ETCS DMI on the link provided by Serana, or saved here. When one is unsure about how to show a specific information, it is easier to follow the spec. And when the outlook is close to the spec, then it might be better to be exactly by spec. Most probably a team of specialists worked on it for years, developing what and in what way to represent to the driver.

I certainly intend to read the specification and use it as a good input to the design process. Of course, we have different issues and there will be things we have to add to it because its a simulation.

[Theo]

Is it possible, to include an option, to show all Information Windows (TrackMonitor, ActivityWindows and NextStationWindow) on the second Monitor in an two Monitor System?

[markus_GE]

gpz, on 11 June 2014 - 06:18 AM, said:

I'm not arguing to use exactly this design. But please note, it is very similar to our current track monitor, and is capable of displaying all the information we need for the simulator. It is not specific to only Europe (used/planned also in China, Australia, North Africa), although I doubt it is used in this form in North-America. But if there is no such "track-monitor-like" display used in NA at all, then it is even more reasonable to use this one. It is also more fun (at least for me) to use something that is known to be used by real drivers too. As you said, this driver aid is not part of traditional locmotive's cabview, but so isn't the original track monitor too. And if there is to choose between something fictitious and real in a simulator, for me the selection is trivial. Just a couple of arguments...

James Ross, on 11 June 2014 - 06:23 AM, said:

I certainly intend to read the specification and use it as a good input to the design process. Of course, we have different issues and there will be things we have to add to it because its a simulation.

That´s both good to hear. The only thing I don´t want is something totally like ETCS interface, cause it´d make driving an American train feel so European :oldstry:

Also, I now better understand your rationale. :sign_thanks: for explaining :D

Cheers, Markus

[James Ross]

Theo, on 11 June 2014 - 10:57 AM, said:

Is it possible, to include an option, to show all Information Windows (TrackMonitor, ActivityWindows and NextStationWindow) on the second Monitor in an two Monitor System?

Not at present but it's on my list, and as I have multiple monitors, I'd quite like it too, so things may happen given time, but it's not a simple feature (and there a variety of ways we could do it).

[Lindsayts]

Some thoughts on a track monitor for a train sim. Why is it required?
I am certain James knows these points, I put them up as some of these are not very obvious.


First point,
In a real world in order to bring say a fast freight to a stop at a signal, the signal would need to be visible for over 1.5 kilometres. Using the current computor displays availible this is not possible. Using a 2560x1600 display its possible under most circumstances to identify a signal at 1000 metres but its not reliable on MSTS/OR.
The original version of Kuju's train simulator magnified the signal itself around 2 times at distances so one could more easily identify a signal.
Generally though the solution to this is to provide a signal display so one can readily identify signals in the distance.

Second point.
I do not know about the rest of the world but in Australia. All drivers must be route certified before they can drive on the route, ie all drivers new to a route have a period of training so they can get to know the route.

In a train sim this sort of thing is not feasible so some kind of track display needs to be provided so up comming changes in the track can be seen enough in advance so the driver can take the required action.
Things that will need to be displayed is (at least) changes in grade, curves with speed limits and distance to the next station would be nice. A thing effecting the last item is we currently only have a flat display so we have no depth perception so one has difficulty when one does not know the route of judging the braking when stopping at a station.

Lindsay

[Lindsayts]

An additional point on siting signals, in real life railways usually have some kind of signal siting group who's responsibilty is to see that all signals are visible at the required distances. Now a thing I have found is a good percentage of route developers do not always understand this point and it is not uncommon for some signals to be obscured by objects.
So this is an additional reason.

Lindsay