[R H Steele]

Sid P., on 17 December 2015 - 02:42 PM, said:

I may write a summary of the OR "include" methods for the Manual.

Sid, that would be excellent, thank you. I'm still a little hazy about the include file function in OR, - the line-space business for one thing. It would be nice to know how many and type of include files now can be used. I could not really locate anything in the manual about it - or what the correct name is "include function" "include file" ??

[Csantucci]

I believe I read in a remote post that an empty line was needed on top of the include file, however I never tested that. It's good that Sid tested that. If he found that such line (and the blank line below the include line) isn't needed in the .eng and .wag files, it isn't needed in the .trk files either.

[Genma Saotome]

R H Steele, on 17 December 2015 - 04:42 PM, said:

Sid, that would be excellent, thank you. I'm still a little hazy about the include file function in OR, - the line-space business for one thing. It would be nice to know how many and type of include files now can be used. I could not really locate anything in the manual about it - or what the correct name is "include function" "include file" ??

The Include file concept was initially applied to .wags and .engs and simply put Include() means "go over there and read that file too". Using it in the *.trk is simply applying the idea in another place. In .wags and .engs any number of include files can be specified.

In the beginning, the only technical requirements I know of is to end the .inc file with a blank line and begin the file with either a blank line or a comment line (I choose to use a comment line and I put the file name there). Apparently that requirement has been dropped... but it's probably good practice to use line 1 as I described so you know what it is supposed to be.



I have done a lot of experimenting with include files for .wags and .engs and have concluded they fall into three basic types:

• Will usually apply to each .wag and .eng -- think universal coupler and brake data.
  
• Will apply to all .wags or .engs of the same design from the same modeler AND those files are scattered across multiple trainset directories -- Joe's SD-40-2 locomotive skinned for 7 different roads, kept in 7 different folders, will likely have identical Lights data, among other things.
  
• Will apply only to multiple .wags or .engs that are all in the same folder.

What seems to work best for these three is to put the first two types in specific-to-this-purpose directories in trainset (I used the names Common_Fleet_Stds for the first type and Common_Model_Stds for the second and that works well. The third type stays in the directory with its .wags or .engs. I've described this approach in several other posts.

I don't know how much thought has been given to where the include file for *.trk should go... seems to me it would be fine to leave it the home directory of the route itself, just like its parent *.trk file.

[Sid P.]

Genma Saotome, on 18 December 2015 - 11:00 AM, said:

The Include file concept was initially applied to .wags and .engs and simply put Include() means "go over there and read that file too". Using it in the *.trk is simply applying the idea in another place. In .wags and .engs any number of include files can be specified.
....
I don't know how much thought has been given to where the include file for *.trk should go... seems to me it would be fine to leave it the home directory of the route itself, just like its parent *.trk file.

The Manual already has a good description, (submitted by a user) of the use of include files: "8.14 Or-Specific File Inclusions for MSTS .eng and .wag Files". It could be expanded to discuss general include files.

Re the .trk include - I agree that the Route folder seems the logical spot, since the data could be very route-specific.

BTW, perhaps those reading this topic have not read the extensive and detailed description by James Ross of using system-wide include files in http://www.elvastowe...-include-files/ .

Cheers,

[al225]

Will the Thomas and Friends references ever stop?

Attached thumbnail(s)

• 

[Mike B]

Just a note: I've been running Rollins Pass lately, and trees-on-tracks (or at least big-bushes-on-tracks; not a lot of actual trees in the route other than high in the mountains) are common. It did seem for a while, in development builds before 1.1, that the problem had been mostly fixed (with other route) - has there been a reversion, or is RP just a bad route in this regard (not in many other ways - nice route that I had not used much recently). Currently using 1.1.3487 (stable).

[dennisat]

Mike B, on 03 May 2016 - 06:58 AM, said:

Just a note: I've been running Rollins Pass lately, and trees-on-tracks (or at least big-bushes-on-tracks; not a lot of actual trees in the route other than high in the mountains) are common. It did seem for a while, in development builds before 1.1, that the problem had been mostly fixed (with other route) - has there been a reversion, or is RP just a bad route in this regard (not in many other ways - nice route that I had not used much recently). Currently using 1.1.3487 (stable).

Have a look at this on UKTrainsim. The info is on Elvas Tower as well but I can't find it at the moment.

Dennis

[James Ross]

Mike B, on 03 May 2016 - 06:58 AM, said:

Just a note: I've been running Rollins Pass lately, and trees-on-tracks (or at least big-bushes-on-tracks; not a lot of actual trees in the route other than high in the mountains) are common. It did seem for a while, in development builds before 1.1, that the problem had been mostly fixed (with other route) - has there been a reversion, or is RP just a bad route in this regard (not in many other ways - nice route that I had not used much recently). Currently using 1.1.3487 (stable).

The details of the change are earlier in this thread.

The original code was deemed too expensive/slow to run by default, and it was impossible to know how far from the tracks to clear of trees because e.g. some routes use forest objects to place lineside vegetation.

Thus we have made it enabled via a route option (in .trk), so the route author (and users willing to edit files) can easily make the decision on whether it should be applied to a given route and how much clearance of the track should be given.

[dennisat]

dennisat, on 03 May 2016 - 07:32 AM, said:

The info is on Elvas Tower as well but I can't find it at the moment.

James Ross, on 03 May 2016 - 11:47 AM, said:

The details of the change are earlier in this thread.

Sorry, my brain must have gone AWOL. I now see that in my explanation of this on UKTrainsim I also noted that it is in the OR Manual.

Dennis

[Mike B]

Thanks. Brain fade plus not following the discussion continuously.

Edit: finally plodded through all the messages, including the include file notes. Will try on the weakling laptop to see what the effect on frame rate really is. Thanks again.

Edit2: Yes, it works on Rollins Pass. Minor frame rate effect - not noticeable on main desktop. Kind of a chevron-shimmering effect on some cut slopes near the track, but no effect on operation. For those who might not be as knowledgeable about basic Windows things as others, might want to mention that if the .trk file name has a space in it (as in "Rollins Pass"), the path and file name in the include reference must be inside quotes - on pain of a "load error" reported in the route choice box in the ORTS menu; elementary, but some people don't know that.