[roeter]

Presently, signals at stations where a train is to stops are kept at danger until 2 mins. before departure, or until the train stops if it arrives within those two minutes. This rule is a 'blanket' rule and is applied to all signals which protect a junction (i.e. there is a node in the track between this and the next signal).
This 'hold state' is very important in some situations, in particular when trains have long stops in order to allow other trains to overtake. If the 'hold state' did not exist, the signal would clear immediately as the train approached thus blocking the path of the train which is to overtake.
However, it is applied to all situations and is not very popular with some users.

Recently, I have been looking at alternative ways to define and process this state.
Rather than set it as a 'blanket' process, defined in the program code and applied to all signals at all stations, the processing could be moved to the signal itself through a definition in the signal script.
A signal would then be able to test the 'station hold' state, and set the signal at danger if that is what is required.
The advantage would be that the use of holding state can be defined per route and per location, rather than as a general overall rule.
The disadvantage would be that if it is to be set for certain signals and locations, it requires a change to the sigscr.dat file to set this behaviour.

As a side-effect, the new function would be incompatible with MSTS. To overcome this problem it would be required to define specific OR signal definitions files. That is done quite easily, though - the present sigcfg.dat file can be copied to sigcfg.dat_or, this file can than be edited to change the referenced sigsrc file.

So how would it work?

If this would be implemented, these are the steps required to set this functionality for a specific signal in a route.

• Copy the route's sigcfg.dat file to sigsfg.dat_or, and the sigscr.dat file to sigscr.dat_or (note that some routes use different sigscr files, sometimes even multiple files).
  
• Edit the new sigcfg.dat_or file to change the reference of the required sigscr file to the new or file.
  
• Identify the type of signal for which this function is required (by means of the route editor and the sigcfg.dat file).
  
• If the signal is to be set to state STOP if it must be held for a station stop, add the following lines to the script for that signal in the new sigscr file for OR :
  

      if (station_hold())
      {
          state = SIGASP_STOP;
      }
  

  
  The function "station_hold" returns 'true' if a 'hold' is active for that signal.

The 'hold' state would now work for all signals which have this function set, not just those leading to junctions. This can have advantages in situations where there are two signals leading up to the next junction instead of one.
An experimental test with heavy AI traffic has shown that this new method actually works better than the present function.

Any thoughts on this, please?

Regards,
Rob Roeterdink

[A Tejesember]

I would love to see customisable or even randomised hold time. What I mean is that here they still use manual main signals, so before a train can leave (or enter) a station, the dispatcher has to set up and lock the path, close the road crossings if there is any, then clear the signal for the train. This can happen just before scheduled departure, few minutes before or even late. It really just depends on the person in charge. It would be pretty neat to set a minimum and maximum time when the path locking and signal clearing should happen, and OR would choose a random number between the two, and do its job then. I would allow negative numbers for minimum, so being late could also be the "fault of the dispatcher". This brings up another thing, when the train is hold up because of another. When the path is cleared, it is immediately set up for the other train. I think this could be delayed somehow just as the things above. It would really add to the experience on routes with manual systems in my opinion.
Also, there could be a switch, to wait until the train stopped, or can clear in advance based on timetable.

[markus_GE]

Partial to it.

On the one hand, it might mean operational improvements.

On the other hand, I´m not very keen on learning the SigScr language to update all of my routes. I would probably also have to learn route editor for it, for which I really don´t have the time and motivation at the time (graduation in a few weeks). Yet I would still like my activities to work the way I set them up, that is with the old processing...

Just my thoughts, though.

Cheers, Markus

[Buttercup]

Would it be possible to identify an individual signal or signals by its or their location and have the rule apply to it or them only?

The only problem I've noticed with the current system is when there the approach signal is a long ways from the station a speed restriction is sometimes set a long ways from the station which is unrealistic,

[Csantucci]

I'm not sure if I'm partially saying the same thing as Rob , but the way a signal must work referring to the hold function depends not only from route layout and signalling rules on a specific route, but especially from activity, train timetable, train priorities, and in general the function could be usable for almost any signal. So, a signal could require a hold in certain situations and could not require a hold for other ones. So my proposal is that this should not rely on signal files, but on info coming from enhanced (ORTS) activity files (like train timetable, train stops, train priorities) and from the actual traffic state (is there a priority problem in that moment)? I'm not sure if such info should be explicit (saying that a specific signal must be closed up to a certain event) or implicit (behaviour of signal is derived from the above mentioned info). Moreover it should always be possible for the dispatcher to force a signal close or clear to override game-defined priorities.
So I'm rather reluctant, as Markus is, to foresee changes to MSTS signal files and even to route layout for this function. At level of route maybe only a general parameter could be provided, indicating if signal hold is always required or not for trains stopping at a station (in Italy it is not since some year).

[gpz]

It isn't required in my country too. Moreover real-life dispatchers if possible, try to receive the train to stations with clear outlet signals, because otherwise the trains cannot "target-brake" near to platforms, since the train control system in use require prior speed reduction in case the train is approaching a red signal. So in the latter case the trains usually need double braking, and can approach the platform only by about 30-35 km/h.

[jtr1962]

This has been causing issues on many routes because a hold signal at a station also drops the following signals to approach. This could mean you might get an approach signal two miles from a station. End result you're stuck crawling at, say, 30 mph for those two miles instead of proceeding at track speed. Needless to say, this plays havoc with schedules, especially on commuter lines with stops every few miles.

I might suggest a slight change to correct the problem but still allow holding trains at stations if they're being overtaken by other trains. Keep the signals in their normal state (i.e. you only get approach or stop aspects according to the signal script and whether the blocks ahead are occupied) until the train stops at the station, or at least is very near the platform (say within 1/4 mile of where it's supposed to stop). At that time, set the signal aspect at the end of the platform to stop until the schedule dictates that the train can leave. This will allow approaching the stations at track speed but also keep trains at stations until following trains can overtake them.

[gpz]

 jtr1962, on 04 March 2014 - 01:47 AM, said:

Keep the signals in their normal state (...) until the train stops at the station (...). At that time, set the signal aspect at the end of the platform to stop until the schedule dictates that the train can leave.

This small piece of your post is against how real-life railways work. When a path has already been set, and the signal is cleared, it is not allowed to reset this path and signal by the dispatcher, until the train had travelled along it. (Only the train is allowed to reset the signals behind itself.)

[roeter]

 gpz, on 04 March 2014 - 04:51 AM, said:

This small piece of your post is against how real-life railways work. When a path has already been set, and the signal is cleared, it is not allowed to reset this path and signal by the dispatcher, until the train had travelled along it. (Only the train is allowed to reset the signals behind itself.)

Quit true. Only in very special situations (failures, emergencies) may a signal be reset. This must then be clearly communicated to the driver, and the signalman must be able to prove the action was justified. When the signal is reset, the path which was cleared remains locked for 2 to 5 minutes for safety reasons - provided the train did not pass the signal. If the train passes the signal after it had been reset, the path remains locked until the train has cleared the section, and very often an investigation will take place why the signal was reset and why the train was not stopped in time - and the line usually remains blocked during this time. Quit likely both signalman and driver will be releived from their tasks and replacement staff brought in.
(Exceptions, ofcourse, were local signalboxes with semaphore signals and no track circuits - if driver and signalman agreed nothing was wrong and there was no inspector around, nothing would be reported :derisive: ).

Regards,
Rob Roeterdink

[jtr1962]

 gpz, on 04 March 2014 - 04:51 AM, said:

This small piece of your post is against how real-life railways work. When a path has already been set, and the signal is cleared, it is not allowed to reset this path and signal by the dispatcher, until the train had travelled along it. (Only the train is allowed to reset the signals behind itself.)

Yes, I'm totally aware of that but I'm trying to think of a solution here which allows for both holding a train in a station when needed while at the same time allowing it to approach the station at track speed and target brake at platforms. We could also define it at the signal itself as suggested in the first post but my way wouldn't require it.

Anyway, in my opinion until a solution of some kind is figured out perhaps keeping signals in a danger state at station stops should be an option instead of the blanket way signals are treated. As others have said, in many situations the dispatcher attempts to keep the signals clear at station stops to facilitate approaching the platforms at speed.