[Kazareh]

jovet, on 03 September 2016 - 05:19 AM, said:

Refactoring code takes a lot of concentration and sometimes some planning. Starting with this and trying to make it neater and more flexible/sensible isn't always easy and straightforward.

Exactly. And thigns go awry in the process, so fixing the awry-ness is just, part of the ever-going process.

[Serana]

I reviewed the code I have rewritten.

Well, first, the TCS Script Disable checkbox still has the same behaviour : if a script (such as the TCS France script) is defined in the ENG file, it will ignore it and load the MSTSTrainControlSystem class. The default train control system is not a script.

The only difference of functionality in the MSTSTrainControlSystem code I found was this one : the Alerter checkbox was disabling the speed control... which is not at all logical and that's why it seems I didn't put it in the speed control conditions of the rewritten code.

Perhaps a Speed Control checkbox could be added.

[Kazareh]

I want to bring up something I found out about this bug which has broken the PRR Eastern Region. I run a lot of Amtrak service on the PRR ER, not just PRR stuff. Now obviously there is the issue of speed limits, and the route having a 100mph cap, which does not do for even a LD train like the Star, Meteor, Crescent, etc etc. Those travel at 110. If I attempt even that, it brings the train into TCS Emergency Braking until it gets back to 100MPH.

Acela's are out of the question.

[vince]

Kazareh, on 22 September 2016 - 07:47 AM, said:

I want to bring up something I found out about this bug which has broken the PRR Eastern Region. I run a lot of Amtrak service on the PRR ER, not just PRR stuff. Now obviously there is the issue of speed limits, and the route having a 100mph cap, which does not do for even a LD train like the Star, Meteor, Crescent, etc etc. Those travel at 110. If I attempt even that, it brings the train into TCS Emergency Braking until it gets back to 100MPH. Acela's are out of the question.

The route sets the speed limit, not Open Rails. I believe that at the time the route is modeled 100 mph was indeed the actual speed limit.
As the route is set in the 1950's the Acela is for sure out of the question.
You will have to mod the route to make it fit the equipment you want to use. Signals are a problem (for rivet counters) though, no color position lights on the Corridor.

regards,
vince

[Kazareh]

vince, on 22 September 2016 - 04:37 PM, said:

The route sets the speed limit, not Open Rails. I believe that at the time the route is modeled 100 mph was indeed the actual speed limit.
As the route is set in the 1950's the Acela is for sure out of the question.
You will have to mod the route to make it fit the equipment you want to use. Signals are a problem (for rivet counters) though, no color position lights on the Corridor.

regards,
vince

Yes, however, the route speed was ignorable for modern day trains, and now with the stuck TCS Speed Enforcement, it will auto-Emergency-Brake the train. This is a problem. As for modding the route, that is a huge task in of itself which is currently impossible due to the Class A, B, C, and D train speeds the NEC utilizes and ORTS only supporting Freight/Passenger speeds. So, removing the 'always on' option of the TCS Emergency Braking/Speed Enforcement is a better solution.

[vince]

Kazareh, on 22 September 2016 - 04:49 PM, said:

Yes, however, the route speed was ignorable for modern day trains, and now with the stuck TCS Speed Enforcement, it will auto-Emergency-Brake the train. This is a problem. As for modding the route, that is a huge task in of itself which is currently impossible due to the Class A, B, C, and D train speeds the NEC utilizes and ORTS only supporting Freight/Passenger speeds. So, removing the 'always on' option of the TCS Emergency Braking/Speed Enforcement is a better solution.

For a more elegant solution simply edit the track file ( *.trk ) for the route using notepad or wordpad.
Presently the SpeedLimit ( 45.0 ) 100mph should be set to SpeedLimit ( 60.3504 ) 235 mph.
The SpeedLimit is expressed in the track file as meters per second.

regards,
vince

[Kazareh]

vince, on 22 September 2016 - 05:36 PM, said:

For a more elegant solution simply edit the track file ( *.trk ) for the route using notepad or wordpad.
Presently the SpeedLimit ( 45.0 ) 100mph should be set to SpeedLimit ( 60.3504 ) 235 mph.
The SpeedLimit is expressed in the track file as meters per second.

regards,
vince

Yeah I'm going to have to do that as a bandaid fix, but the thing is when ORTS breaks osmething, ORTS needs to fix it. I understand in advance before anyone opens their mouth, they're looking at fixing this as it was broken during the code-cleanup.

Just do get a smidge tired of whenever the ORTS Program causes an issue, people's automatic answer tends to be 'fix it yourself'.

[Serana]

Not every troubles can be solved by modifying the code. Sometimes you have to correct the data (ENG files, WAG files, etc.)
Example : when people say "the speed limit of the consist is wrong, it's a bug in the simulator", my response would be "Nope, fix the MaxVelocity variable in the consist file".
If your route says you should run at 100 mph, there is maybe a reason (historical reason, physical reason (curves for example), etc.).
For me, the cleanest solution to your problem is to modify the TRK file.

If I come back to one of your sentences which basically says "it's broken, fix it", I have some remarks to do.
Firstly, I will quote this :

Quote

The only difference of functionality in the MSTSTrainControlSystem code I found was this one : the Alerter checkbox was disabling the speed control... which is not at all logical and that's why it seems I didn't put it in the speed control conditions of the rewritten code.

It's not broken as you say. It has been corrected to what it should be. The alerter is not the speed control, so the checkbox shouldn't disable the speed control.

Secondly, nobody gave an opinion about this :

Quote

Perhaps a Speed Control checkbox could be added.

Nobody confirmed that they wanted this checkbox, so nothing has been done for the moment.
For me, this modification is a workaround, and I consider workarounds to be ugly most of the time, so it's not in my priorities.

Also, please remember that we're not omniscient. I can't guess if you agree with the proposed solution.
So please give an opinion about the proposal.
Thank you ! :)

[Kazareh]

Very well, then my friend. I absolutely would love to see a checkbox to enable/disable speed control, for sure. As how the code introduction brought in undesired performance, that would be a good way to be rid of it for those whom do not wish it, but also retain it for those who do. :)

My appologies, ironically for what I do with Radio work my communication skills are not always up-to-par for sure.

[copperpen]

I do not think that the TCS scripts have broken anything, indeed they have fixed what was broken. If 100 is the top limit for the route, then there should be no stock running above that speed anyway. Vince is right, if you want higher speeds, just adjust the trk file to get what you want or need.

[elvasleis]

vince, on 31 August 2016 - 09:24 AM, said:

As I recall, there is a time delay setting in the engine file between the warning and brake application.
Here is a clip from the Acela of the sections that apply. What follows are not the default settings but my own. As you can see, I just zero'd most everything out but some selective altering may get you what you want.
I think one of the Route_Riter utilities is able alter these parameters globally.

EmergencyStopMonitor(
		MonitoringDeviceMonitorTimeLimit( 0 )
		MonitoringDeviceAlarmTimeLimit( 0 )
		MonitoringDevicePenaltyTimeLimit( 0 )
		MonitoringDeviceCriticalLevel( 0 )
		MonitoringDeviceResetLevel( 0 )
		MonitoringDeviceAppliesFullBrake( 0 )
		MonitoringDeviceAppliesEmergencyBrake( 0 )
		MonitoringDeviceAppliesCutsPower( 1 )
		MonitoringDeviceAppliesShutsDownEngine( 0 )
		)

	VigilanceMonitor(
		MonitoringDeviceMonitorTimeLimit( 45 )
		MonitoringDeviceAlarmTimeLimit( 37 )
		MonitoringDevicePenaltyTimeLimit( 0 )
		MonitoringDeviceCriticalLevel( 0 )
		MonitoringDeviceResetLevel( 0 )
		MonitoringDeviceAppliesFullBrake( 0 )
		MonitoringDeviceAppliesEmergencyBrake( 0 )
		MonitoringDeviceAppliesCutsPower( 0 )
		MonitoringDeviceAppliesShutsDownEngine( 0 )
		)

	OverspeedMonitor(
		MonitoringDeviceMonitorTimeLimit( 0 )
		MonitoringDeviceAlarmTimeLimit( 5 )
		MonitoringDevicePenaltyTimeLimit( 0 )
		MonitoringDeviceCriticalLevel( 151 )
		MonitoringDeviceResetLevel( 0 )
		MonitoringDeviceAppliesFullBrake( 0 )
		MonitoringDeviceAppliesEmergencyBrake( 0 )
		MonitoringDeviceAppliesCutsPower( 0 )
		MonitoringDeviceAppliesShutsDownEngine( 0 )
		MonitoringDeviceTriggerOnTrackOverspeed( 0 )
		MonitoringDeviceTriggerOnTrackOverspeedMargin( 2 )
		MonitoringDeviceResetOnZeroSpeed( 1 ) 
		MonitoringDeviceResetOnResetButton( 0 )
		)

Tweak these puppies and I think you will be pleased with the result. Just one engine at first tho' until you get it right.
regards,vince

I have found so far only a few deisels have the problem and I have just tried the above changes Vince has suggested on the Jet train and this does the trick.
Thanks Vince.