Posted 25 March 2017 - 04:21 AM
Adding the actual TDB-references for each of the signal heads is no great problem, I will include it in the update I'm working on.
By the way, I am also updating most information and warning reports in the logfile such that these will include both train 'number' and train name, which will be more helpfull to identify the train in question, in particular in timetable mode.
I'm afraid it's not possible to indicate why a signal is at danger. That is the result of the what is defined in the script, and the program has no 'direct' knowledge of what is happening when processing the script.
When parsed, the script is 'translated' to a set of abstract definitions, each definition contains details of a single step as defined in the script. Such steps can be, for instance, a function call, or an 'if' statement etc. Function call definitions simply consist of input variable(s), reference to required function and output variable. But as mentioned, these details are abstract definitions, that is the processing itself has no 'knowledge' of what function is processed, or what the output variable is used for.
There is a provision for debug output, which prints out each and every step of the script as processed. But this additional outpus is presently included in the code through a compiler debug switch, and so not readily available to users.
It would be possible to change this into a user-setting option, but that has another serious drawback. The code to generate this output is spread out throughout the script processing. Converting it to a user-option would add quite a number of additional 'if' statements in order to check if the output is required or not. But, in particular on large routes with lots of signals, the signal processing allready is a major contributor to the overall program load. Adding scores of if-statements which, of course, must be processed for each and every head in each update, would definitely add to the load and thus effect the overall performance.
Any thoughts on this are welcome.
Another complication in all this, is that it need not always be the signal script which is holding the signal at danger. It could be the deadlock processing, or, in timetable mode, it could be caused by a train command (e.g. wait, hold).
By the way, some indication as to what is happening can be derived from the dispatcher hud, as this does show track state and deadlock information for the route ahead of the train.
Regards,
Rob Roeterdink