Page 3 of 8 FirstFirst 12345 ... LastLast
Results 21 to 30 of 72

Thread: Long Train Operation

  1. #21
    Join Date
    Sep 2006
    Location
    .
    Posts
    2,741

    Default

    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.

  2. #22
    Join Date
    Jan 2011
    Location
    New York
    Posts
    384

    Default

    Quote Originally Posted by geepster775 View Post
    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

  3. #23

    Default

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

  4. #24
    Join Date
    Jan 2011
    Location
    New York
    Posts
    384

    Default

    Quote Originally Posted by dcarleton View Post
    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

  5. #25
    Join Date
    Jun 2009
    Location
    Post Falls, ID
    Posts
    1,133

    Default

    Quote Originally Posted by motormaster532 View Post
    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
    Last edited by PerryPlatypus; 12-08-2021 at 12:51 AM.
    ~Sean Kelly~
    MRL Mullan Pass for Open Rails: https://www.trainsimulations.net/mullanpass
    SP Shasta Route for Open Rails: In Development / Tracks 100%, Scenery 75%

  6. #26

    Default

    Quote Originally Posted by slipperman View Post
    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.


    Quote Originally Posted by PerryPlatypus View Post
    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.

  7. #27
    Join Date
    Nov 2008
    Location
    Alhambra Sub MP 484/ Southern California
    Posts
    448

    Default

    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.

  8. #28
    Join Date
    Nov 1999
    Location
    UK.
    Posts
    783

    Default

    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.
    Dell Desktop. Intel i5 3.3 CPU. 8GB RAM. Nvidia GTX 1050Ti 4GB graphics. Windows Pro 64bit. RailDriver. Partridge in a pear tree...

  9. #29
    Join Date
    Sep 2006
    Location
    .
    Posts
    2,741

    Default

    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.

  10. #30
    Join Date
    Jun 2009
    Location
    Post Falls, ID
    Posts
    1,133

    Default

    Quote Originally Posted by steamer_ctn View Post
    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?
    ~Sean Kelly~
    MRL Mullan Pass for Open Rails: https://www.trainsimulations.net/mullanpass
    SP Shasta Route for Open Rails: In Development / Tracks 100%, Scenery 75%

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
-->