[Genma Saotome]

I've been advocating the include concept for a long time... several years... and now that it is here I still like the Include() concept... but at this early stage it's not w/o frustrations.

First off, once your .wags and/or .engs start using Include() you can no longer use AE to create new activities that make use of them. AE (and RE too) just don't like them. Which means it is a bit of a problem putting Include() to use. They're fine so long as all that you are going to do is run existing consists. But if you're creating a new Activity you have to click thru n number of error messages to get into AE... and the same number when you try to save what you've done.

And don't even thing of using Conbuilder on files using Include().

So in practical terms you need two full installs of your routes: One using the original .wags and .engs -- where you run AE -- and a different one where you put your "Included" files and run OR. Absent a replacement AE this will be a bit of a bother for some time.


Second problem is about pathing within the domain of a mesh file. An example is needed to make clear what I'm describing. I took a model from the ET library -- a Fairbanks Morse H10-44 locomotive that's skinned for the Milwaukee Road. The download contains a number of .eng files, each representing a slightly different version of the locomotive... (maybe) some mesh differences and each instance is skinned uniquely. Becuase they're all in the same directory and share a whole lot of common data, the Include() file idea works very well... for example I created "H-10-44_Couplers.inc" and put a relevant Include() into each .eng. That works just fine. Doing similar things with other sections reduced each .eng file to a handful of lines and now If I want to tweek any values I go to the relevant *.inc file, tweek it, and it's automatically part of all of the .wags at run time. Way cool.

Where the pathing comes in is with this: What happens to those *.inc files when I have another instance of the H10-44 locomotive that is skinned for some other railroad? They're all relevant... and they're all in a folder titled "MILW_H10-44_#760-783" (n.b., the original folder was called H10-44-MILW-Reskin). So what happens if I had models skinned for the PRR, C&NW, and B&O??? I suppose their .wag files would have to say something like this:

Include ( "..\\..\\MILW_H10-44_#760-783\H10-44_Couplers.inc *" )  <--- see note at end of this post

Assuming that works. And having gone this far it becomes clear that the superior location for those include files in not is the MILW folder but in their own H10-40 folder. IOW directories more along these lines:

FM_H10-40
MILW_H10-44_#760-783
PRR_H10-44........

The implication is this: as the original mesh begins to take on more and more aspects of something representing the fundamental design of the locomotive or car the .eng and .wag takes on more and more aspects of something representing the presentation in-game of various instances. IMO this will require a certain amount of re-thinking on the parts of both OR developers, content creators, and end users.

Will a folder for, say, "3dtrains F7's" be accepted as the proper place to stick a bunch on standard-to-the-design *.inc files? And "SFRD_RR-40-32"? IOW folders w/ absolutely no reference to specific instances of .wags or .engs?

Will there be semi-standard names for these include files? Is "H44-10 Couplers.inc" a suitable name to promote... as opposed to "H44-10 Type E Couplers.inc", "H10-44_include01.inc", "Couplers.inc", or "Moe Howard Couplers.inc"?? Does it even matter (I'm inclined to say yes, it does).

Should the mesh file go into the directory where the standardizes include files are? IMO in many cases, yes.

What should one do when there are legitimate differences between versions of what is understood as the same kind of locomotive (or car)... such as an early version and a late version of the same locomotive (physical differences, such as more lights)? I would think the *.Inc files still belong to the class (The H10-44 level) but now the variation requires an Early whatever.inc and a Late whatever.inc; And because the mesh files are indeed different the question: Where do the mesh files go? Unique names at the class level or whatever goes in the instance directory?

My point is this is all new ground and I think it's going to take a fair amount of experimentation to get to a level where best practices are understood. In the meanwhile, given the AE issues I suggest folks try Include() experimentally so as to see the possibilities but not to go overboard and implement it fleet-wide as best practices... even features... are not yet understood.




* I've never liked the "..\\..\\" convention... especially if it is repeated all over the place. I've always figured using a mnemonic made more sense:

Path1 (..\\..\\FM_H10-40)
...
Include ( "Path1\H10-44_Couplers.inc" )
Include ( "Path1\H10-44_Lights.inc" )
etc...

Easier to read... easier to edit.

[markus_GE]

Genma Saotome, on 08 June 2014 - 11:26 AM, said:

[...]

So in practical terms you need two full installs of your routes: One using the original .wags and .engs -- where you run AE -- and a different one where you put your "Included" files and run OR. Absent a replacement AE this will be a bit of a bother for some time.

[...]

Some interesting thoughts there, but I can only offer help to one: You won´t need two full installs of you routes, because there´s not direct relation to the trains. IE, you would only need two installs for your trains, but not routes. Would? Would! - If it weren´t for the Open Rails sub directory of each item of stock ;)

Just put you files fitted with includes in a sub-directory "Open Rails" (hope, that´s the right spelling) of the assets' original folder inside TRAINSET, and there you go: Include compatibility: check. MSTS AE compatibility: check. CB compatibility: check. Compatibility to almost any other program: Check (disregard DPU here, though - I´ll still have to think about how DPU can digest Includes - or if it will / should at all).

Hope that helps a little :)

Cheers, Markus

[Lindsayts]

You have pointed out a number of things that need to be kept in mind but...........

Now I already have a separate install of MSTS and OR because of a number of differences between the two that already exist. The way I work is the any activities and consists are built in a COMPLETELY SEPARATE install of MSTS (Note 1) when things are working its all transferred over to openrails and modified as required. I evolved this method due to the many differences that already exist between MSTS and OR. Its for this reason of the many differnces that I believe OR now needs to seriously think of working on a decent set of editors and tools for OR.

I only use the consist editor to create entirely new consists having found editing an existing consist to be easier and I have already created entirely new consists only using a text editor.
Note, ALL cabview alterations I do are done the same way, ie using a text editor. This is one of using text files as config or definition files great strengths as its dead simple to edit them directly if one finds the existing tools to limiting or faulty in some way.

I personally do not see a problem of having the same shape across different items of rolling as I always treat different items as different. Treating different items automaticly in a similiar way from my experience being a true recipe for disaster.
I do not know about windows but in unix if two files are truly the same and need to be treated in the same one can always use "sim links", this is a file that simple points to another location where the real file lies. (In unix theres also a "hard link" this is a single file that has multiple directory entries).

Note 1: This install of MSTS is now entirely on Linux using wine as an windows emulator, this is because I have found MSTS's editor and tools are easier to use under wine on linux.

Lindsay

[markus_GE]

Lindsayts, on 08 June 2014 - 01:02 PM, said:

[...]

I do not know about windows but in unix if two files are truly the same and need to be treated in the same one can always use "sim links", this is a file that simple points to another location where the real file lies. (In unix theres also a "hard link" this is a single file that has multiple directory entries).

[...]

Lindsay

These are available too in WIN on an NTFS file sys.

IOW, a sym link is actually a file with kind of an Include statement towards another file, while a hardlink makes the file linked to show up in more than one place at the same time, right? Didn´t know these details...

Cheers, Markus

[Mike B]

Quote

Note 1: This install of MSTS is now entirely on Linux using wine as an windows emulator, this is because I have found MSTS's editor and tools are easier to use under wine on linux.

Thank You! I've been wondering whether MSTS & friends worked in Wine. Now all I need is to verify a few others (some old DOS programs, FSX, and ACD Canvas especially). I'm looking to move to Linux+Wine when Win7 is killed off.

-M

[Lindsayts]

Mike B, on 08 June 2014 - 02:47 PM, said:

Thank You! I've been wondering whether MSTS & friends worked in Wine. Now all I need is to verify a few others (some old DOS programs, FSX, and ACD Canvas especially). I'm looking to move to Linux+Wine when Win7 is killed off.

-M

One has far more control over wine than one does for any versions of windows. The registry for wine being all plain text, one can if one wishes under normal operation, ie not installing anything, stop wine from writing to the registry (the registry being a separate file one simply makes it read only).

MSTS was tried using wine 1.4, Tgatool 2a works also using wine, fcalc works directly under linux using mono. The linux command line for the later is "mono fcalc.exe".

Incidently just as a matter of interest Openrails was tried directly on Linux using Mono, it exited with a large number of errors indicating it could not find the registry.
This and the success of fcalc2 was VERY enlightening, while I will say any change in the direction of development will be challenging. In the future if a change in direction should be required. It would be worth looking at an OS agnostic approach using mono, it may be easier and work better than people think, Mono being a completely open approach to the whole C# XNA toolkit approach with much support and development effort going into it.

I am currently setting up wine to run as many MSTS's utils as possible. I will post a success/failure report in due course.

Lindsay

[Lindsayts]

markus_GE, on 08 June 2014 - 01:23 PM, said:

These are available too in WIN on an NTFS file sys.

IOW, a sym link is actually a file with kind of an Include statement towards another file, while a hardlink makes the file linked to show up in more than one place at the same time, right? Didn´t know these details...

Cheers, Markus

Thats correct, in unix the only way one tell a hard link exists is by looking at the number of directory entries a particular file has, see below in an extraxt from a directory listing, the number 2 after the permissions (the -rwxr-xr-x bit) and the two files are the same size indicate that both entries are in fact the same file.
If you to remove one of these files the 2 would decrease to 1 and the only thing freed on the disc would be a single directory entry.

-rwxr-xr-x  2 root   root      691140 Jun  2 23:38 avr-gcc
-rwxr-xr-x  2 root   root      691140 Jun  2 23:38 avr-gcc-4.8.1

Lindsay

[Genma Saotome]

markus_GE, on 08 June 2014 - 12:53 PM, said:

Just put you files fitted with includes in a sub-directory "Open Rails" (hope, that´s the right spelling) of the assets' original folder inside TRAINSET, and there you go: Include compatibility: check. MSTS AE compatibility: check. CB compatibility: check. Compatibility to almost any other program: Check (disregard DPU here, though - I´ll still have to think about how DPU can digest Includes - or if it will / should at all).

Hope that helps a little ;)

Cheers, Markus

Sounds like a real kludge but if it works, I'm gonna use it.

There are, IMO, still issues about naming & best practices that need to be worked out.

[cr-stagg]

Genma Saotome, on 08 June 2014 - 04:59 PM, said:

There are, IMO, still issues about naming & best practices that need to be worked out.

Just take a look at the "bag of worms" we already have with the "Include like" Sound and CabView alias statements. Every vendor has their own "common" Sound/Cabview folders. Some are subfolders of Trainset folder. Others are subfolders (or multiple subfolders) of the Trainset/common.SND or cab folders. And freeware creators and repainters are just as inconsistent as the payware vendors.

How will/does OR treat Include statements when the object file is missing? MSTS treats missing objects for Sound and CabView statements differently. That is Missing SMS files get an error message that can be ignored and the sim runs without playing the sounds. Missing Cabview files get an error message also but the sim crashes if you try to ignore or continue. Will/is OR programmed to treat missing Include statement object files differently? That is will these two Include statements, "Include ( XXX_Brakes.inc )" and "Include ( XXX_Description.inc )", be treated differently if the object file is missing? I should hope so.

What is the object of this endeavor? Are you trying to save HD space by not replicating common data? That couldn't be . Most (or maybe some) of us can remember when HDs cost $6.00/MB ($240 to $250 for a 40MB HD. I saw an add today for a 4TB HD for less than $200. That less than $0.00005/MB. Kind of like the reverse of remembering paying 27 cents a gallon for gasoline for my first car. HD space is cheap! My 240GB SSD I have for my MSTS/OR installation cost less than $100. So saving HD space cannot be the answer.

Is it to make a change to tweak the physics for all SD40s in your trainset by just making a change to one .INC file? If that is your objective, then even with "Naming & best practice procedures" you won't be changing just one .INC file. To back up this statement just consider how many WAV files you would have to replace if you found the "Perfect Horn" recording for a BNSF Dash9. Let's see the MLT Dash9 sounds are in ../MLT_Required/MLT_Sounds/ but then there are separate folders for CN and CP and NS and etc. Then for SLI there are SLI.Seligman etc, and for the repaints there are the ones in the many ENG folders where the sound folder from the DASH9 folder was copied, or the repaints where the creator had copied all the WAV files from the DASH9 sound folder in to the MSTS "global" Sound folder and you still wouldn't find them all.

I cannot see how Include statements improve anything. To me it makes ENG and WAG files more complicated than less complicated. Considering the cost of HDs today I see no reason to even use aliases for sounds and cabviews. Having all the pertinent files in the same folder or subfolder makes troubleshooting ENG and WAG file much easier.

[Lindsayts]

I am the originator of the idea of the current include function for the eng files, the objects being to simplify working on eng files over the entire system and make it easier to change the "physics" over the entire rolling stock fleet.
I have spent many many hours playing around with eng files and the original system leaves a great deal to be desired.

The current approach was adopted as it did not require a major effort on the part of the developers, this must be kept in mind. While it would be nice to rebuild the eng file parsing from the ground up that will be a seriously major task and it will be very unlikely to be done for sometime. The current approach while it could be much better is certainly MUCH (understatement) easier to work with.

Parsing problems,
All the include statements do is assemble the final file, parsing is not done until all the include statements have been read in so any errors are not generated until OR parses the final assembled file. OR does not do much in the way of error checking within an eng file (Note 1), what usually happens is the function simply does not work. I have been carefull in the way the eng file has been split up to make sure its easy (well easier anyway) to spot brace nesting issues.

Your example with the sound is not how it is done, if one wishes to change the sound what one does is simply change the "Sound" line in the eng file (there's usually at least two of them) from say

Sound ( Idonotlikethis.sms ) to

Sound ( Thisisgreat.sms )

If one wishes to play around with the overall sound scape this assumes much knowledge on how MSTS generates sounds and this goes well beyond any playing with eng files.

Note 1: The actual parsing is done in two major stages, the first stage breaks out the individual statements in the eng file the second stage is handled by the individual sources files that describe the function and exactly how much error detection is done depends on who has programmed each individual section.

Remember OR is being built by volunteers who are doing this because they like to, all the rest of us are along for the ride. One has to work with the developers, you can NEVER order a volunteer to do anything.

Lindsay