[copperpen]

If you look at the right side of the cab panel, you will see the in cab next signal display, in this case using a form of the position light signal. As for the "OK to proceed" sound, in the Dorset Coast route and several other UK ones that has been replaced by a whistle and "Right away driver" which does work in ORTS. I think the failure of ORTS sound is the same as MSTS, it cannot be located where specified or the main sound folder.

[Csantucci]

Sorry Merwyn, I wanted to say that the "Permission granted" sound does not play in ORTS (neither should be "Permission denied")

[gpz]

PA1930, on 22 October 2013 - 03:57 PM, said:

So here's the "coding" part on the cab for the current EBICAB system implemented on the loco:

Digital (
			Type ( SPEEDLIM_DISPLAY DIGITAL )
			Position ( 236 287 24 12 )
			ScaleRange ( 0 120 )
			Accuracy ( 0 )
			AccuracySwitch ( 0 )
			LeadingZeros ( 0 )
			Justification ( 3 )
			PositiveColour ( 0
				ControlColour ( 255 200 0 )
			)
			NegativeColour ( 0 )
			DecreaseColour ( 0 )
			Units ( KM_PER_HOUR )
		)
		Digital (
			Type ( SPEEDLIMIT DIGITAL )
			Position ( 290 287 24 12 )
			ScaleRange ( 0 120 )
			Accuracy ( 0 )
			AccuracySwitch ( 0 )
			LeadingZeros ( 0 )
			Justification ( 3 )
			PositiveColour ( 0
				ControlColour ( 128 255 128 )
			)
			NegativeColour ( 0 )
			DecreaseColour ( 0 )
			Units ( KM_PER_HOUR )
		)

Looks like noone understood fully what is the difference between the two speed limit cabview controls. :) Currently SPEEDLIMIT is not used at all in ORTS, and you say SPEEDLIM_DISPLAY is used instead of SPEEDLIMIT. I look at it.

[Csantucci]

SPEEDLIMIT should have been introduced by MSTSbin. At page 17 of the manual one can read the following:

Speed limit (current 
(only for signal lights)

(		Dial (
			Type ( SPEEDLIMIT DIAL )
			Position ( 276 274 60 60 )
			Graphic ( "..//..//common.cab//cab814//M3.ace" )
			Style ( NEEDLE )
			ScaleRange ( 0 110 )
			ScalePos ( 240 135 )
			Units ( KM_PER_HOUR )
			Pivot ( 30 )
			DirIncrease ( 0 )
		)

In the meantime I made more precise tests about the different function of EmergencyStopMonitor, VigilanceMonitor and OverspeedMonitor.
The VigilanceMonitor block defined in the .eng file performs both the standard vigilance function (that requires that you regularly press the acknowledge key) and the next signal speed check (in the sense that the alerter is triggered if the next signal speed is lower than the actual signal speed ). The presence of EmergencyStopMonitor and OverspeedMonitor does not seem to have any influence on these functions. The OverspeedMonitor block (even if standalone) maintains its promises, that is it performs the actual speed check function, with vigilance triggering in case of overspeed and emergency stop (if enabled) in case of no acknowledge.
I couldn't find the function of the EmergencyStopMonitor.

I draw also your attention to what George, the great developer of MSTSbin, found out about the hidden, but working parameters of VigilanceMonitor.
Here
http://mstsbin.uktra...om/eng/eng.html
selecting page "Tips-Cheats" you find a list of 26 (!) parameters that MSTS recognizes for the VigilanceMonitor block. There are quite interesting things, as e.g. the possibility of triggering alerters in case of OverRPM, or OverCurrent, or LowMainResPressure.

[gpz]

Pedro, could you please test your speed limit displays with r1830, if they work correctly now?

[PA1930]

Just tested with X1830! Currently on ORTS the system works semi-fine like in MSTS! Great work, thanks! :)

Now here go some screenshots with my notes regarding after the new change on ORTS:
1st screen we can see that it works good, but the next speed limit indicator is showing the signal maximum speed only and not the next speed limit. Though this is exacly what happens on MSTS.

http://i40.tinypic.com/huhtn9.png

2nd screen I've set the juction to the diverge route so the next speed display now shows the correct speed limitation as it is being limited by the signal.

http://i42.tinypic.com/14bryj5.png

3rd screen I've set the other pair of junctions so I could get the 30km/h speed limitation by the signal and it works as it should. :(

http://i39.tinypic.com/118q6pk.png

4th screen I've set the junction back to the normal track so it now shows me that the next speed limit is 120km/h as it was in MSTS. [Because its the same as before, it shows the maximum speed that the next signal allows the train to pass... but only shows 120 because that's what's set in the "ScaleRange" on the cab "coding".

http://i39.tinypic.com/2ugh4bp.png

5th screen shows that I'm on the new speed limit but strangely shows me that the max speed is 130km/h while the actual max speed is 120km/h as seen on the Trackmonitor on the right so I don't know why is that...

http://i41.tinypic.com/16j289y.png

Conclusion now:
The system works exacly like MSTS, though it has this minor problem seen on the 5th screenshot.
To achieve the exact way that CNV (Convel/EBICAB700) works there should "extra implementations" either on the ORTS code or on the cab code (but yet that would be necessary to change something on the ORTS code anyways...).
Knowing that for now the developers are sticking into not goin much off of the MSTS "limits", I guess this system isn't able to make it work better than what it does. I would like to see it working properly but if that means a to-do later task, then count me in to help develop it later. :)

[gpz]

The minor error of the data on the last screenshot can be corrected, but you are right, we cannot diverge from default MSTS behavior right now. I think the whole stuff should be moved to TrainControlSystem class, making possible in the future to override its functionality by individual controls like EBICAB. In this way the braking actions based on signal aspects could also be fine tuned for individual control systems. (I have also problems with Hungarian EVM, its functionality cannot be fully programmed by using default MSTS stuff too.) But for this to work an additional .eng file parameter would be needed to indicate the available onboard control systems, and also a user command to switch between them, as it often happens in our area, since many locomotives have multiple of them installed to be able to serve in different countries.

[Csantucci]

Nice work Peter! To be rigorous also the SPEEDLIMIT indicator should refer only to signal speeds, see my above post referring to the MSTSbin manual.
Referring to the possibility of overriding MSTS functionality, you know that now the ORTS steering developers and Chris in particular have provided a framework for this, by foreseeing the insertion of strings of type ORTSxxxx in the case MSTS tolerates that (which is often true, as Chris' tests demonstrate).
Of course one way is to provide within the .eng file data that describe which train control systems are managed by the engine, as you mention.
For display options there is in my opinion also a further solution. I added Chris' "cuckoo" lines to the SPEEDLIM_DISPLAY digital indicator within the .cvf file of Pedro's engine without any grumbling by MSTS at runtime:

Digital (
			Type ( SPEEDLIM_DISPLAY DIGITAL )
			Position ( 236 287 24 12 )
			ScaleRange ( 0 120 )
			Accuracy ( 0 )
			AccuracySwitch ( 0 )
			LeadingZeros ( 0 )
			Justification ( 3 )
			PositiveColour ( 0
				ControlColour ( 255 200 0 )
			)
			NegativeColour ( 0 )
			DecreaseColour ( 0 )
			Units ( KM_PER_HOUR )
			ORTSa ( 1 )
			ORTSb ( 1 2 )
			ORTSc ( 1 2 3 )
			ORTSd ( 1.2mph )
			ORTSe ( 1.2 2.3mph )
			ORTSf( 1.2 2.3 3.4mph )
			ORTSg ( "text with spaces" )
			ORTSh ( text )
			ORTSi ( text text )
			ORTSj ( text text text )
		)

So one of these ORTS parameters could be used to define if a signal-related speed is shown or a signal+track-related speed is shown (which I think is interesting also for other train control systems and not only for EBICAB). Also further refinements through additional parameters could be possible this way. What do you think about?

As you are currently involved in train control systems and cabview controls, I draw also your attention to this
http://www.trainsim....hlight=MSTS+AWS ,
which I discovered yesterday. As it says, inserting on top of the various cabview controls this RESET_TWO_STATE statement, the use of that control has also the function to restart from 0 the alerter count.

[roeter]

Hello,

very much like the idea of a separate class to be set up for these information systems.
To define the information in a special 'block' in the *.eng file is a good option. Extentions to the *.eng file can be made without losing the compatibility with MSTS, as has been shown in the work on steam engines.
A major problem here is, however, that the definitions for these systems span across multiple 'disciplines' : they need to be linked to cabview items and sound definitions - especially when an engine has multiple systems.

For transponder-based systems (e.g. Indusi, AWS) there is the very complex point of how to define the transponder locations (and the link to the related signal) - that must be items in the *.tdb in order for the train to be triggered at the correct position, but there is not much choice there as compatibility with MSTS is an absolute must, we still depend on the MSTS route editor. MSTS obviously has no 'transponder' items, and there is nothing which could be easily 'converted' to that purpose either.
I see no easy way forward there at the moment, so I think we should, for now, concentrate on continouos systems.

One more question : how 'intelligent' are these systems?
If, for instance, there is a fixed speed-restriction (speedpost) to 60kph, followed closely by a signal with a speed reduction set to 30kph.
Would the system indicate the 60kph until that speedpost is passed, then changing to 30kph (at too short a distance to be usefull), or would the system realise the next speedlimit is more severe and indicate the 30kph, ingoring the 60kph speedpost?

Regards,

Rob Roeterdink

[Csantucci]

Hi Rob,
why shouldn't it be possible to use exisiting MSTS speedpost and signal items also as transponder/balise/beacon emulators? In reality very often such beacons are in the immediate vicinity of speedposts and signals. And if other ones have to be added where no speedpost and signal is foreseen, one could think to ad-hoc objects of type MSTS signal (or speedpost) to emulate beacon/balise behaviour.