[Traindude]

Weter, on 19 April 2024 - 08:57 PM, said:

May I try and translate the document, please, for better "immersion", what would help me to understand the text better?

Sure. If you need any clarification, please let me know.

[Weter]

Thanks. I'll do.

[Weter]

Quote

The use of *.inc files and Include ( ) statements can, of course, be used in any MSTS-compatible file
using the “SIMISA@@@@@@@@@@JINX0D0t______” header, and not just *.eng or *.wag
files. However, the similar guidelines (see pages 3-4) apply.

About headers, see James Ross' article on his Silver site. JINX0D0t is indeed *.eng/*.wag configutation's signature, other types have differences there.
Here and further

Here and farther, yellow afe for recommended insertions.

Quote

These files contain all the necessary information—about physics, sound, cab view files, etc—that are to be used by that locomotive or car.

Purple are for argue statements:

Quote

Additionally, these duplicated parameters among tens of dozens of *.wag and *.eng files can eat up many megabytes of disk space in no time at all.

Text file "weights" less, than 50-100 Kb, however, You are right in core.

dark-olive is for reference text, 3hich can be omitted by author, when reading, used for confirmation of context only.

Quote

When ORTS loads the *.eng or *.wag file folder, it will also look for a subfolder labeled
OpenRails. If it finds one, it will then look for an *.eng or *.wag file of the same name as the
main file. The*.eng and *.wag files contained within this subfolder are abbreviated versions
that usually contain ORTS-exclusive parameters, in order to maintain the main files'
compatibility with MSTS, and are tied into the main *.eng or *.wag file with an Include ( )
statement pointing to the main *.eng or *.wag file (example: Include ( “myloco.eng” )).

There can be FULL file versions, in order to not modify original MSTS files, but remove obsolete, incorrect and out-of-use (by ORTS) MSTS parameters completely, in addition to insertion of new ORTS parameyers needed.

That's great, You've inserted links to specific primary documents!
Very well-done work.

[Traindude]

Weter, on 20 April 2024 - 06:42 AM, said:

About headers, see James Ross' article on his Silver site. JINX0D0t is indeed *.eng/*.wag configutation's signature, other types have differences there.
Here and further

Here and farther, yellow afe for recommended insertions.


Purple are for argue statements:
Text file "weights" less, than 50-100 Kb, however, You are right in core.

dark-olive is for reference text, 3hich can be omitted by author, when reading, used for confirmation of context only.

There can be FULL file versions, in order to not modify original MSTS files, but remove obsolete, incorrect and out-of-use (by ORTS) MSTS parameters completely, in addition to insertion of new ORTS parameyers needed.

That's great, You've inserted links to specific primary documents!
Very well-done work.

Here's an updated version with your suggestions.

Attached File(s)

•  incfiletutorial.pdf (254.29K)
  Number of downloads: 17

[Genma Saotome]

Sanjay, the only concern I have about the information you've put together is with the examples. The use of very non-specific names for your .inc files can be rather dangerous in practice. For example, in North America there are at least 7 different brake standards in use in the 20th century. If you are using a set of brake data for 1995 named brakes.inc and you receive another named brakes.inc containing values correct for 1916 there will be problems running your activities.

Because of that risk I use very specific names when creating .inc files so I can tell at a glance the differences and pick the correct one.

I do understand you were giving examples and the use of generic names made it easy to write. May I suggest you slip something into the introduction of you examples telling the reader you used very generic names for easy reading and to warn the reader that his own names should be specific enough to avoid problems with .inc files for the same purpose colliding because no one took care to deal with the differences of era and maybe even country in the file names or directory paths.

[Traindude]

Genma Saotome, on 21 April 2024 - 09:28 PM, said:

Sanjay, the only concern I have about the information you've put together is with the examples. The use of very non-specific names for your .inc files can be rather dangerous in practice. For example, in North America there are at least 7 different brake standards in use in the 20th century. If you are using a set of brake data for 1995 named brakes.inc and you receive another named brakes.inc containing values correct for 1916 there will be problems running your activities.

Because of that risk I use very specific names when creating .inc files so I can tell at a glance the differences and pick the correct one.

I do understand you were giving examples and the use of generic names made it easy to write. May I suggest you slip something into the introduction of you examples telling the reader you used very generic names for easy reading and to warn the reader that his own names should be specific enough to avoid problems with .inc files for the same purpose colliding because no one took care to deal with the differences of era and maybe even country in the file names or directory paths.

I totally understand where you're coming from.

In my examples at the end of the tutorial, I put a subfolder within the main *.eng and *.wag file folder labeled Include. (This is in addition to the normal Cabview and Sound subfolders.) Thus, in that case, the file paths would be:

/TRAINS/TRAINSET/Indian_Valley_4_6_2/INCLUDE/LOCO/Brakes_Wag.inc
/TRAINS/TRAINSET/Cedar_Park_Railway_4_4_0/INCLUDE/TENDER/Brakes.inc

By putting the *.inc files in a separate subfolder within the main *.eng/*.wag folder, I don't have to add prefixes to every *.inc file.

On the other hand, if the *.inc files for multiple locomotives or cars were in a centralized location, such as separate "Common.brakes" folder, then it would be necessary to name the files with the specific style of brake system (e.g. K, UC, 6ET, etc.).

A few of the guys here on ET and I are working on a set of standardized *.inc files for North American brakes and couplers that hopefully addresses, if not avoids, this kind of ambiguity.

[Weter]

Hello.
Thanks for attention to my notes; I sincerely hope, some of them would help.
I beg pardon for not gathering all of suggestions into one post, but here are some more:
I've seen the discussion here, where Laci and Carlo have convention, that SAME NAME key would be useful with include files.
Actually, I've no idea, was that new feature added into official code, or currently remains NYMG-only.

Also, within the same discussion, the idea about recursivity of *.inc-files was mentioned.
With all that said, I think, You may look into that, when You'd have some time, and decide, could that be useful to be used in Your document, or no.

[pschlik]

Completely forgot that [[SameName]] was a thing, that's included in official versions and really only serves one purpose: making it a little easier for an OpenRails replacement file to reference the original file. Not always useful, I don't use it, but more people should know it exists.

[Genma Saotome]

Traindude, on 21 April 2024 - 10:49 PM, said:

/TRAINS/TRAINSET/Indian_Valley_4_6_2/INCLUDE/LOCO/Brakes_Wag.inc
/TRAINS/TRAINSET/Cedar_Park_Railway_4_4_0/INCLUDE/TENDER/Brakes.inc

Yes, in the case of an .inc file used to influence the behavior of only the ,wags or .engs in the same folder, yeah, then the name doesn't really matter. Even in the case of several \trainset folders having the same .s file for an Indian_Valley_4_6_2, generic is good enough (n.b., in this case I'd put those .inc files into \common.inc\models\person's name\Indian_Valley_4_6_2. This way all of the .engs for however many folders are holding the Indian_Valley_4_6_2 would look there for brakes).

Then to be complete, the feedback I gave yesterday should have made clear the need for very specific names is for anything used on a fleet-wide basis. Sorry for the omission.