[PA1930]

Csantucci, on 24 October 2013 - 12:23 AM, said:

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?

Its not my decision, but if we could get advantange of using those ORTS parameters that don't make MSTS "nuts", then why not using it? :) It would be nice and an "easy" way to make the EBICAB work more propperly.

roeter, on 24 October 2013 - 12:43 AM, said:

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?

Rob, I've shown a video earlier on this topic so I don't know if you have seen it. At least the EBICAB, in real life, it gets info on specific "beacons" in the middle of the tracks [See this picture: http://cpkids.cp.pt/...1986_convel.jpg ] and the system calculates a distant vs speed curve for when to alarm the train driver when to reduce speed.
If you didn't watch, here's a video that I have shown earlier on this topic of the CNV working in a Portuguese unit:
So its not the most appealing system to the eyes, but its almost as great as LZB. :( All in all what is currently missing are the EBICAB related sounds but the system itself works semi-fine as I've shown on the screenshots. Now it could be better if we could get to use those extra parameters. The problem is that there are many different cab signalling systems that we could make so one of my sugestions (and I know that some might not like this so much but its only my sugestion!) is that, in case we/you do coding for different systems, you could implement an extra "check mark" box in the Simulation tab to choose what system to work in the simulation. This would be nice and we could have a set of different systems and only use one or two of them if the player chooses to.

[gpz]

Since the systems differ not just in their speed limit display, but in many other aspects (like the brake responses), I think we really need a more general place of setting the available systems on board, than a suboption of a cabview display control. Since .eng is unique for a locomotive, that might be a good place to store what types are installed on a particular loco. Certainly it is possible to use a list in the main menü to select from, temporarily.

If we want real simulation, I think a modular system like MSTS MonitoringDevices cannot cover all the possible behaviors for all the systems, so I think, they should be modelled individually, without the need of the user setting each suboption. So the user should be able to just select one from the list, there are only a finite number of them to implement in ORTS. And of course the default MonitoringDevices will always be there as fallback.

[PA1930]

gpz, on 24 October 2013 - 02:41 AM, said:

Since the systems differ not just in their speed limit display, but in many other aspects (like the brake responses), I think we really need a more general place of setting the available systems on board, than a suboption of a cabview display control. Since .eng is unique for a locomotive, that might be a good place to store what types are installed on a particular loco. Certainly it is possible to use a list in the main menü to select from, temporarily.

If we want real simulation, I think a modular system like MSTS MonitoringDevices cannot cover all the possible behaviors for all the systems, so I think, they should be modelled individually, without the need of the user setting each suboption. So the user should be able to just select one from the list, there are only a finite number of them to implement in ORTS. And of course the default MonitoringDevices will always be there as fallback.

Well, I actually completely agree with you. ;)

Though another sugestion/request: Is it possible to try to implement a "next speed limit display" that shows the next speed limit from the speed posts as well and not only from the signals that have a limited speed set? If this could be achieved, I believe that at least pretty much of the EBICAB would be working fine... Then some time further we could try to make it work more similar to the real life (like only showing the next speed limit x meters before getting to it instead of showing it always no matter the distance, and also only displaying the next speed limit when the speed is lower than the actual speed limit).

And sorry Carlo, I think the discussion about the signal systems has been a bit off-topic related to the sounds you wanted to make. Though it would be a great adition if what I sugest could work along with sounds as you could see on the video. :)

[gpz]

PA1930, on 24 October 2013 - 04:12 AM, said:

only showing the next speed limit x meters before getting to it instead of showing it always no matter the distance

This is the same problem as with AWS: The exact location where the sound indication should clang is determined by a balise, which should be part of the route, but it isn't. A similar behavior could be imitated by using a constant distance before each signal for "activation". I don't know if this would work correctly, there is a chance... But a question to Rob is: Is the actual distance to the next signal available somewhere in the database?

[roeter]

Well, I hate to damped your enthousiasm, but there is no intention to implement any monitoring system in ORTS.
What should - and hopefully will - be implemented is something along similar lines as the signalling itself : a basic structure which can handle a set of instructions (parameters or scripts or whatever) which define the required functionality.
As with the signalling itself, there are just too many differences and variations. It also has to be taken into account that these differences and variations not only occur based on locations, but also on time : the first monitoring systems started to appear about 80 years ago and the way these operated definitely changed over the years, so the system to be implemented also depends on the era in which the route is set.

What needs to be decided is how to define such a set of information. It could be a 'block' in the *.eng file, but that would require that this info is added to each applicable engine. Another option would be a complete new definition file, which can then be referenced from the *.eng file in much the same way as the cabview or sound files. That would definitely be my prefered option.
It will need a fair bit of work to exactly work out what would need to be defined and how.

So what can be done at short notice?
Apparantly, the present cabview display works reasonably well, based on the definitions in the *.cvf file. Clearly, this will only allow a single system to be implemented. Some additional features may be added, provided these are compatible with the processing of the *.cvf file in MSTS. Perhaps a link can be made to a sound (or sound trigger), so as to play the proper sound when the displayed info changes. A link with the AWSMonitor control could perhaps also be provided direct from the *.cvf.
It has been shown that additional definitions can be included in the *.eng file without compatibility problems, perhaps the same goes for definitions in the *.cvf file. It would, for the time being, make for a reasonable system without too much impact in areas of code which should not have anything to do with this, like the signal processing itself.

Regards,

Rob Roeterdink

[PA1930]

Well the idea was just to show the speed limits and make sounds work with it, not really the accuracy about how it works in real life (making disntace vs speed calculations for a speed curve). I believe its possible to know the distances for the next signals and new next speed limit (its at least shown in the track monitor). First thing I would only "try to do" [if possible, of course] is how I mentioned, that the "next speed limit" would be also shown on the yellow display but not only for the signal speed limits as it works currently.

Then what I was mentioning about the it could show only a value within x meters before the signal, I din't want to sound for it to be something mandatory, but knowing that one can know the distance for the next signal or speed limit post, couldn't it be possible to make something either on the *.eng file or on the *.cvf file to only display the new speed if the speed is lower than the actual speed... [This sounds an imposssible script to "write" on the *.eng or *.cvf file isn't it? I don't know to be honest... I don't know if one could make "if" conditions on these files].

[roeter]

Csantucci, on 24 October 2013 - 01:02 AM, said:

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.

First of all, such beacons are very often obviously not in the vicinity of signals or speedposts, as the warning has to be an advance warning - therefor the transponder or beacon or whatever is a certain distance ahead of the location for which it gives a warning - this distance will vary according to linespeed and, sometimes, visibility of the object itself.

As for using signals or speedposts as marker for such locations, here are a few firm objections and complications.

Using signals.

• There is only a limited set of signal types available. "NORMAL" signals obviously can not be used for this, other types often have some function or other within the signal system. To add such signals at arbitrary positions can clearly create serious problems regarding the working of other signals in that area, depending on the defined logic.
  
• It would be possible to create new types of signals to avoid the problem as mentioned above for ORTS. But even so, compatibility with MSTS would be lost. However, such new signal types cannot be included in the sigcfg.dat type as MSTS would not accept such definitions. So, a separate sigcfg file for ORTS would be required. But that is completely unchartered terrain. Other discussions regarding completely new files have led to the general accepted statement that the format for these files should be JSON. But not only would that require a completely new definition for a sigcfg-style file, it would also require a translation from the present files to this new format. Furthermore, there is as yet no base structure to process JSON files.
  
• "NORMAL" signals are processed in a very special way - these are the basic objects which define the TrackCircuit structure. Other signal types are ignored by train control as these have no relevance for the actual control. This means complete new logic would have to be introduced to link train control to these special signals. Which, ofcourse, brings the added compexity of how these signals can be identified - see items above.

In all, the signalling is difficult and complex enough as it is without starting to abuse signals for completely different purposes.

Speed limits.
The functionality of a speedpost/milepost is defined in a set of bitmasks. Clearly, additional functionality like transponder can not be defined in the MSTS route editor as this would not be a valid bitmask for MSTS. It could, perhaps, be set manually in world-files (not a mean task), but the question then remains how MSTS would react to such an invalid bitmask.
So, speedpost/milepost can not be defined as transponder without a great risk to MSTS compatibility.
So, I see no way in which speedpost/milepost objects can be used for this purpose either.

For now, the best option is to test if the *.cvf could handle sound-related definitions, as I have suggested above.
A possible alternative would be soundmarkers, which would have a sound definition related to the next signal aspect.

Regards,

Rob Roeterdink

[roeter]

gpz, on 24 October 2013 - 04:56 AM, said:

But a question to Rob is: Is the actual distance to the next signal available somewhere in the database?

That info is directly available : Train.distanceToSignal.

Regards,

Rob Roeterdink

[Csantucci]

I see that Rob too speaks about "short notice". That's my concern.
In my opinion (and this is also the general ORTS development policy at the moment) first thing to be done is to achieve implementation of the MSTS "monitoring" functions still missing in ORTS, as Peter has well done with the speed displays. I have already mentioned the RESET_TWO_STATE keyword in .cvf files as something still missing in ORTS. As I'm not a professional programmer, I will try to well define what is still missing in ORTS with respect to MSTS, hoping that someone then will implement that ;)
What should come after that? I see that Rob is against coding of the various monitoring systems (if I understand well his words). I too am perplex about this solution, as it gives only in the hands of the programmers the possibility of having a specific working monitoring system, and if there is no programmer interested, let's say, in the Italian monitoring system, that as all monitoring systems has its own strange things, there will never be such monitoring system implemented. So Rob's suggestion about a parameter or scripting structure (maybe with the possibility of hooking also code chunks) is a better, medium term solution.
In the short term I still think that providing some simple, parameter definable, extensions to the available MSTS monitoring functions can add quite much in terms of similarity to real world. I have the impression that MSTS is not soo far away from that, if one does not want to be perfectly adhering to real world.
Rob mentions the possibility to add further parameters in the .cvf files without damaging MSTS operation: I have tested that this is possible, see my post of 10:23 of this morning.

Pedro, don't be sorry about the fact that we are out of scope because we don't talk about sounds. Sound implementation must be coherent with the overall philosophy of train control, so I prefer to intervene only when the fog about what is and will be done becomes a bit thinner. Sound will be, as we say in Italian, "la ciliegina sulla torta" (the small cherry on the cake)!

Edit: while I was writing this post there were three further new posts, so sorry it does not consider them...

[roeter]

gpz, on 24 October 2013 - 04:56 AM, said:

But a question to Rob is: Is the actual distance to the next signal available somewhere in the database?

And some further info : the list Train.SignalObjectItems has the details of all signal/speedlimit objects within the present cleared train's path.
The list are class ObjectItemInfo items, which is defined in Signals.cs, and has (among other things) type of object, aspect (if signal) and distance to train as well as from the previous object (obviously this latter item not for the first one in the list).

Regards,

Rob Roeterdink