Elvas Tower: Passing a signal at danger - Elvas Tower

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Passing a signal at danger Warning in logfile Rate Topic: -----

#1 User is offline   eugenR 

  • Conductor
  • Group: Status: Contributing Member
  • Posts: 472
  • Joined: 15-April 13
  • Gender:Male
  • Simulator:MSTS
  • Country:

Posted 23 March 2017 - 07:49 AM

If a Player has passed a Signal at danger OR is writing a Warning in the Logfile:
Warning: Train 0 passing signal 78 at 76.7 at danger at 3.64

I was thinking 78 is the Signal-number in the *.tit/*.tdb File, but it isn't!

Can you please ad here the TrItemId ( 5 )
	SignalItem (
		TrItemId ( 5 )
		TrItemSData ( 267.126 00000002 )
		TrItemRData ( -868.672 1 1013.36 -5854 14822 )
		TrSignalType ( 00000000 1 3.14158 ChNHauptsignal_1_Ri )
	)

Often users complain, that they are standing before a signal at danger.
A very simple way to instruct them to deliver more information about the Signal would be:
drive over the Signal and send my the logfile (+the signalfile). With this information it is easy to identify in a first step the Signal and his function.
edit:
perhaps You can also print the reason why the signal is at danger
SNCA, script can signal only open if also the next Signal is open, Track occupied by Train X, Track reserved for TrainX, static train, end of route, ect.

Thank You
EugenR

#2 User is offline   Jovet 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 2,240
  • Joined: 14-January 08
  • Gender:Male
  • Location:Omaha, Nebraska.
  • Simulator:MSTS/Open Rails
  • Country:

Posted 24 March 2017 - 03:52 AM

You can also turn on Track Debugging (Default: CTRL+ALT+F6) and take a screen shot. It should show the appropriate entry numbers.

#3 User is offline   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,419
  • Joined: 25-October 11
  • Gender:Male
  • Country:

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

#4 User is offline   eugenR 

  • Conductor
  • Group: Status: Contributing Member
  • Posts: 472
  • Joined: 15-April 13
  • Gender:Male
  • Simulator:MSTS
  • Country:

Posted 25 March 2017 - 05:18 AM

View PostJovet, on 24 March 2017 - 03:52 AM, said:

You can also turn on Track Debugging (Default: CTRL+ALT+F6) and take a screen shot. It should show the appropriate entry numbers.


View Postroeter, on 25 March 2017 - 04:21 AM, said:

I'm afraid it's not possible to indicate why a signal is at danger.
Regards,
Rob Roeterdink

Thanks for the hint with CTRL+ALT+F6 I doesn't know it.
And for finding the reason of a red signal I can use the Dipatcher-Info F5 and 5x Shift+F5. If the track is free and reserved for the own train and the signal stay at red it must be a problem in the Signal-logic as SignalNumClearAhead.

Thank You
EugenR

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users