[roeter]

When the new signalling was created, it was decided to enforce an automatic speed restriction for AI trains when approaching a signal with aspect RESTRICTED or STOP_AND_PROCEED. As the names of these aspects imply, trains should not pass signals showing such aspects at normal full speed. At the time, doing this by default was the only option.

However, things have changed, and for some time now new OR-specific 'Approach Control' signalling functions are available, which can enforce such behaviour by keeping the signal at danger until the train is close to the signal or has reduced its speed sufficiently.

That leads to the question what to do now with the automatic restrictions.
In my view, there are a number of options.

• Keep things as they are.
  There have been very few remarks on this behaviour, in general it seems to have been accepted.
  
• Make it a user option.
  Would not be difficult, but I fear many users will nor really know what the effect would be.
  
• Make it a route-specific option.
  Such an option would have to wait until we have OR-specific route definition files.
  
• Remove the option and for those signal systems where it is required, the signal scripts must be adapted to use the 'Approach Control' functions.

I'd like to know your opinion on this, please.

Regards,
Rob Roeterdink

[Csantucci]

I would like this as an option by the moment. This way it is as the option "No forced red at station stops". The two options cover what is usually a country-specific way of operating, and so it is good to have them user-selectable. (By the way in my country there is neither reduced speed approach to signal nor forced red).
Transforming these options to route-specific options may be done in a second moment, when OR-specific route definition files are there.
If the user-selectable option is not accepted, I prefer that this behavior is cancelled (also for compatibility with MSTS).

[copperpen]

Option 4 for a lot of users would be a no go. The first option would be my choice as it maintains the status quo for legacy MSTS routes.

[RustyXL]

My choice would be option 2. As I've mentioned in another thread the AI trains in one of my routes slow down unnecessarily because of stop and proceed signals. If I could disable the automatic speed restriction for those signal aspects the AI trains would finally run properly. I tried changing the sigcfg and the sigscr of the route but either the problem was only made less severe or the game crashed in explore mode.

[vince]

My choice would have the AI follow the same signal rules as the player.
As I recall there was always a speed restriction for AI in MSTS but the problem was it was 'stuck' at a Restricted speed forever.
Plus it would then proceed at Restricted speed into any train in the block.

I'll look to be keeping option 1 or 2

best,
vince

[mauried]

Id simply leave it as is.
Whilst I would use a user defined mode , option 2 , I suspect that most people who play with the Sim
dont care all that much about how AI trains run, and adding more complexity will simply result in more questions being asked
on the Forum.
Ideally , AI trains should run the same way the player trains do, or as close as practically possible.

[markus_GE]

Personally, I´d say, make it an option. Those who want it can switch it on, those who don´t can leave it off. The default for the setting, IMHO, should be on, because that would leave things as they are, and work around too many questions being asked.

Cheers, Markus

[jtallen]

Ideally the AI trains should be following the same signal rules as the user controlled train or trains. I'll have to vote for option 2 until the route editor is out, then it would be option 3.

[roeter]

Well, the opinions on this are obviously divided.
What is clear, and even though it has been suggested several times, that this should not be a user option. User options are something that relates to user preferences - like viewing distance, shades etc.
Whether or not train speed should be reduced has nothing to do with user preference but with signal definitions.

So, I have opted to make this a signal option. A new flag, "OR_NoSpeedReduction" can be set for required aspects in the signal type definition in the sigscf.dat file (OR-version, obviously), as shown below :

		SignalAspects ( 7
			SignalAspect ( STOP			    	"Red" )
			SignalAspect ( STOP_AND_PROCEED			"LowYellowFlash"	SpeedMPH(25) signalflags (OR_NOSPEEDREDUCTION) )
			SignalAspect ( RESTRICTING			"LowYellow"		SpeedMPH(25) signalflags (OR_NOSPEEDREDUCTION) )
			SignalAspect ( APPROACH_2			"TopYellowMidGreen" )
			SignalAspect ( APPROACH_3			"TopYellow" )
			SignalAspect ( CLEAR_1				"MidGreen" )
			SignalAspect ( CLEAR_2				"TopGreen" )
		)

Default is that speed will be reduced. If this flag is set, the speed reduction is suppressed.

Setting this option as signal aspect option has a the advantage that it can be set per signal and per aspect as required.
The changes have been committed in version 2675.

Regards,
Rob Roeterdink

[Genma Saotome]

roeter, on 02 December 2014 - 03:44 AM, said:

Well, the opinions on this are obviously divided.

Regards,
Rob Roeterdink

Sometimes the correct answer is two functions, one for each purpose: there is a great tendency for people to argue over something w/o ever realizing they're arguing about two different understandings that use a single, common identifying label.

Anyway, I dunno if two are feasible in this case but the habit of considering two is something that should always be in one's toolbox.

[gpz]

Rob, I think you made the right decision. Users would not know what to select indeed, unless a table had been provided with recommended setting for each country / railway company.

Let me ask for clarification: Is the original (now the default) behavior meant that the train would slow down as soon as it "sees" a restricting signal ahead at its block end, or is the speed restriction applied after passing the signal?

[Csantucci]

The solution of leaving it to the sigcfg file is OK, although I would have done it the opposite way, so that the default is what MSTS does. Anyhow modifying the file is not complicated.

[roeter]

The speed restriction is applied just before the signal - the train will approach the signal at normal speed, then almost stops in front of the signal (speed down to about 5 mph), and will then resume normal speed again - any speed restrictions linked with the aspect will, ofcourse, be applied after the train has passed the signal.

Both aspects (STOP_AND_PROCEED and RESTRICTING) are generally used either to allow the train into a section already occupied, or into a siding with restricted speed. This behaviour ensures the train will have slowed down enough to safely enter the occupied section or the restricted siding.
It was intended as a substitute for an 'approach control' signal - such signals (particularly used in Britain) are kept at danger until the approaching train has reduced speed sufficiently. MSTS does not support approach control functionality, and neither did OR when the signalling was reworked.
Looking through the various manuals, it is also the expected behaviour for many USA railways if a train approaches a 'permissive' signal which is at danger (the original STOP_AND_PROCEED indication).

Approach control functions have been introduced some time ago, so more proper signal behaviour can now be defined, and there is no longer any need for this default behaviour. To keep things as they were, the default is unchanged, but can it can now be switched off.

Regards,
Rob Roeterdink

[Csantucci]

Hi Rob,
in the country forum I follow a person got a crash with the following log:
 Nuovo WinRAR ZIP archive.zip (3.04K)
Number of downloads: 248
Can you pls. have a look? It seems connected with the new "No speed reduction" function.