[ATW]

I would use templates in maybe reskins or renumbers but I don't feel success to do so yet till some things are finished being fixed an implemented. Test unit's are no problem in beta releases.

2 main ones I wait on is the current talk of adhesion an powered axle counts an engine temperature parameter tweaks an other additions an fixes.

[copperpen]

All that is needed is a set of 5 files based on one locomotive. The first we all have, it is the original MSTS eng file. Second is the MSTS file with basic OR parameters added. Third is a basic OR file with all of the surplus MSTS parameters stripped out. Fourth is the advanced OR file with all of the currently known and used bells and whistles. Fifth is an example using include files.

There is no need to wait until features are completed, they can be added when done.

[ATW]

I guess so since it will not need any major changes to main original eng except in the "Wagon (" sections since the bug in ORTS now is if I include a "Wagon (" section ORTS does not read the "Engine (" sections of the sub folder eng file. That is no major thing on my end of sharing as of now unless I recommend separately a change or addition in the "Wagon (" section of the main eng file... otherwise Engine sections alone now can easily be placed in a chosen matching engines folder in OpenRails subfolder an making outside an inside (changes of the include line name of sub eng) file to root linked main eng file.

Again as mentioned the bug about sub eng file lines Wagon vs Engine section is as follows on my end till further investigation:
1. Subfolder "OpenRails" with sub eng reads a regular full eng file's "Wagon (" sections with no problem but skips reading "Engine (" section lines even with new ORTS or regular MSTS parameters.
2. Deleting OpenRails sub eng file "Wagon (" sections solves the problem of ORTS not reading new an tweaked MSTS parameters in "Engine (" section.
3. So if both Wagon an Engine sections are included of a sub eng file it will only read Wagon section. So if any changes or limited addition to wagon sections of eng file like ORTS Adhesion line or braking types, timing, max brake force, mass, shape etc... I have to put the changes an addition in main original eng file.

4. The good simple thing I like about the sub "Engine (" line sections is if I am missing a line that's in main eng... ORTS moves on to read the main but if I am not missing it in sub eng... ORTS reads it where I don't have to worry of original MSTS lines messing up even though I just use MSTS for release testing purposes (since I had reports from those wanting my releases to work in MSTS).


So I guess now its not much worry to release beta eng file templates without the need of shapes even though I plan to use full freeware units later in future an maybe my soon tweaked SD70M's an GEVO's as full releases.

[ATW]

I have put together a beta template for North American locomotives being modern BNSF. Based on info I have come by to put this together I would like to point that not all railroads use the same Throttle HP settings as majority use their own custom made ones an don't always use the typical prototype settings. Since this is a ready to go beta, I started it out with modern BNSF an have many other prototypes in the works but not ready to release. Default Dash9 is a good test unit to start out with. For those that have the SLI BNSF Scenic sub engines you can easily start from there too but name editing an linking is required.

Recommended For advance experienced eng an wag file editors but here are the steps.

1. Choose a test engine matching the engine.
2. Copy attached locomotive prototype eng file contained in zip.
3. In the chosen locomotives folder make sure a sub folder named OpenRails is made then paste the eng file in it.
4. Rename the OpenRails eng file to the existing test units main rooted eng name.
5. Open the ORTS eng file an simply rename the include line name to the same opened ORTS eng file.
6. Test out in ORTS in a consists an have fun.

Note. included Eng files have their own custom Throttle % settings set to use MSTS Basic % settings to reduce the bugs of cabview display mismatches of the notch number displays... Main eng file is highly recommended to use the basic default throttle % as HP notch settings are already set to there true matching curve which saves the need.

Throttle ( 0 1 0.125 0
NumNotches ( 9
Notch ( 0 0 Dummy )
Notch ( 0.125 0 Dummy )
Notch ( 0.25 0 Dummy )
Notch ( 0.375 0 Dummy )
Notch ( 0.5 0 Dummy )
Notch ( 0.625 0 Dummy )
Notch ( 0.75 0 Dummy )
Notch ( 0.875 0 Dummy )
Notch ( 1 0 Dummy )
)
)



I would have put the Controller settings in the files to skip from main eng but ORTS has a couple of bugs reading some original MSTS eng parameters lines while in sub folder eng files which still needs some looking into.

I am not responsible of any harm done to your system using these. For tips, questions or other concerns just PM me or post here

 Modern_BNSF_Engines_Beta_1.zip (9.33K)
Number of downloads: 293

[cr-stagg]

ATW,
I noticed that the second line of your engine files begin with:
"include ( ..\"
Normally the Parameters begin with a Capital letter as in Engine, Sanding, Mass, Lights, etc.
Is there a reason that you made them
"include ( ..\"
instead of
"Include ( ..\" ?

[Genma Saotome]

AFAIK it should always be ..\\ and not ..\

I've seen error messages for the later... invalid path.

I'm also in the habit of placing everything with the parenthesis in double quotes -- Include ( "..\\string..." ) -- but I do not know if it's necessary.

[cr-stagg]

Genma Saotome, on 29 April 2016 - 09:09 AM, said:

AFAIK it should always be ..\\ and not ..\

I've seen error messages for the later... invalid path.

I'm also in the habit of placing everything with the parenthesis in double quotes -- Include ( "..\\string..." ) -- but I do not know if it's necessary.

Dave,
I made a typo I my question. I should have said: ATW uses "include ( ../" not "include ( ..\" in the second line of his ENG files.

Quotes around the data are only necessary if there is a space in one of the path/file names. A space signifies end of data or separation of data when more than one data item is present. But always using quotes is a good idea.

I have another question. Why are these lines written this way:

ORTS (
ORTSEmergencyCausesThrottleDown( 1 )
)
ORTS (
ORTSEmergencyEngagesHorn( 0 )
)
ORTS (
ORTSWheelSlipCausesThrottleDown( 1 )
)
ORTS (
ORTSEmergencyCausesPowerDown( 1 )
)

And not this way:

ORTS (

ORTSEmergencyCausesThrottleDown( 1 )
ORTSEmergencyEngagesHorn( 0 )
ORTSWheelSlipCausesThrottleDown( 1 )
ORTSEmergencyCausesPowerDown( 1 )

)

And one more question: Where are terms like "ORTSEmergencyCausesThrottleDown" defined? A search for "ORTSEmergencyCausesThrottleDown" in the Manual gets zero results.

[ATW]

Strange you are getting errors an I am not but I will change it. These eng files are supposed to be in a subfolder an the reason ../xxx.eng instead of just xxx.eng

Is no one even seeing a change in performance an visual getting errors because the files came directly from test unit's?

I use the most recent x3535 with no error on my end as far as loading.

[cr-stagg]

ATW,

I was not questioning your use of the "../". I was questioning why you used an "i" instead of "I" in the Parameter Include.

[ATW]

cr-stagg, on 29 April 2016 - 09:45 AM, said:

I have another question. Why are these lines written this way:

ORTS (
ORTSEmergencyCausesThrottleDown( 1 )
)
ORTS (
ORTSEmergencyEngagesHorn( 0 )
)
ORTS (
ORTSWheelSlipCausesThrottleDown( 1 )
)
ORTS (
ORTSEmergencyCausesPowerDown( 1 )
)

And not this way:

ORTS (

ORTSEmergencyCausesThrottleDown( 1 )
ORTSEmergencyEngagesHorn( 0 )
ORTSWheelSlipCausesThrottleDown( 1 )
ORTSEmergencyCausesPowerDown( 1 )

)

The way they are included is how ORTS positively reads them where the other organized way ORTS does not read. This is a good topic to look into.

As for the i an not I in the include I seen no difference but can change that as well since I used a template post that had the same include setup. These are beta template files anyway an more to come in variety.