[Eldorado.Railroad]

While looking at some include files and corresponding .eng/.wag files a curious thought came to mind which I cannot find a clear answer.

So in the case of Test.eng file:


Scenario 1)

Quote

include ( "..\\Someplace\\Couplers\\My_Coupler.inc" )

.....
Coupling (
Type ( Automatic )
Spring (
Stiffness ( 4e2N/m 6e6N/m )
Damping ( 5e6N/m/s 5e6N/m/s )
Break ( 5.1e7N 5.1e7N )
r0 ( 12cm 15cm )
)
Comment ( CouplingHasRigidConnection ( 1 ) )
Velocity ( -0.2m/s )
)
.....

Scenario 2)

Quote

.....
Coupling (
Type ( Automatic )
Spring (
Stiffness ( 4e2N/m 6e6N/m )
Damping ( 5e6N/m/s 5e6N/m/s )
Break ( 5.1e7N 5.1e7N )
r0 ( 12cm 15cm )
)
Comment ( CouplingHasRigidConnection ( 1 ) )
Velocity ( -0.2m/s )
)

include ( "..\\Someplace\\Couplers\\My_Coupler.inc" )
.....

Note that the position of "include ( "..\\Someplace\\Couplers\\My_Coupler.inc" )" in the file is different in each scenario. The contents of My_Coupler.inc is basically a replacement, nothing OR specific, of what is is already in the Coupling() declaration in the Test.eng file.
In what scenario does the information in " include ( "..\\Someplace\\Couplers\\My_Coupler.inc" )" overwrite what is in the Test.eng file? How can you prove your assertion?

Regardless of best practice and smaller files, etc. I would like to know what really happens as it simplifies the use of some older consist managers which balk at an OR only type of .eng/.wag file.These older consist managers ignore newer OR only type entries as long as all of the MSTS expected data is there. It would be most convenient to simply drop in include files, in the proper places instead of having two different files, one for MSTS(legacy) and the other OR only.

I ask this because the official documentation for OR only has examples where one large include is placed at the top of an existing MSTS(legacy) .eng file. I assume here that what is in the include file "overrides" everything else in the .eng file. Is that correct?

This may be a messy question to ask, as the purpose of the include files are to not only add OR specific entries, but also possibly MSTS(legacy) entries! So who wins the battle here?

Thanks,
Steve

[Genma Saotome]

When there are multiple occurrences of any parameter OR will keep the values from the last one read. I use that rule to create empty .wag files that look like this:

Wagon ( XM_PRR_x29_503449_Mt

WagonShape ( PRR_X29_503449.s )
FreightAnim ( X29_parts.s 1 1 1 )
Include ( "..\\Common.Inc\\Models\\Tim_Muir\\X29_&_ARA_Boxcar\\PRR_X29_Empty_Car.inc" )
Include ( "..\\Common.inc\\Fleet\\DHNelson\\Std_Type_E_Coupler_Generic_Draft_Gear.inc" )
Include ( "..\\Common.inc\\Fleet\\DHNelson\\Single_Pipe_AB_Brakes.inc" )
Sound ( "GenFreightWag1.sms" )
Name ( "XM 40' PRR X29 503449 Mt 1924-68" )

)


and then the same car carrying a load in a different .wag file:

Wagon ( XM_PRR_x29_503449_Machinery

WagonShape ( PRR_X29_503449.s )
FreightAnim ( X29_parts.s 1 1 1 )
Include ( "..\\Common.Inc\\Models\\Tim_Muir\\X29_&_ARA_Boxcar\\PRR_X29_Empty_Car.inc" )
Include ( "..\\Common.Inc\\Models\\Tim_Muir\\X29_&_ARA_Boxcar\\PRR_X29_Machinery.inc" )
Include ( "..\\Common.inc\\Fleet\\DHNelson\\Std_Type_E_Coupler_Generic_Draft_Gear.inc" )
Include ( "..\\Common.inc\\Fleet\\DHNelson\\Single_Pipe_AB_Brakes.inc" )
Sound ( "GenFreightWag1.sms" )
Name ( "XM 40' PRR X29 503449 Machinery 1924-68" )

)

The only difference is the second file has an include statement for the machinery load. This also means I can create a bunch of lading files for this class of cars... all I need to do is take the empty .wag file, rename it for the load, add the one line, update the string inside name(), save.

To dig deeper, the load file contains only those parameters whose value will change because the car weighs more:

Comment ( "Machinery load for ARA & X29 Boxcars" )

comment ( "Part 2A and 2B are parameters based on presence or absence of a load. " )
comment ( "Parameters for an empty car belong in an Empty_Car.inc file." )
comment ( "Parameters for a loaded car belong in a Lading Name_Loads.inc file." )

comment ( "Part 2A - parameters based on presence or absence of a load." )

Mass ( 43.8061t-us )
CentreOfGravity (0m 1.25m 0m )
DerailRailForce ( 99.3523kN )
DerailBufferForce ( 371.0528kN )
ORTSDavis_A ( 146.6931lbf )
ORTSDavis_B ( 1.0625lbf/mph )
ORTSDavis_C ( 0.0594lbf/mph^2 )

comment ( "Part 2B - Unsupported parameters based on presence or absence of a load." )

LadingName ( "Machinery " )
LadingWeight ( 20.2061t-us )

All of the parameters you see in part 2A are also in the empty car file but the values the carry are for an empty car. I was trying to convert ALL of my .wags to this style of data management and stopped because (Australian) Peter was making a lot of code changes for brake show friction, super elevation and couplers and I deecidied it would be smart to let the dust settle and go thru one major effort to update stuff. I suppose most of that dust has settled but I've been busy w/ other things.

[Weter]

Hello, Steve.
I can repeat your statement: the MANUAL says almost nothing about include files.
For example, we can learn nothing about *.inc files usage from there.
Looking like, this part of manual was never revised last ten years.
(the stone, thrown towards ORMT's garden)

From my personal experience (I tried to improve smoke effects for diesels), if I use combination of *.eng-files (one MSTS-original and other in OpenRails subfolder), the parameters of smoke are somehow "mixed/multiplied", instead of substitution for new ones from OpenRails modified file. I've seen some confirmation of that somewhere in this forum, don't remember where.

Rudolf Richter's Eng-files Manual tells us, that program reads *.eng-files from their end to the beginning (what, as well, determines, which coupler description will be assumed as front, which-as rear). I don't know, is this order inherited by ORTS or no <Dave confirms that above>. Second consequence of given fact is: if you describe something at your *.eng-file twice (or more times), but it must be mentioned only once, the latest description will be taken in account during game loading, but all previous descriptions will be dropped.

ORTS Manual recommends to use modified for ORTS *.eng-files (complete), placed to OpenRails subfolder, instead of modified original files.

I know from Dave and ErickC two techniques of using include files, Manual told about third.
Nowadays I used successfully that way, when I include TrainBrakeValve () block, aliased to *.inc-file with it, to numerous of *.eng-files, that use this valve.
This way, I will be able to modify that include file once, but changes will be applied to all models, aliased to that.

I'm planning to use same technique for aliasing couplers later.

For the experiment, I comment () -out the blocks, that I plan to substitute by *.inc code, for easy roll-back all changes, if it won't work as expected.
This will "hide" unwanted block and prevent its reading by the program.
At least, I see no sense to use both (native and include) blocks simultaneously: if use include, then original block should be deleted or commented-out from the *.eng-file.

What is essential - the very FIRST STRING OF INCLUDE FILE MUST BE EMPTY.

[scottb613]

Weter, on 04 December 2021 - 11:10 PM, said:

What is essential - the very FIRST STRING OF INCLUDE FILE MUST BE EMPTY.

Hi Folks,

Also keep in mind that if you have a value with a very long string - with more than 80 characters - you need an empty line after the string with a CR. Took me a while to solve this issue.

EXAMPLE:

ORTSBrakeShoeFriction ( 0.0 0.5 8.0 0.288 16.1 0.241 24.1 0.211 32.2 0.187 40.2 0.173 48.3 0.161 56.3 0.150 64.4 0.142 72.2 0.139 80.5 0.134 88.5 0.129 96.6 0.125 104.6 0.123 112.7 0.121)

Regards,
Scott

[Eldorado.Railroad]

Could I please ask that you do NOT hijack this thread. The OP is not about whether MSTS is better than OR. Nor is the OP about having two different couplers in the same .eng/.wag file, etc. If you are unsure about what the OP is about, please re-read, or ask for further clarification.



< Admin Comment >

All the posts about how many couplers have been split off into a new thread titled "Question does OR use One coupler...." Please continue that discussion in that thread. Thank you!

The information about how to do includes in a .eng/.wag is already tenuous. I hope that future readers of this thread will find an answer to my OP, and not get confused about a completely different issue, for which the purpose of this OP was not intended.

As for Dave and "Weter", thanks for staying on topic, and also clarifying what was confusing to me. In practice some modelers, payware or otherwise have their own "ideas" on how to do includes in .eng/.wag files. I am not sure whether OR provides any debug facility to see what values in an .eng/.wag file are ACTUALLY being used at runtime. Having the facility to inspect those values, perhaps in a log file, would eliminate the "guesswork" for the modeler.

Given some of the responses, I think the manual for OR might have to be updated. Perhaps in SEPARATE thread we could illustrate what should be in that manual with regards to include files with the information we now have through our combined experiences. Some of this is quite complicated, so distilling it down to something that both the experienced and layperson would understand will be a bit of a challenge.

Thanks for your cooperation,
Steve

[Weter]

Indeed, Steve.
I've seen a great potential of include "technology", but Manual thought me almost nothing.
Different authors use different approaches, as their habits and visions tell them, so this way for me looks like a blind man's adventure.
Why no one of this function's dev's couldn't tell us clearly: how did that intended to work, what should it use and which syntax is right for that.
Why the Manual haven't been updates for so long?

Add:
There were some reports, that TSRE consist editor treats included files faulty some times.

[Genma Saotome]

Here's the background: I asked for the Include statement and the OR Team was nice enough to respond and provide it. I had intended to convert a bunch of .wags tot he new method and post them in the library but unfortunately there was a problem in my braking.inc file that took a very long time to figure out what I had done wrong. I had other things going on as well.... the net is I never published those files as a proposed standard. Other people stepped in and proposed their own solutions... and then more examples... etc. etc. SO IMO an opportunity was lost.

Going back to the start I had three principles I was following

• Since Include was OR-only so would the .engs and .wags that use them -- pure OR, no dual MSTS/OR fiddle.
  
• The location of the include files had to cover one-of's as well as shared across a handful of identical models skinned for various railroads (e.g., Tim Muir's USRA boxcars, AND shared across most .wags and .engs.
  
• Having been a professional data architect I knew the value of both object oriented design and third normal form which meant I was going to constrain include files to specific hardware instead of emptying out the .eng file and putting it all in one .inc file.

The hard part was location... it made perfect sense to me to follow the example of \common.snd and \common.cab for any .inc file that was going to be shared across multiple folders in \trainset. What turned out to be a bit problematic was how to handle updates to those files. What I finally settled on was using peoples names in the path. An example:

Include ( "..\\Common.Inc\\Models\\Tim_Muir\\X29_&_ARA_Boxcar\\PRR_X29_Machinery.inc" )
Include ( "..\\Common.inc\\Fleet\\DHNelson\\Std_Type_E_Coupler_Generic_Draft_Gear.inc" )

The first line has "Tim Muir" in it. He created the models. I put his name there because other people may have created models for the same cars (this is more common with locomotives) and as such there may be good reason to keep .inc files for both sets of models separate. The modelers name in the path does that. In other cases it is a payware name.

In the second line is "DHNelson" -- that's me. And as you see the parent directory is \Fleet. These .inc file are meant to be used by most .wags and .engs in a \trainset file and it seemed reasonable to me that many people could be creating and distributing such files and that it would be wise to keep them apart. I expect a typical process would be to install "John Doe's" files, check them out and if they were no good go into the .wag and change John's name to mine.

Here is what I have right now:

A variety of different couplers and brakes.


What I've done with models. A close look will reveal ONE empty car.inc file and all of the rest are for loads. This is pretty much typical for .wags, everything else that is needed will be found in \Fleet and shared by most .wags -- couplers and brakes. Go back to my post where I have a .wag file... it is only a dozen lines, many blank.



Not yet mention is one-of models. One folder, several .wags or .engs, nothing else remotely similar. In this case I put all the .inc files that are specific to this one model here, with the .wag or .eng files. It'll still use \fleet .inc files but there will not be anything under \Models because only on \trainset directory is present.

Hope this helps.

[Genma Saotome]

A few more thoughts... go back and glance at the list of files placed in \Fleet -- lots of couplers. I don't yet know what numbers to put in each so many are identical. Should I learn of some I'll edit the relevant file. This way I can accommodate changing technology over the decades and not have to wait to set up .inc files when I'm still in the dark.

Here is the "standard" empty car .inc file -- I change the values for different cars:

Comment ( XM_USRA_SS_Empty_Car.inc )

comment ( "Parts 1A and 1B are correct for all .wags of this model" )

comment ( "Part 1A - Parameters based on the model itself." )

Type ( Freight )
Size ( 3.1m 4.6m 13.45m )
InertiaTensor ( Box ( 3.1m 4.6m 13.15m ) )
MaxBrakeForce ( 90.9132kN )
MaxHandbrakeForce ( 18.1826kN )
BrakePipeVolume( 0.191ft^3 )
DerailRailHeight ( 2in )
ORTSTrackGauge ( 4ft 8.5in )
ORTSRigidWheelBase ( 5ft 6in )
ORTSBearingType ( Friction )
ORTSNumberAxles (4 )
WheelRadius ( 33in/2 )
ORTSUnbalancedSuperelevation ( 3in )
ORTSBrakeShoeFriction (
0.0 0.50
8.0 0.288
16.1 0.241
24.1 0.211
32.2 0.187
40.2 0.173
48.3 0.161
56.3 0.150
64.4 0.142
72.2 0.139
80.5 0.134
88.5 0.129
96.6 0.125
104.6 0.123
112.7 0.12
) Comment (* Cast Iron Brakeshoes *)

comment ( "Part 1B - Unsupported parameters based on the model itself." )

MaxWidth ( 10ft 1in )
MaxHeight ( 13ft 7in )
BrakeShoeFriction ( 0.2 )
TargetPctMtyWeight ( 0.7 )
DavisFormula ( "Davis 1926" )
CAPY ( 100000 )
LD_LMT ( 122400 )
LT_WT ( 46200 )

comment ( "Part 2A and 2B are parameters based on presence or absence of a load. " )
comment ( "Parameter values for an empty car belong in an Empty_Car.inc file." )
comment ( "Parameters value for a loaded car belong in a Lading Name_Loads.inc file." )

comment ( "Part 2A - parameters based on presence or absence of a load." )

Mass ( 26.069t-us )
CentreOfGravity( 0m 0.8m 0m )
DerailRailForce ( 59.1245kN )
DerailBufferForce ( 327.7kN )
ORTSDavis_A ( 146.225lbf )
ORTSDavis_B ( 1.0463lbf/mph )
ORTSDavis_C ( 0.0685lbf/mph^2 )
ORTSBearingType ( Friction )

comment ( "Part 2B - Unsupported parameters based on presence or absence of a load." )

LadingName ( None - Mty )
LadingWeight ( 0 lbs )

As I said earlier, everything that changes because of weight is located in section 2A. Note that brakeforce is not there... it is in 1A. That's because brakeforce normally doesn't ever change... except for some cars it does. Some cars have an Empty/Loaded switch that does change the brakefoce (coal hoppers for example). For these cars I'd move Brakeforce out of section 1A and put it in 2A. Here in the empty car.inc file I'd then change the value for brakeforce to be correct for an empty car... and then over in the load.inc file I'd add the lines there using the original values. Bingo, empty/load brakes.

What I cannot do with these files is reflect the changing weight that occurs within a session -- loading a coal car for example.

Last, please take a look at what I've labeled "Unsupported Parameters". It is my opinion that all of them could be useful as real parameters. Consider DavisFormula ( "Davis 1926" ); along with MaxWidth ( 10ft 1in ) and MaxHeight ( 13ft 7in ) we'd have the missing parameters that would allow OR to calculate the Davis A, B, and C values for us. Isn't that what software is supposed to do? Others in this collection are things I believe could be displayed as sprites or be part of other calculations OR software could do for us.


I think the approach I'm using would work for most people.

p.s. should anyone wonder why I bother with this stuff, the explanation is in the web page of the link below my .sig

[R H Steele]

Eldorado.Railroad, on 04 December 2021 - 07:56 PM, said:

...

I ask this because the official documentation for OR only has examples where one large include is placed at the top of an existing MSTS(legacy) .eng file. I assume here that what is in the include file "overrides" everything else in the .eng file. Is that correct?

This may be a messy question to ask, as the purpose of the include files are to not only add OR specific entries, but also possibly MSTS(legacy) entries! So who wins the battle here?

Thanks,
Steve

When I first encountered the ideas of include files and an OpenRails folder I was under the impression that it was originally introduced to add ORTS parameters and physics modifications while maintaining the integrity of the default msts file in the parent folder ( one level above ).

Reading about the history of the OpenRails folder and include files, if I'm not mistaken, I believe it was Wayne Campbell's idea to use the combination of the include file and the OpenRails folder. Not totally sure about that.
Of course, then I had no notion of how to construct a pure OR eng ( or wag ) file and also little understanding of the construction and usage of the different parts of the MSTS files.

I've always used the Open Rails folder to add OR specific parameters while leaving the default msts file untouched. I am still in the process of learning and understanding the different sections of eng and wag files, so the msts files provide a basic reference point for me.

Early on in the process I can remember reading a thread where it was mentioned that OR will look for an OpenRails folder first, parsing the information in that folder first, then look for the default eng or wag file to complete the loading process.

include ( "..\\SD402.eng" )
Wagon (
    Mass ( 176.9t )
    include ( "..\\..\\..\\..\\..\\Common.inc\\Locomotives\\Couplers\\Std_TypeF_Coupler.inc" )
    include ( "..\\..\\..\\..\\..\\Common.inc\\Locomotives\\Brakes\\Std_Loco_Brakes.inc" )
    ORTSAdhesion ( ORTSCurtius_Kniffler ( 7.5 44 0.161 0.7 ) )
    ORTSAdhesion ( ORTSSlipWarningThreshold ( 62 ) )
    ORTSNumberAxles ( 0 )
    ORTSNumberBogies ( 2 )
    ORTSLengthCouplerFace ( 20.9804m )
    ORTSLengthBogieCentre ( 13.5382m )
    ORTSBearingType ( Roller )
    ORTSDavis_A ( 1901.54 )
    ORTSDavis_B ( 58.2089 )
    ORTSDavis_C ( 8.337645 )
    ORTSWagonFrontalArea ( 156.0767ft^2 )
    ORTSTrackGauge ( 4ft 8.5in )
    ORTSRigidWheelBase ( 5.65ft 3.6in )
    ORTSUnbalancedSuperelevation ( 2.56in )
    Comment( == Assumptions -Locomotive Diesel-Electric, speed - 65mph (105km/h), Roller Bearing, 6 axles, frontal area - 14.5m2, Weight - 176.9 ton (metric), Drag 1.00 == )
)
Engine (
    Effects (
    	DieselSpecialEffects (
    		Exhaust1 (
    		0 4.57 1.75
    		0 1 0
    		0.25
    		)
    	)
    )
    ORTSDriveWheelWeight ( 176.9t )
    ORTSNumberDriveAxles ( 6 )
    include ( "..\\..\\..\\..\\..\\Common.inc\\Locomotives\\Std_Eng_SD40-2.inc" )
    include ( "..\\..\\..\\..\\..\\Common.inc\\Locomotives\\Brakes\\Dynamic\\SD40-2_177t_DynBrakes.inc" )
)

[scottb613]

Genma Saotome, on 05 December 2021 - 12:27 PM, said:

What I cannot do with these files is reflect the changing weight that occurs within a session -- loading a coal car for example.

Hi Dave,

Can you not use the Dynamic Freight Animation that we use on tenders to change the weight during a session? I'm pretty sure Peter had working load points to "fill" or "empty" car during a session.

Dynamic Loads
http://www.coalstone...sics/animation/

Regards,
Scott