Replies to some of the points raised above.
- Colors.
Separate colors for the various aspects will become available at a later stage.
The intention is to make these into settings, but decisions will have to be made if these settings are user or route related, and also where to store these settings.
- Clearing signals.
I am very surprised by some comments above which claim the present signal control is unrealistic, and then suggest to make it possible to set a signal to the required aspect. Now, that is as unrealistic as you can get it.
I have quite a few signalling simulations (and am actively involved in the development of one such simulation), but there isn't a single system where such a control is possible. A signal is always simply cleared, and the actual aspect (often not even shown to the controller!) is determined by the signal logic.
One exception in some systems is the ability to override some signal logic which will set a special aspect, e.g. to give access to occupied track. That is something that could be implemented at a later stage.
- Signal script.
There are no major outstanding issues regarding the parsing of the sigscr.dat file. However, the support is limited to the general rules as defined in the MSTS documentation. Some sigscr.dat builders have far exceeded these rules by using all kind of C-like statements. Whereas MSTS could (probably) fall back on full singing and dancing C-compilers to parse the script and therefor can process such statements, the script-parser for OR had to be build from scratch and is therefor more limited. Certain C-like constructions well beyond the original definition (like the use of ++, -- etc.) are therefor not supported.
Quite another point here, and I think that is where APK-LVDZ is referring to, is the specific use of aspects, and in particular the use of STOP_AND_PROCEED as main "stop" aspect instead of STOP. That is quite a different issue and has nothing to do with parsing of sigscr.dat file. For various reasons, signal systems which are set up along that line do not work correctly at the moment; it's on the list of things to do but I can only do one thing at the time. To get a single system for both single-player and multi-player signalling is clearly a prime objective before any other changes can be made.
One final remark.
Part of the complexity of the controls is due to the fact that distinction has to be made between 'pathed' and 'unpathed' trains. This is because MP players have indicated they do not want to run pathed trains. Now, in my view, that is unrealistic to start with - drivers don't get to the depot and then start thinking : "what train shall I take today and where shall I take it?".
When they arrive, they are given a train with a destination, route and timetable.
So, all trains should be pathed trains (with timetable), and dispatchers should take control of a limited area (e.g. yard or station) where they control all points and signals, and guide the trains through that area, according to their path and timetable.
As the number of dispatchers is limited, and it's unlikely that all locations can be worked like that, some areas will be controlled by the system - which it can do as all trains are 'pathed' and the system knows where they have to go.
But, that is not how MP players want to run their trains. So the controls had to be adapted to reflect that, and the system now implemented is a compromise. The distinction between 'pathed' and 'unpathed' trains is made to avoid 'unpathed' trains to go where they do not want to go, and yet at the same time limit the load for the dispatcher by letting the 'pathed' trains find their own way.
Regards,
Rob Roeterdink
Log In
Register Now!
Help
Guille592, on 25 December 2013 - 02:44 PM, said:
