Long Train Operation

[geepster775]

Mixed feelings on any on/off switch.

Objective here should be to rattle our minds and search our inventories and start looking for cars that have a unique design requirements that might offer trouble. And discuss that content and/or solutions.

It is totally insufficient to simply state "my stuff is derailing" without giving us accurate descriptions of specific content involved. The addition of any on/off switch just kicks the 'day of reckoning' can down the road.

The suggestions offered here for Rowie's long runners worked. Having tested them, I also found no troubles with the SLI 8-axle QTTX heavy duty flats that were broken into 3 parts for MSTS max axle count reasons.

[geepster775]

That feature is way off. I get derailed cars when I use the minimum of Dynamic Brake. I am glad I didn't have this problem when I was running. Brian

When you were running, the cars on your drawbar did not have many generations of sub-par, limp-wristed MSTS freeware physics passed around by 'fake CEOs' for an eternity on some forum somewhere. Heaven forbid something new gets programmed in that demonstrates just how comically failed that era was.

[slipperman]

Hi geepster775,
While I respect that you have your own views, I cannot understand your attitude! Without MSTS there wouldn't be any such thing as Open Rails, because there'd be no ready-made potential user-base or the vast array of routes and stock.

It may be taking many of us some time to fully embrace OR but its developers should beware that the current trend to make it "more realistic" also increases its complexity, running the risk of 'frightening' some users off. The way to get more users on-board is to make the transition from MSTS as 'seamfree' as possible and, in that respect, quite a good job has been done. Most of us don't want to have to do all the mundane jobs an engine driver/engineer has to do, but just drive a passenger train from A to B, stopping at intermediate stations and attempting to keep to the timetable, or a freight train, probably performing occasional shunting, but everything in reasonable accuracy.
As you might guess, I'd support an on/off switch!!

Cheers,
Ged

[R. Steele]

Mixed feelings on any on/off switch.

Objective here should be to rattle our minds and search our inventories and start looking for cars that have a unique design requirements that might offer trouble. And discuss that content and/or solutions.

It is totally insufficient to simply state "my stuff is derailing" without giving us accurate descriptions of specific content involved. The addition of any on/off switch just kicks the 'day of reckoning' can down the road.

The suggestions offered here for Rowie's long runners worked. Having tested them, I also found no troubles with the SLI 8-axle QTTX heavy duty flats that were broken into 3 parts for MSTS max axle count reasons.

I can appreciate your position ... as I also like to delve into new OR features and add them to my trainset...but this does take time and effort, sometimes users just want to run some trains...therefore I'm also very much in agreement with slipperman.

My test is...what harm? What harm is it for you, geepster, to have an on-off switch...you can keep it on. However, for someone new to OR, or for the users who wish to simply run trains...what harm to them? With no on/off switch their choices are limited, therefore the simulator is inaccessible to a group of users.

There should always be a path to simple physics for users to follow, until they gain the experience, knowledge or decide to choose the path of advanced operations ( and physics )...which realistically speaking will never be identical with real world ops.

[magmateus]

Hi geepster775,
While I respect that you have your own views, I cannot understand your attitude! Without MSTS there wouldn't be any such thing as Open Rails, because there'd be no ready-made potential user-base or the vast array of routes and stock.

It may be taking many of us some time to fully embrace OR but its developers should beware that the current trend to make it "more realistic" also increases its complexity, running the risk of 'frightening' some users off. The way to get more users on-board is to make the transition from MSTS as 'seamfree' as possible and, in that respect, quite a good job has been done. Most of us don't want to have to do all the mundane jobs an engine driver/engineer has to do, but just drive a passenger train from A to B, stopping at intermediate stations and attempting to keep to the timetable, or a freight train, probably performing occasional shunting, but everything in reasonable accuracy.
As you might guess, I'd support an on/off switch!!

Cheers,
Ged

I completely agree!
Mateus

[geepster775]

There is an entire thread running over on Elvas about the thinning out of some checkbox items under the OR options and experimental tabs. It delves deeper into the line of thinking in how we can create a product that suits both the 'simulation diehards' and the 'autopilot users' while making things less confusing overall with fewer checkboxes. It is not my intention to drag that here, but rest assured among those who worry, some version of 'simple controls' is being looked at. As I see it, as of now Peter is just providing the notifications of derailment; the consequences of derailment should be a different level of engagement altogether.

Different countries have different signalling requirements and different frequency and tonnage expectations, so some accommodations on the user option checkbox, country, route, or activity level will always need to be made. Mullan pass is not an Amtrak route so it does not need PTC so it does not require the nanny oversight of train control subsystems in the code like European countries that operate bullet trains do. Escaping derailment notification is not in the same class of compelling need.

[motormaster532]

When you were running, the cars on your drawbar did not have many generations of sub-par, limp-wristed MSTS freeware physics passed around by 'fake CEOs' for an eternity on some forum somewhere. Heaven forbid something new gets programmed in that demonstrates just how comically failed that era was.

Hi geepster. Running Mullan Pass "Z Train Reroute" as we speak,so to speak! At 20 MPH pulling the grade at Austin I was getting messages that car after car was derailing and then miracle of miracles-rerailing! Then the process would start again! It is really not a big deal as I dont find it that much an irritant because since it does not impact what I am doing I just ignore it. But it is a glitch in my opinion. Have a good one! Brian

[dcarleton]

Same issue happening here.

Okay. If the makeup of a train's consist causes it to derail while going uphill and around curves, then be that as it may. But WE didn't create those consists, the vendor did! So then, what the development team has actually succeeded in doing is that they have introduced a feature that devalues the vendor's product....

[motormaster532]

Same issue happening here.

Okay. If the makeup of a train's consist causes it to derail while going uphill and around curves, then be that as it may. But WE didn't create those consists, the vendor did! So then, what the development team has actually succeeded in doing is that they have introduced a feature that devalues the vendor's product....

It really takes VERY,VERY poor train handling to derail a train like that even if it is put together wrong. It is common to assemble freights' in "Block" order,which means drop-offs are combined in one area of the train,empties and loads. There are exceptions of course. Running a train is overwhelmingly by "feel". We cannot feel the train in Simulation,which goes a long way to detracting from realistic performance. This ids why I dont' get worked up if something is not perfectly "Realistic" in the Simulator. It can never be. Brian

[PerryPlatypus]

Hi geepster. Running Mullan Pass "Z Train Reroute" as we speak,so to speak! At 20 MPH pulling the grade at Austin I was getting messages that car after car was derailing and then miracle of miracles-rerailing! Then the process would start again! It is really not a big deal as I dont find it that much an irritant because since it does not impact what I am doing I just ignore it. But it is a glitch in my opinion. Have a good one! Brian

I have experienced similar issues on Mullan, which has me concerned. Running a 3x4x1 coal train up the grade, was getting constant derailing, even in areas of very broad/gentle curves. In the case of both this coal train and the Z Train Reroute consist, they are very very homogenous consists of all loads of similar car length, and all cars being nearly identical weight. These consists are also based on prototypical consists that run over this route without issue daily.

The coal train is 3 locos up front, 67 coal loads, 4 mid-train helpers, 58 more coal loads, then 1 DPU. Grade is 2.2%. The derailment was happening right at or very near to the mid-train helpers, so I am thinking the sim is being overly sensitive to the large in-train forces happening at the mid-trains.

Either there is a flaw that we (the TrainSimulations) team have introduced unknowingly in our WAG or ENG files that never surfaced previously because this type of derailment detection was not a thing... or, there is an error in the new code.

Either way, I am actually in agreement that it would be nice to figure out the solution to the problem, as I am always a fan of realism

[steamer_ctn]

Hi geepster775,
It may be taking many of us some time to fully embrace OR but its developers should beware that the current trend to make it "more realistic" also increases its complexity, running the risk of 'frightening' some users off. The way to get more users on-board is to make the transition from MSTS as 'seamfree' as possible and, in that respect, quite a good job has been done. Most of us don't want to have to do all the mundane jobs an engine driver/engineer has to do, but just drive a passenger train from A to B, stopping at intermediate stations and attempting to keep to the timetable, or a freight train, probably performing occasional shunting, but everything in reasonable accuracy.
As you might guess, I'd support an on/off switch!!

A Simple/Advanced Physic mode has been suggested to cater for different users.

http://www.elvastower.com/forums/ind...ost__p__273779

This feature could be moved to the ADVANCED physics mode, and then people who wish to operate in SIMPLE mode would not be bothered by it.

Either there is a flaw that we (the TrainSimulations) team have introduced unknowingly in our WAG or ENG files that never surfaced previously because this type of derailment detection was not a thing... or, there is an error in the new code.

Either way, I am actually in agreement that it would be nice to figure out the solution to the problem, as I am always a fan of realism

As has been stated a few times in this thread the feature has been tested against real world information, and appears to be realistic.

The development was been based upon relevant railway guidelines. With the operation of longer trains since the 1990s, there has been more focus by the railway companies on string-lining and buffing force derailments.

@Sean, I am happy to work with you to set up a test environment to look at your situation provided we can find appropriate documentation to give us sufficient information.

[UP_4848_Thunder]

Seams things are getting out of control. The lighter the cars are the more vulnerable to derail. Some railroads have in their rules you must not exceed 50MPH with empty cars in train but some railroads have placement restrictions. I created a new law names for my stock when dealing with loads or empties or light cars so when building them in consists editor I know where what should go or be but my next later down road is hazmat placard abbreviations.

MT Basically 30 tons or under
LT 30-50 tons
LD 50-75 tons
PLD 75-100 tons
HLD 100-200 tons

But to cut story short vendors or freeware contributors are new to this well because we got a new feature in the beginning test stages and what new parameters need to be added to eng/wag files but I put this example of how an what to calculate whether empty or loaded. There are plenty of stock out there released that rarely even use ORTS parameters like example some wonder why they get the curve speed exceeded messages. But yea I agree a on/off for derailment messages need to be added.

Example 1 bellow shows what dimension parameters to calculate, add and look for to tweak or test their stock to a better standard before bashing authors or vendors. A good test example would be testing them on default equipment then get a feel an test on various routes locomotives etc.

ORTSLengthBogieCentre ( )
ORTSLengthCarBody ( )
ORTSLengthCouplerFace ( )
ORTSNumberAxles ( )
ORTSNumberBogies ( )





More examples to come later for long cars and articulates.

[niknak]

I too am getting derailments on Mullan Pass Z reroute act just past the Austin nameboard. This occurs on both the latest MG version and the latest testing version. However it doesn't occur when in autopilot mode. I don't remember this happening (or any comments on the forum) a few months ago when I last ran this activity. but that could just be my memory.

Nick.

[geepster775]

It appears the first 21 or so well platforms are string-lining on the hairpin curve at Austin. Happens whether super-elevation is on or off. Farther up the hill, I was getting fewer cars doing that in the less tighter curves across the trestles. Train was only 87 platforms with power in 3x2, so train makeup is not the cause. Recall that when this route was released, there were 2 contentious physics issues between route builders and dev team. One involving excessive tractive effort needed to overcome resting resistance to get the train rolling, and a car position lurching effect upon restores that were causing broken couplers. As a result the rolling stock was released with MSTS physics instead of Davis values.

[PerryPlatypus]

A Simple/Advanced Physic mode has been suggested to cater for different users.

http://www.elvastower.com/forums/ind...ost__p__273779

This feature could be moved to the ADVANCED physics mode, and then people who wish to operate in SIMPLE mode would not be bothered by it.



As has been stated a few times in this thread the feature has been tested against real world information, and appears to be realistic.

The development was been based upon relevant railway guidelines. With the operation of longer trains since the 1990s, there has been more focus by the railway companies on string-lining and buffing force derailments.

@Sean, I am happy to work with you to set up a test environment to look at your situation provided we can find appropriate documentation to give us sufficient information.

Hi Peter,

Thanks for the response. It might be a bit until I can respond to set up a formal testing scenario with you, but I'll email you when I get some time in the coming weeks to do that.

I have briefly looked through the relevant pages on your Coals to Newcastle site. I see mention of the follow variables:
ORTSLengthBogieCentre - length between bogie centres.
ORTSLengthCarBody - Length between car ends (For most accuracy, use the coupler pivot point).
ORTSLengthCouplerFace - length between coupler faces.
ORTSNumberAxles - number of axles on the car.
ORTSNumberBogies - number of bogies on the car.

There is a statement that when these values are not explicitly specified (which would be the case with any of the Mullan content), that they are estimated from information in the WAG. Obviously I am curious what formulas are used for estimating these values.

I do want to bring up the issue of superelevation as a potential cause. In the real world, superelevation is going to have a major contributing factor to derailments. Stringline events are often. Does your new derailment calculations take into account superelevation? All of those real world derailments would've occurred on track with varying degrees of superelevation. Do your calculations assume that the real-world derailments occurred on curves with zero superelevation?

Mullan Pass has a built in superelevation table that specifies superelevation for various curve radii. This table was created by studying the track charts and trying to determine "typical" values of superelevation for a particular curve radius. However, as I'm sure you know in the real world, this superelevation can vary significantly from one curve to another on the same railroad, even between two curves with the same radius. It's all a matter of design track speed for a particular spot.

What I am getting at is:
1. Does the new derailment code take into account superelevation, and if it does not
2. How can the derailment code adequately check the L/V ratio if it is not properly taking into account superelevation, and/or considering the fact the vast majority of currently available ORTS routes do not specify magnitude of superelevation on particular curves anyway? Ideally the derailment code needs some way of estimating the superelevation on a particular curve in the sim - perhaps by doing a back calculation based on track speed and curve radius using typical "unbalance" values for rolling stock. Maybe some calculation like that is already happening?