[Csantucci]

I have the intention to provide internal cab sounds (beeps and so on) related to the leading engine of a train passing a signal or a speedpost announcing speed restrictions or similar events. As signalling systems differ very much from country to country it won't be possible to develop solutions suited to every specific case. However I would like to try to provide a general solution as far as possible. To this aim it would be very nice if ORTS forumers of various countries could provide here some basic info on how this matter is handled in their national signalling systems. Links to videos showing such events and to simple documentation could also be welcome.

[PA1930]

This actually sounds like a great idea, but then again it will be difficult as there are indeed many different systems to "represent".

Speaking about the Portuguese one, also used in Sweeden, its the EBICAB700 (Sweeden is EBICAB900 but its basically the same...).

Only sounds you could implement on it are:
- Warning of next slower speed [it would be nice if one could make the yellow number be flashing as it aproaches the new speed limit ahead];
- Same sound but only one slightly longer "beep" for showing the new actual speed limit [fixed green color];
- Warning sound for overspeed on the current speed limit [usually starts warning at around 5km/h in excess of speeding and at 9 km/h it applies the brakes] - While on this, the overspeed warning there is also a flashing green light
- Speed displays can be already achieved but I think it doesn't work well on ORTS [yet] but it worked "fine" on MSTS. Though in general for these speed displays to be working the route must be ready for it as well. Currently it can only be achived with normal signals indicating a speed (lets say that one must set a green signal but showing a "Restricted" speed of, for example, 160km/h so that its shown on the speed display...) Though a problem with this is that the next speed display should only show something when there's a slower speed [yellow display], because when its for current speed it only shows on the green diplay...

Here's a overview picture of the EBICAB700 [we call it Convel, and shorter name for it is CNV]:

http://www.k-report.net/foto/i006514.jpg

Note that you can actually see the displays working and the yellow one is marking that the next speed limit is 30km/h and on the green display shows current max. speed which is 45km/h.

A further sugestion for this is that, if in some case the ORTS development team decides so, we should create a dedicated "forum" with topics for different kind of systems to be easier to organize the posts about what system we're talking about and trying to develop. Just a minor sugestion, of course. :p

Other system I could speak about is the German PZB and LZB, but I'm sure there will be more people here who know much more than me and are willing to share their knowledge about it... I know a big part of it due to driving trains on the German Train Simulator "Zusi 2" which is quite realistic in driving aspects but very poor in graphics. (Even though the 3rd version is being developed and it has stunning graphics).

[roeter]

Systems do indeed differ greatly per country, but two very distinct types of system can be distinguished.
One system is where sounds and indication are (more or less) train controlled, or at least continuous.
The other system is where sounds and indication are transponder controlled, and therefor set at a fixed location.

Examples of the first system are most modern systems like German LZB and systems used on HSL (including ERTMS (European Rail Traffic Management System)).
Examples of the second type of systems are all older types of systems, like German Indusi, British AWS systems etc.
Some systems are more or less inbetween, with no physical object to show the location but often the in-cab aspect does change at fixed locations. Those systems work either through rail-carried information or special induction loops, e.g. the Dutch ATB (Automatic Train Control).

Sounds and cabview items for the first type of systems can be defined in the engine-related sound and cabview file, and would take the required sounds and aspects from the next signal or speedpost, with continuous update for display and additional sounds if aspects change.

The second type of system would require location-fixed control objects. For sounds this could be a standard sound marker which somehow would have to be linked to the next signal aspect (in locations with short-distance signal placing these may even need to be linked to the second signal ahead). There would not be a separate sound on aspect change once the location is passed.
This could perhaps be managed for sounds, but it is, in my view, beyond what the present implementation for cabviews will allow.

Carlo, am I right in assuming you are only looking at implementing the first (continuous) type?

Regards,

Rob Roeterdink

[Csantucci]

Hi PA1930 and Rob,
thank you for your first contributions.
Some first points on how I foresee to proceed:
1) First of all I want to get some basic knowledge on how the most widespread types of signalling systems work
2) I foresee to implement and release things by steps, as I have also to increase my programming knowledge
3) For the time being there is an ORTS development directive that states that it is not allowed to implement additions or changes in MSTS files that cause unrecoverable errors when used under MSTS, and I of course will stick to that directive. Therefore for every function I will have to check if there is a way to have it working under such framework.
4) I see that signal sound management and cabview displays/controls are strongly related. If possible, and only if possible, I will link cabview display with related sound.
5) For many reasons I don't foresee to implement things like brake curves and in general controls on the train (with the exception maybe of some emergency stop), but only visual and sound indications. Of course I will be happy if someone would do that further implementation.
6) It can happen that some implementations will be too difficult to me to develop. In this case I will ask for help, that could arrive or not.
7) Important: while I will try to provide general sound triggers and eventually additional cabview controls, it will be task of the local content developers to develop related .sms and cabview files.

Now some questions and answers:
@ PA1930:
1) Can you give me the download links for the above loco/cabview and for an equipped route? I would like to check how it works in MSTS and how it works in ORTS, to see if ORTS compatibility with MSTS has to be improved.
2) Are in reality all routes equipped with such monitoring system, or not? And if not, is there some trackside table or similar indicating that such monitoring starts and ends?
3) Does the beep sound a bit before the new speed indication is valid, or just after it?

@ Rob:
I don't see at the moment the need to restrict work only on continuous train monitoring systems. Anything nearing the actual ORTS behaviour to reality is welcome in my opinion. Referring to sound markers, in my preliminary idea I dont' foresee a new type of markers, that would require changes in the MSTS RE and so on. So I think to base on signal markers, in two different ways:
1) adding to the management of signals that already are foreseen within actual sigscr and sigcfg files also the triggering of some sounds
2) foreseeing some MSTS and ORTS compatible new signals, whose main purpose is to generate a sound within the cab (e.g. start/end of a route section where an automatic monitoring system is available, change to national/ERTMS signalling system).

[copperpen]

There is no true AWS type of system in MSTS, it is not capable of using them. There is an in-cab advanced signal warning with in-cab display that does work, and this has been adapted to give an impression of a working UK style AWS system, using the alerter code to provide the warning sound and switch operation needed.

[Csantucci]

Hi Merwyn,
could you provide the download links for a UK loco and route where this mock-up of AWS works under MSTS? Can you explain how this advanced signal warning is implemented now (correspondence between signal aspects and lamps or similar within cab)? Does it currently work under ORTS? What is missing to better emulate AWS?

[gpz]

Csantucci, on 22 October 2013 - 02:25 AM, said:

Does it currently work under ORTS? What is missing to better emulate AWS?

For this one I know the answer, since I implemented a bunch of MSTS monitoring device functions by creating the TrainControlSystem class in the last months. And the only thing I haven't found any information on internet is how AWS in MSTS works. So it is not implemented in OR, but I would be happy to fill this gap if someone could provide some docs about how MSTS used it.

[JorD1]

Interesting topic.
I have a general thought about OR, especially with new futures like this one.
Why do you try to implement new general things to "old" cabs. Wouldn't that limit you'r options, or make it impossible to implement some features in later versions.

Isn't it a better idea to create a new Openrails equivalent of the old .CVF
One that allows scripting by the end user/Addon developer.

Then the builder of the cab could for example show the maximum speed, get signals. and process these to call sounds or show certain things on monitors/gages in cabs.

For example a dutch cabin with ATB train protection.
A cab script would be able to read the maximum allowed speed. (eg. 125)
The script in the new OR cvf could for example look something like this.
(Would be nice if you could also have the option to use a separate file which you call in the cvf.

if (MaxSpeed =< 130 && MaxSpeed => 100)
{
   ATB130=true; //Switches a light on showing 130
}

Or something like this:

OnSignalPass ("Proceed") //OnSignalPass (Signal status)
{
   Playsound ("bell.wav", 30, False); //Playsound(filename, length, repeat) A Stopsound( filename ); should go along when repeat is True
}
OnSignalPass ("Stop") //OnSignalPass (Signal status)
{
   If (PlayerSpeed > 40kmh)
   {
      ApplyEmergencyBrake();
   }
}

It would probably allow most in cab signalling and warning systems to work properly in OR.
Don't know if you guys know OMSI? It's a higly scriptable bussim, and nearly all computer functions of real busses can be made. Can be quit interesting to create something like that in OR too.

Edit: I want to add something I forgot.
I have the same feeling with the new OR activity files which are planned for 2.0 I think??
Why don't do rolling-stock and routes first. Would be a shame if the new act files would make certain things impossible when the route/rolling-stock files are designed.

[gpz]

The implemented functions and the format of cvf file can be separated, so it is not an issue now. :) No need to bundle one feature to the other.

[PA1930]

Csantucci, on 22 October 2013 - 12:37 AM, said:

Now some questions and answers:
@ PA1930:
1) Can you give me the download links for the above loco/cabview and for an equipped route? I would like to check how it works in MSTS and how it works in ORTS, to see if ORTS compatibility with MSTS has to be improved.
2) Are in reality all routes equipped with such monitoring system, or not? And if not, is there some trackside table or similar indicating that such monitoring starts and ends?
3) Does the beep sound a bit before the new speed indication is valid, or just after it?

Hi Carlo,

1) Unfortunatly there aren't any routes yet available with this system implemented on MSTS at 100%. What you could try is one locomotive already ready for this system with a French route that sometimes has some signals showing some "restricted" speed which is "compatible" with a Portuguese loco's. It is available on the internet but I feel more free to give you the loco myself just to be sure you're using exacly the same that I have: https://dl.dropboxus...9360/CP1960.rar (76MB) French route I'd sugest LGE V3: http://funtrain.net/...gnes/add-on-31/

2) Currently there are only a few routes not equiped with the CNV/EBICAB700 system, so when there's no system its the train driver's attention and knowledge of the route that works, as well of course there are trackside signals indicating speed limits. As for start and ending, usually you don't have any signals saying that the system will start or end (I know, sounds wrong, but that's how it is...), whenever the system starts it usually presents something three bars like this [---] [---] on both displays as well as with a beep sound informing the system has got info about the system starting on the beacons between the rails... And when getting off of the system, usually there's another "long" [maybe 6 seconds] beep and both displays turn off because the system now has got info that there's no new beacons on the route its running now. Sounds a bit confusing so any further questions, please ask. :)

3)On this case, the beep sound only sounds when the new speed limit is valid.
Here you can see this video a train driver made to just show something (it was just to show what the system does if he doesn't brake the train on time after the system telling him to do so...)

http://youtu.be/_rdI7UUCmiY?t=1m12s

Ok, so here's what happens: You can see that the yellow display is showing "6d" which means the train will be going to reach a place that the limit is 60km/h and its diverging in a junction.
The train driver shows what the system do if he doesn't reduce the speed when the green starts flashing the 6d, so the train applies the brakes... But then you can see that after the train is now on the 60km/h zone, it updated the speed on the green display with that beep sound and shows the 60.
On the case that if it was for example a reduction of speed from 100km/h to 60km/h without any junction, it wouldn't show the "d" next to the number. [I'm saying this just in case you have any doubt about what does that mean].

Again, any more questions, please ask. :dance3: