ORTS Engine file for OpenRails - Annotated

[R. Steele]

(Idea for this thread originated with peterman's post#4 >>> https://www.trainsim.com/vbts/showth...nly-diesel-Eng)

Here's an annotated engine file for Open Rails, set up as an include file to be placed in an OpenRails folder.

According to the manual

...preferred solution is to place the OR-specific .wag or .eng file in a created
folder TRAINS\TRAINSET\TrainCar\OpenRails\... (

Adding ORTS parameters to the default MSTS file is NOT the method to use. Not only is it destructive to the original file, it is compromising both MSTS and ORTS data integrity.
Keep MSTS and ORTS data parameters separate.

I did the best I could, trying to find all the ORTS parameters, that had references in the manual or otherwise were verified. I found a few that are in the code, but not published anywhere, I think they were left undeveloped, they are not included - example ORTSGenerator..
This sample is for Diesel, there are other ORTS parameters for Steam, Hydraulic, and Electric - all found in the manual.
Please check for errors.
Attached zip had downloadable copy.

***FIRST LINE IS ALWAYS BLANK SPACE***
include ( "..\\Name of Engine File.eng" )
Wagon (
	CouplerBlock ( )  Comment ( rear coupling )
	CouplerBlock ( )  Comment ( front coupling )
	BufferBlock ( )
				Comment ( substitute include string for all three above )
				Comment ( include ( "..\\..\\Common.Std\\Engines\\Std_Coupler.inc" ) )
	ORTSBrakeShoeFriction ( x, y ) Comment ( see Manual section 8.6.1 )
	BrakeParameters
				Comment ( substitute include brake string for brake parameters )
				Comment ( include ( "..\\..\\Common.Std\\Engines\\Std_Eng_Brakes.inc" )  )
	ORTSAdhesion ( ORTSCurtius_Kniffler ( 7.5 44 0.161 0.7 ) )   Comment  ( Manual Section 8.1.3 )
	ORTSAdhesion ( ORTSSlipWarningThreshold ( 70 ) )  Comment  ( Adjustable, Manual Section 8.1.3 )
				Comment ( ORTSAdhesion can be formated same as "throttle down" block below )
				Comment ( interia default is estimated from Loco Mass and Maximal Power, unless set )
	ORTSAdhesion( Wheelset (  ) Axle (  ) ORTSInertia (  ) )  Comment  ( leave out if unknown = Manual Section 8.1.3 )
	ORTSBearingType ( Roller ) Comment ( accepts Roller, Friction, and Low ) 
	ORTSDavis_A ( 2138.03 )   Comment ( FCalc2 used to calculate Davis A,B,&C = use metric units )
	ORTSDavis_B ( 70.4167 )   Comment ( Davis Numbers UoM hard coded )
	ORTSDavis_C ( 8.337645 )
        ***Comment( == Assumptions -Locomotive diesel/electric - speed - 65mph (105km/h), Roller Bearing, 6 axles, frontal area - 14.5m2, WagonWeight - 214.0 ton (metric), Drag 1.0 == )
	ORTSTrackGauge ( 1435 ) Comment (default in mm -leave out if unknown, Manual Sec 8.9 )
	ORTSRigidWheelBase ( 5ft 6in ) Comment ( default-leave out if unknown, Manual Sec 8.9 )
	ORTSUnbalancedSuperElevation ( ) Comment ( leave out if unknown, Manual Sec 8.11 )
	ORTSFreightAnims ( ) Comment ( see Manual section 9.3.2 )
	Lighting ( )
	Comment ( Complete lighting block must be used, if different from MSTS engine file  )
	Comment ( Engine Sound can be added, if different from MSTS engine file )
)
Engine (
	Effects
	(
		DieselSpecialEffects
		(
		Exhaust1
			(
                0 4.781 0.912
				0 1 0
				0.17
			)
		)
    )
    Comment ( CabView can be added )
	Comment ( Cab Sound can be added )
    Comment ( substitute include string for ORTSDiesel Block )
	Comment ( include ( "..\\..\\Common.Std\\Engines\\Std_Engine.inc" ) )
	Comment ( for ORTS Diesel Engines Block UoM see Manual page 82, hard coded )
	Comment ( Multiple Diesel Engines Blocks can set for one locomotive, number is unlimited )
	Comment ( Complete Engines Block must be present, only optional line is ExhaustDynamicsDown )
ORTSDieselEngines ( 1
		Diesel(
			IdleRPM ( 318 )
			MaxRPM ( 904 )
			StartingRPM ( 255 )
			StartingConfirmRPM ( 318 )
			ChangeUpRPMpS ( 75 )
			ChangeDownRPMpS ( 25 )
			RateOfChangeUpRPMpSS ( 5 )
			RateOfChangeDownRPMpSS ( 5 )
			MaximalPower ( 2237.1kW )
			IdleExhaust ( 1 )
			MaxExhaust ( 3 )
			ExhaustDynamics ( 2 )
			ExhaustDynamicsDown ( 0.5 )
			ExhaustColor ( 206B787D )
			ExhaustTransientColor ( 40212324 )
			DieselPowerTab (
				  0	  0
				318	  0
				393	  279638
				468	  559275
				543	  838913
				618	  1118550
				693	  1398188
				768	  1677825
				843	  1957463
				904	  2237100
			)
			DieselConsumptionTab (
				0    0
				318  5.2
				904  164
			)
			ThrottleRPMTab (
				0   318
				12.5  393
				25  468
				37.5  543
				50  618
				62.5  693
				75  768
				87.5  843
				100  904
			)
			DieselTorqueTab (
				0     0
				318  51155
				904  409236
			)
			MinOilPressure ( 20 )
			MaxOilPressure ( 50 )
			MaxTemperature ( 120 )
			Cooling ( 3 )
			TempTimeConstant ( 720 )
			OptTemperature ( 71 )
			IdleTemperature ( 55 )
		)
	)
	ORTS  (	ORTSWheelslipCausesThrottleDown ( 1 )
 		  	ORTSEmergencyCausesThrottleDown ( 1 )
			ORTSMainResChargingRate ( 0.750 )
			ORTSBrakePipeChargingRate ( 30 )
			ORTSEngineBrakeReleaseRate ( 38 )
			ORTSEngineBrakeApplicationRate ( 34 )
			ORTSBrakePipeTimeFactor ( 0.003 )
			ORTSBrakeEmergencyTimeFactor ( 0.15 )
			ORTSBrakeServiceTimeFactor ( 1.46 )
			ORTSAirBrakeMainresvolume ( 11 )
			ORTSDynamicBlendingOverride ( 1 )
	)
	ORTSDriveWheelWeight ( MASS ) Comment ( total weight on loco driving wheels in metric tons -leave out if unknown )
    ORTSMaxTractiveForceCurves ( )  Comment ( see Manual section 8.14 )
    ORTSTractionCharacteristics ( ) Comment  ( see Manual section 8.2.2 )
    ORTSContinuousForceTimeFactor ( 1800 ) Comment ( Adjustable, default hard coded in seconds, Manual Sec. 8.7 )
)

ORTS_Locomotive.zip
I didn't make this file for actual use in the sim, too many comment lines. I made it just to show what possible ORTS parameters existed and in which section of the file they belonged. For explanation purposes only. If you search there are other threads with examples of working files and how to implement them.

***The Davis numbers Comment/Assumptions line is very important. Please take the time to include in the file. This line is taken directly from Peter Newell's very excellent site Coals to Newcastle, http://www.coalstonewcastle.com.au/ . A treasure trove of information, especially for steam, but importantly, for ORTS in general.
When you put in the assumptions section it provides those who come after a chance not only to check your work, but to also learn from what you did. It furthers the knowledge base and helps to maintain accurate data. It also helps eliminate the "pulling data from thin air syndrome", you've left a trail documenting your process, that is always helpful to others wishing to learn.

[baldwin]

Thing is, that really only applies if you are still running ORTS and MSTS. I am not, so all my eng files have ORTS data in them and I do not use an Open Rails sub folder for eng/wag files.

Anything that begins with ORTS will be ignored by MSTS anyway because it is not programmed to read those lines.

As for the couplings, right now ORTS will only use one, not two, and will add one if none are present in the eng/wag file.

[GokuMK]

Adding ORTS parameters to the default MSTS file is NOT the method to use. Not only is it destructive to the original file, it is compromising both MSTS and ORTS data integrity.

Any examples of this destructivity?
MSTS ignores all ORTS values. And OR makes always one file from these two during gameplay, so no difference.

Only reason to put ORTS values in separate file is that it makes much easier to edit by hand the ENG file to fit MSTS and OR requirements.

[wacampbell]

Only reason to put ORTS values in separate file is that it makes much easier to edit by hand the ENG file to fit MSTS and OR requirements.

I added this feature to OpenRails for two reasons:

1. to make it easier for people to release ORTS enabled versions of library models while respecting the .eng file copyright of the original author. The original builder may have left the hobby or not be interested in adding OR support to his loco. Someone else can create a ORTS folder for that loco and release it as an update kit. This folder does not have to contain any of the original builder's files.

2. to allow MSTS compatibility in the event ORTS values conflict with the MSTS values. I envisioned a scenario where putting the correct values in a file - for HP say - or mass etc - might make the model not work right in MSTS or break MSTS activities. As everyone knows, over the years, people have done some strange things with .eng file values. So having a separate file for ORTS ensures that nothing changes for MSTS users.


Wayne

[R. Steele]

Any examples of this destructivity?
MSTS ignores all ORTS values. And OR makes always one file from these two during gameplay, so no difference.

Only reason to put ORTS values in separate file is that it makes much easier to edit by hand the ENG file to fit MSTS and OR requirements.

Goku, perhaps my choice of "destructive" was inept, but I refer you to & Baldwin to post#4 for an explanation far more cogent than any I could provide.

[peterman]

(Idea for this thread originated with peterman's post#4 >>> https://www.trainsim.com/vbts/showth...y-diesel-Eng)/

Gerry,

I see that you didn't read my post correctly... I said, " an OR .eng file"... not an MSTS .eng file with an include alias. One day the developers of locomotives and such will be making locomotives with 25,000 or 30,000 polys, which probably wouldn't allow MSTS to load them, therefore the include file would be irrelevant. Baldwin has summed it up quite nicely.

Peter

[R. Steele]

Peter, Following is the last post I made in the thread where you posted your idea "that I didn't read correctly"

Not quite what you proposed, but I thought I would start from here, so we could all weigh in on what ORTS specific parameters were useful and what worked. Once we get that figured out we can add a specific ORTSDieselEngine block to whatever we choose from the library and then see what we got. I think you guys with much more experience than I should choose something you all can agree on...Yeh I can hear the howls of laughter on that point!
I started a new thread >>> https://www.trainsim.com/vbts/showth...90#post1925090

"Not quite what you proposed is what I said" and is this not quite what you proposed? Alas, you are like most people who think they "read" but are falling rather short in the comprehension aspect of reading. But I did leave the idea out there, if all could agree on something...read and comprehend the post. What, I gotta do all the work!
So, I'll tell you what, get together with Baldwin and you two come up with the engine you are dreaming of...time to put up fellas.

And Baldwin, certainly you should keep doing what you are doing, if it gives you pleasure. This is a hobby, after all, and I'm not one to argue with someone else concerning what gives them pleasure with their hobby, what's the point?

[baldwin]

Gerry

I base my post on research and testing that was done before the use of an Open Rails sub-folder was added to the manual. The basic ORTS steam loco eng file does not use this folder, and can be a mix of legacy MSTS data where used and new style ORTS data. This works because MSTS by design discards anything that it is not programmed to read.

As for include files, there is no agreed standard or method for use, and as Otto was fond of saying KISS is the way to go. So mine reside in the standard eng file because I see no point in making an Open Rails sub-folder when I am not using MSTS. So, for an ORTS eng file it merely requires that the ORTS data is inserted, and where this clashes with legacy MSTS data, the latter is removed.

I even have a test train that has no couplers and it runs just like any other train in ORTS, so I question the need for couplers in the eng/wag files apart from defining coupler break values.

[R. Steele]

I even have a test train that has no couplers and it runs just like any other train in ORTS, so I question the need for couplers in the eng/wag files apart from defining coupler break values.

(my emphasis - gerry)

The underlined/bold is the important part for people to understand, they should adjust the break values from unrealistically high MSTS to the closer to prototypical values of ORTS... to do that you have to have at least one complete coupler block included in the files [correct?],
either using the method I outlined or the method you outlined...user choice of course.

[peterman]

Peter, Following is the last post I made in the thread where you posted your idea "that I didn't read correctly"



"Not quite what you proposed is what I said" and is this not quite what you proposed? Alas, you are like most people who think they "read" but are falling rather short in the comprehension aspect of reading. But I did leave the idea out there, if all could agree on something...read and comprehend the post. What, I gotta do all the work!
So, I'll tell you what, get together with Baldwin and you two come up with the engine you are dreaming of...time to put up fellas.

And Baldwin, certainly you should keep doing what you are doing, if it gives you pleasure. This is a hobby, after all, and I'm not one to argue with someone else concerning what gives them pleasure with their hobby, what's the point?

Gerry,

You have officially been added to the list !!!

Peter

[R. Steele]

Gerry,

You have officially been added to the list !!!

Peter

Why Peter, my good man (as far as I can tell from viewing your words on a web page, who knows?) are you channeling Dear, Beloved, Otto?
I'm Honored! ( No snark or irony intended, so don't infer it.)
Regards, Gerry

[muskokaandtahoe]

WRT using an extra folder in your .wag or .eng folder to place OR specific parameters and values -- I don't bother. I only run OR (have not run in MSTS since day 1 of the OR project) and given that fact I've worked out (yet another) solution that seems to work well for me:

I created a library a master repository for all .wags and ,engs. I divided that into two halves, one for stock MSTS files and the other for OR. Whatever is in those folders is copied (or symbolically linked) to the folders I actual use to run routes. For all practical purposes what is in my MSTS master repository is a backup. When I download something I put the files there. Then I add a copy over in the OR half and do all my OR specific edits over there, creating "stock" OR files. IMO it's a far more straightforward solution than stuffing an OR folder inside of your MSTS content because most people who use OR are OR-Only users.

WRT keeping files in sync between my master repository and any directory where cars and locomotive files are actually used, I recommend a program called beyond Compare. In fact, I regard it as an essential tool for either MSTS or OR. It gives you side by side comparisons of directories and files, even the lines of files. You can show everything, only differences in identically named files, and/or missing files. Pick the version you want and with a single click move a copy to the other directory. It Is, IMO, the absolute best tool for keeping multiple copies of .wags and .engs in sync, no matter how many different places they're placed.

The demo for Beyond Compare said 4 weeks... it gave me something like 4 months. Low price, one of the best pieces of software I've ever purchased. I wish I had it when the concept of mini routes was introduced.

[muskokaandtahoe]

Gerry, WRT your example of the .inc folder. Do give some thought to what guys will need when they have rolling stock from multiple countries and will want to be setting up .inc files. It's probably not much of an issue for those of us in North America but may well be a factor for lot sof other people. I'm using \[country name] as the first sub folder.

Next I thought I'd mention that like your example I started out with a single common.std folder. I started to have concerns about that when creating .inc files for commonly owned locomotives in North America -- F7's for example -- where I was seeing variation in the original files when looking at stuff created by different people. Length... lights... locomotive performance stuff. I eventually concluded I was not going to invest my time trying to ferret out which data value was "most correct" and accepted that I needed to have multiple .inc files assigned based on who created the model. As I worked that list of .inc files grew pretty rapidly and I grew concerned the one folder was being over-crowded. My solution was to go with two "common" folders, one for the whole fleet -- couplers, brakes, brake stands, etc., and another specific to certain models. So I'm now using common.fleet and common.models as my root folders for most .inc files and the next level is country.

I like the idea of your \engines subdirectory; I'd call it locomotives because that is the whole unit whereas the engines are down at the drive mechanisms. Perhaps two more - Freight and Passenger as well?

Last point -- a general concern: How best to deal with multiple people distributing .inc files... how is anyone to know that a newly downloaded .inc file contains some specification that screws you over? Should we be setting a standard that includes identifying who created the file? Naming it differently (at first) so it can be checked out? Adding a date so you can compare which version is newer? No suggestions from me (yet), just a concern I think should be considered before we go too far on promoting the include feature.

[muskokaandtahoe]

Why Peter, my good man (as far as I can tell from viewing your words on a web page, who knows?) are you channeling Dear, Beloved, Otto?
I'm Honored! ( No snark or irony intended, so don't infer it.)
Regards, Gerry

Could be!

Among the many useful things I learned from Otto was that grammar in German has a rule that every sentence ends with an exclamation point!

Who knew!

May he rest in peace.

[Erick_Cantu]

The best thing, honestly, would for someone to figure out what we need and what we don't and create a set of template OR-only .eng and .wag files with only what's necessary in them and the MSTS-only parameters removed. No include files, no extra directories, no libraries, no paths, just models and physics. KISS is a good rule to follow, I think. There just ain't any utility in cross-compatibility anymore.