Long Train Operation

[geepster775]

Backwards compatibility is important, but is not 100% ecompassing nor should it be forever. There has to be some form of obsolescence planning involved, pathways to move users away from obsolete and unusable material. Already we have route design techniques that when optimized for Open Rails make the routes unplayable in MSTS. Same goes for activities. Activities are designed today that use features in open rails that make them unplayable in MSTS. New payware rolling stock being assembled from former MSTS multi-part shapes and produced now as one-piece shapes that exceeds MSTS capabilities.

In another thread, Randy stated he only uses 4 GB of his 30 GB TRAINSET folder. He found out that 87% of that 30 GB was unused, most of it likely comprised of abandoned or unsupported freeware. He did the responsible thing and actually analyzed and managed his TRAINSET folder. I have a hard time supporting perpetual compatibility with a bunch of unused material just to accommodate those who are lazy and feel exempt from applying the same analysis. There has to be a mechanism to slowly peel away from past.

ORTS has lost more users to new sim franchises that came along simply because it has not moved fast enough to escape the MSTS gravitational pull of limitations.

[CSRX]

In my opinion refinements and improvements in OR shouldn't require changes in pre-existing rolling stock to continue using it as usual. If these refinements and improvements require such changes, they should either subject to option checkboxes or should become operational only if additional parameters are inserted in the .wag and .eng files. Backwards compatibility is important IMHO.

100 percent this!
Call me lazy all you want, but some here have zero clue about actual life versus a video game, and it shows.

Some people moved on from ORTS not just because it's taking time to step away from MSTS, but because it is a hassle with all this updates and upgrades one has to do.
Most want plug and play, and I don't blame them. That's why I often run Train Sim World when I just want to relax, versus get frustrated that yet again I need to update my rolling stock and engines, for them to still work.

When you spend numerous hours on a project, for it to become obsolete, to me that's a slap to the face to all those still trying to provide rolling stock and engines for the community.

Shrugs.

[dcarleton]

When you spend numerous hours on a project, for it to become obsolete, to me that's a slap to the face to all those still trying to provide rolling stock and engines for the community.

100 percent that!

[R. Steele]

100 percent this!
Call me lazy all you want, but some here have zero clue about actual life versus a video game, and it shows.

Some people moved on from ORTS not just because it's taking time to step away from MSTS, but because it is a hassle with all this updates and upgrades one has to do.
Most want plug and play, and I don't blame them. That's why I often run Train Sim World when I just want to relax, versus get frustrated that yet again I need to update my rolling stock and engines, for them to still work.

When you spend numerous hours on a project, for it to become obsolete, to me that's a slap to the face to all those still trying to provide rolling stock and engines for the community.

Shrugs.

Real life, you do the same dang thing on a daily basis, waiting for air to pump.
So you want a video game, not a simulation, with MSTS is a game, ORTS is closer to the real deal, with a few minor irritating issues that are bit unrealistic at the moment.

As mentioned, don't want to wait, hit the "Shift ?" button combo.

Anyways, I need to buy a few more items from TS.

Puzzling, contrary views, take a breath hoss. I can't fathom what you would find acceptable, all the models you've graciously repainted or provided still work for me, nothing is obsolete. I suppose the case is, when the issues become irritating to you, then they become a reason for complaint?

Anyway all this is quite a ways from the point of the thread.

Which was:

If you are operating long trains, then you will be interested in potential derailment issues, and your trains will need to be marshalled appropriately.

Open Rails supports derailment detection, and this feature is demonstrated in the mini route described here -

http://www.elvastower.com/forums/ind...51#entry278251

The scenarios described are based upon actual Accident Reports describing derailments.

I can see Carlo's point about:

If these refinements and improvements require such changes, they should either subject to option checkboxes or should become operational only if additional parameters are inserted in the .wag and .eng files.

steamer_ctn has posted about having the derailment parameters apply only to advanced physics, not simple physics...which is more in the plug and play area.

Perhaps you should direct your energies to asking if that can be accomplished? I'm finished.

[csantucci]

I'd add that there is further way to provide backwards compatibility while not renouncing at more accurate physics calculations, and that is the Experimental Option "Correct questionable braking parameters", which could be extended to "Correct questionable physics parameters". What this option does is to check at runtime some .eng parameters and, if they are outside reasonable ranges, which can occur quite frequently for old rolling stock, to correct them on the fly (only in memory) so that such rolling stock runs as it should under these more accurate physics calculations. This of course can't cover 100% of the cases, or provide very precise substitutions, but it can give a good contribution to keep old stock usable without re-engineering effort.

[CSRX]

No matter how you try to spin it against me Gerry, ORTS is still a computer game.
While backwards compatibility still works at the moment, and most of my equipment still works at the moment, there will be a day it doesn't. To be honest as well, updating current items I plan to release, versus not updating some of the older models that still look really great in the sim (older NEPS stuff) you can tell they act differently than the current standards of ORTS.

So again, when one puts in hours for something to become obsolete, that's frustrating, and makes it understandable on why so many have moved onto plug and play games versus trying to constantly work on something just to enjoy running it.

[UP_4848_Thunder]

Its a mixed feeling when it comes to updating stock on an on as ORTS updates the code but when new features come out I can understand the frustrations. Heck I am afraid to make new releases just because everyday I feel something is missing or am waiting on a better feature or something that needs tweaking or/and its just I am too busy working on a real Class 1 railroad taking my sim time away (but proud to be single lol). I have new spines an autoracks in the works but I don't feel comfortable because some features was missing but now in the works which is this topic. Other thing awaits bug fixes and tweaks is in the coupler code dealing with long cushion slack without the need of extra wag files even though its no problem to have some stocks remain with multiple wag files for one wagon as I have seen real stuff matching my idea like a pulled out drawbar instead of its knuckle breaking and even a pin cracking. But me I mix out coupler strengths by the few thousands an tonnage formula ratings bonus as it has always annoyed me in ORTS everything with same rating the 1st out car always broke instead of cars back so some couplers need to have some steroids or be the weakest link.

But my opinion for those that dislike ORTS team putting efforts out there providing constant testing builds an new features to public instead of their selves like other game/simulation platforms that only put new features yearly where you gotta buy to try an wait next time or years not given new lives for original.... Accept or un accept the changes or help improve if you see something wrong an not bash because you have no motivation to tweak or add the features of parameters. With route riter eng/wag editor I at times have a less timely matter editing or adding to packs of repaints of the same configuration or exact similar shapes with just repaints.

I agree some check and un check options need to be in the options but way I look at it now in none lazy way with changing or adding features to stock is like the real railroading deal of different crafts fixing issues with engines/wagons or adding something new. So what we need now is a sim version of the FRA to qualify new/old or upcoming releases payware or freeware up to todays an future ORTS standards an give new lives to pre releases in a team like manner? Some may not like it an some may like it but its like offers, as I have in the past had a number of freeware authors respond but then not respond showing obviously no interest of updates an improvements I did to a past release getting new live or you can say makeover oh because they feel some type of way of their old release showing or running that age. I get doubtful of my works too but I update to my interest if I have to or want to. But like I mentioned before I have things I am not comfortable or got the time to release till something is done.

[R. Steele]

...While backwards compatibility still works at the moment, and most of my equipment still works at the moment, there will be a day it doesn't. ....So again, when one puts in hours for something to become obsolete...

That's putting a rather drastic and misleadingly negative interpretation upon the reality of the situation Shawn, because the stated development policy on the OR website ( and in discussions I've read ) show this to be the real intentions of OR development...always has been.
From the OR website...

Content Compatibility

Open Rails will continue to maintain compatibility with content from previous official versions of Open Rails.
File Formats

New types of content will use the JavaScript Object Notation (JSON).
Existing types of content from previous official versions of Open Rails will continue to be loaded without change.

The content you are so generously ---- and expertly --- offering to the community will be usable in the future ( as is everything in the TS library back to 2001 ) --- but the forward movement of OR towards more realism will hopefully continue.

[R. Steele]

edit to my post: I should add, that going forward some of the added features may not be available to users running the simulation with simple physics. With the stated development policy ( above below ) I would expect everything to work reasonably well using simple physics.

[scottb613]

Hi Folks,

As one of the few modelers left - just my two cents. I'm all for backwards compatibility and supporting existing content - with the caveat - that it doesn't become the ball and chain preventing us from moving forward with ORTS improvements. I anxiously await each new addition to ORTS and have high hopes for its future - that's where my focus lies - if I need to make changes to leverage those additions - so be it.

Regards,
Scott

[CSRX]

That's putting a rather drastic and misleadingly negative interpretation upon the reality of the situation Shawn, because the stated development policy on the OR website ( and in discussions I've read ) show this to be the real intentions of OR development...always has been.
From the OR website...

The content you are so generously ---- and expertly --- offering to the community will be usable in the future ( as is everything in the TS library back to 2001 ) --- but the forward movement of OR towards more realism will hopefully continue.

No, I'm not actually. Who in their bright mind is going to use items from 2001, let alone my recent work that will eventually become "obsolete" compared to current or future standards of ORTS, physics wise and etc.

[jonpd]

Sometimes those models from 2001 or whatever are the only things out there. Not everyone has the skill or inclination to build new models. I appreciate the efforts of the dwindling number of those that do.

[UP_4848_Thunder]

Making new lives like refurbishing older content still gives opportunities for models to keep standing out if one doesn't want to make a whole new model like for the example of Erick Cantu default replacement equipment that replaced Couplers an trucks as I still use them but with tweaked physics. There is other older content I still use as they were an are still great reskins with couple of things showing their age that I just think of replacement parts or whole new model for them if the interest is there or just live with it with some good to worth keeping. Example of good reskins are models that Ted Curphey made or models using his contributed trucks an couplers that can keep the base model of reskins an just replace/delete obvious aged parts needing a makeover like couplers an wheels.

As long as one can still give credit for original content giving new refurbished look up to standard then some content is still alive an put to use. My example of this is I used Jeff Auberpine Autorack Ace mapping and made a completely new shape because the thing I thought was missing is having left an right sides independent of each other, wanted the sides to have its holes to see cars on the variety of levels, animate open ramp doors and have animated slack couplers that give enough cushion room which still needs tweaks in advanced coupling. I got the experiment that I wanted to see and it gave me the opportunity to have either visually breaking a drawbar or coupler but it consumes couple of things till ORTS moves forward fixing.

So older worth keeping content recycled at a free cost with better tweaked or new shape is a good or bad opinion to keep content a new life? Vendors payware tend to do this but on sad part with new names but same car number instead of replacing the older one or providing shape updates.

[UP_4848_Thunder]

On the physics related side back on topic to this subject... this week I have worked an come up with an idea that can save users time on new releases an make it simple to convert older physics to the new standard of this topic without having too much copying an pasting involved when something has been updated or tweaked to a better standard in the future. I myself get tired of updating each content with new parameters line after line but am not lazy frustrated having to do so when interest comes up as I like new improved ORTS additions and realism.

Since we have conversion kits and standard engine files for locomotives by Gerry I think some divided advanced standard sections need to be made for the type of wagon/car as well an put to use to save people time updating each tweaked line for those that get frustrated doing it every time something new comes into picture. Only thing people need to tweak to their basics is size, COG, mass, shapes, names, couplers, legacy lines etc. Thing I am afraid of dealing with this is tons, friction, coupler strengths, brake forces and their calculations in inc. files but there is the way to start from minimum-max ton numbers of a given car dividing them up in separate files every 5 tons where users choosing will have to round off the tons to give accurate standards like a load sensing device.

I been going through various resources about flanges, angle an it's length calculations that I made various inc files to root to test stocks as include files for where if in the future something is added, tweaked, deleted of that given coefficient standard file then the thousands of rooted converted files using that include file will get the change with one click as if its a complete rebuild to all as if one was replacing MSTS Trainset/Default/Default.wag. Other thing I divided for test stock is the type of car an their own standards that I had to make a long name as well as put abbreviated author/company name in the type of car. I am using various stocks whether worn/new flanges to give variety but also measured flanges myself at work an come by various numbers whether they were worn/average/new an need to convert those lengths vs just google resources.

AAR-1B Profiles seems like a good average standard I been testing and using since it has been reported to have a Flange Angle of 75deg, Flange Length of 618in worn where new points to 625in. Since Treading and flange thickness are not a ORTS thing yet the average AAR-1B flange is some inch's thicker than newer modern AAR-2A thickness where AAR-2A reduce wear with its little reduced thickness given its track gauge enough little playroom instead of being tight to the exact track gauge. I wonder if changing the inches on the stocks profile track gauge some little inches up since smaller has derail risks or give a degree angle 1 number up to reduce derailments?

Example of the root inc file setup (bellow) I have now but plan to change the root names if this AAR/FRA like standard for ORTS files to save many time based on subject of the car by making a pack of parameters up to standard. If something is changed or added like Global Tsection.dat for example then a advanced physics team will update, upload for one to download overwritten files to change the thousands of rooted files to a tweaked standard that's met? Conversion kits are what authors once finished need to convert from templates an upload to get more downloads of their previous file uploads as if they the carmen.

Comment ( Dimensions based on Erick Cantu 78' Centerbeam Shape )
Comment ( Wheel Base an Axles based on AAR-1B Worn Profile )
Comment ( include ( "..\\..\\1V.Common_Physics.inc\\NA_Freight\\Center beam\\DerailCoeff\\Centerbeam-EC_78'_WFLange0.618In-75Deg.inc" ) )


Comment ( **************** Derailment Coefficients **********************
Included in this section - Wheelbase, Gauge, Flange, Axles etc
************************************************** ************* )
ORTSUnbalancedSuperElevation ( 2.56in )
ORTSTrackGauge ( 4.0ft 8.5in )
ORTSRigidWheelBase ( 5.0ft 10.8in )
ORTSWheelFlangeLength ( 0.618in )
ORTSMaximumWheelFlangeAngle ( 75deg )
ORTSNumberAxles ( 4 )
ORTSNumberBogies ( 2 )


Comment ( Dimensions based on Erick Cantu 78' Centerbeam Shape )
ORTSLengthBogieCentre ( 56.201ft )
ORTSLengthCarBody ( 69.822ft )
ORTSLengthCouplerFace ( 77.822ft )


The setup you see may be divided into 2 where the type of car may have its own folders of Dimensions an Wheel profiles instead of the words related to Derail Coeffiecients for NorthAmerican Content.

[R. Steele]

... I think some divided advanced standard sections need to be made for the type of wagon/car ...

That's a fine idea for a resource for people to use...much of that information can be found in various manual, specification drawings, and various editions of the "Car and Locomotive Cyclopedia of American Practice"...it does take time to research and find all the stuff, not to mention the expense of buying editions of the cyclopedia. I've put together quite a few of these for various locomotives and cars...however--this might be a problem--all mine are in the default or metric units of OR, not in the common US units. They also lack the Open Rails "best practice" comment sections outline by steamer_ctn in his website --- they do have comments...more about sourcing and use of the materials.

One other problem is the file naming conventions I used...they are all over the place and really don't reflect any advanced understanding of railroad nomenclature or names...that would have to be addressed by someone with more experience than myself.

I'd be willing to make these public domain, if anyone is interested in using them, users will have to convert them. Currently I have 62 for cars and 46 for locomotives. Below is a sample of both.

File name: 65ft_MILL_GON.inc

Comment ( The Car and Locomotive Cyclopedia of American Practice 4th Editon 1980 Page-127 )
Comment ( Builder - Greenville Steel Car Company 1979 -- 3242cuft )
Comment ( Example Missouri Pacific Gon Number-650944 )
Comment ( Frontal Area == 8.509015 meters squared = 91.59028ft^2 )
Comment ( Load Limits - Light Weight = 59525lbs - Load Limit 190000lbs - Gross Rail Load = 249525lbs )
Comment ( Load Limits - Light Weight = 27t - Load Limit 86.18255t - Gross Rail Load = 113.1826t )
Comment ( include ( "..\\..\\..\\..\\..\\Common.inc\\Fleet\\CarBody\\65ft_MILL_GON.inc" ) )

	ORTSNumberAxles ( 4 )
	ORTSNumberBogies ( 2 )
	ORTSLengthBogieCentre ( 16.9926m )
	ORTSLengthCarBody ( 20.828m )
	ORTSLengthCouplerFace ( 21.6281m )
	ORTSWagonFrontalArea ( 91.59028ft^2 )
	ORTSRigidWheelBase ( 1.778m )
	ORTSWheelFlangeLength ( 19.1516mm )
	ORTSMaximumWheelFlangeAngle ( 1.308996rad )
	ORTSTrackGauge ( 1435.1mm )
	ORTSUnbalancedSuperelevation ( 65.024mm )

File Name: EMD_SD40-2.inc

Comment ( The Car and Locomotive Cyclopedia of American Practice 4th Editon 1980 Pages768-769 )
Comment ( Dimensions apply to EMD SD40-2 & SD40T2, SD40-2F, and safety cab "W" model )
Comment ( Frontal Area == cross sectional area == 14.5 meters squared = 156.0767ft^2 )
Comment ( SD40-2F  Frontal Area == cross sectional area == 14.9 meters squared = 160.3823ft^2 )
Comment ( Mass Range: 368000lbs = 166.922t to 420000lbs = 190.5088t fully loaded and ballasted )
Comment ( ORTS Parameters for wagon section of ENG file )
Comment ( include ( "..\\..\\..\\..\\..\\Common.inc\\Locomotives\\CarBody\\EMD_SD40-2.inc" ) )

	ORTSNumberAxles ( 0 )
	ORTSNumberBogies ( 2 )
	ORTSLengthBogieCentre ( 13.2588m )
	ORTSLengthCarBody ( 19.7104m )
	ORTSLengthCouplerFace ( 20.9804m )
	ORTSWagonFrontalArea ( 156.0767ft^2 )
	ORTSRigidWheelBase ( 4.149725m )
	ORTSWheelFlangeLength ( 19.1516mm )
	ORTSMaximumWheelFlangeAngle ( 1.308996rad )
	ORTSTrackGauge ( 1435.1mm )
	ORTSUnbalancedSuperelevation ( 65.024mm )

They all would probably need to be reworked to make the usable for the wider OR community...but the basic data is accurate and sourced. Some are from measurements taken from models and are commented as such.