[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.