[Genma Saotome]

cr-stagg, on 08 June 2014 - 07:01 PM, said:

What is the object of this endeavor?

To make it vastly easier to manage the values of my .wags and .engs. I replace almost every line in each downloaded .wag file I get. I'd much rather fix them by replacing 100 lines with 6 or 7, all of which are something.inc.

There are no reasons for any freight car I use to have unique values in the coupler() section, nor brakes(). I could be content with replacing everything that's weight based from a selection of a dozen standard files. Moving the text over to text.inc makes editing that easy too. Over in locomotives I fix every single light specification in every .eng. Having a single F7_Lights.inc makes that task trivial compared to what happens now. And on and on and on....

In short, I doubt the usefulness of almost every value in every .wag I get... and a fair number of values in every .eng. Include files make it much easier to install a fix.

[James Ross]

cr-stagg, on 08 June 2014 - 07:01 PM, said:

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.

To be clear, what should be happening is this: if an include points to a file that cannot be found, a warning is printed and everything continues.

Of course, if that include file defines something important, like Lindsay says, that thing will probably not work correct/at all.

If this is not what is currently happening (e.g. we're exiting with a fatal error) let me know and I'll fix it.

[Lindsayts]

James Ross, on 09 June 2014 - 12:31 AM, said:

To be clear, what should be happening is this: if an include points to a file that cannot be found, a warning is printed and everything continues.

Of course, if that include file defines something important, like Lindsay says, that thing will probably not work correct/at all.

If this is not what is currently happening (e.g. we're exiting with a fatal error) let me know and I'll fix it.

I'll do a specfic file not there test and see what happens. The include otherwise works like a dream.

Lindsay

[markus_GE]

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

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

[...]

It would be great to have some sort of cofirmation by a ORTS coder, if "Open Rails" really is the right name for the subdirectory - as I said, I know it´s possible, but I have never used it.

cr-stagg, on 08 June 2014 - 07:01 PM, said:

[...]

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.

[...]

Forget about saving HDD space with it. Assume every ENG file takes around 50KB of space, on average. Stripping out brakes, couplers, controls, physics etc. to external files would probably reduce the ENG file to, say 10KB, but you would have a bunch of extra files, common to one folder of ENGs (takes the most space) or a whole class of locos (less space). In any event, for any give TRAINSET folder with a reasonable (IE, non-collector like, so that you might give each item a spin at least once in your simming time) count of assets, you might maybe save 5 GB of space. OK, that´s more than most of my USB sticks have available as useable storage, but really, how "expensive" are they? ;)

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.

cr-stagg, on 08 June 2014 - 07:01 PM, said:

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.

[...]

These are two very good points, IMHO.

Personally, I think, we´d really need a predefined include convention that has to be stuck to, no matter what, by anybody, in order to keep things manageable. The Include statement seems to be a good step into the right direction, thought it still allows for creating a "mess". Personally, I´d only see it as an intermediate stage that allows for experimentation to find out what works best.

In the end, however, I guess it would be more practical to go along the lines of MSTS' CabView and Sound statements: Couplers should go into one (or more) general, type-specific ".cop" files, brakes to ".brk" etc. and would not be referenced with "Include" in the ENG file, but with "CouplerFront", "CouplerBack", "Brakes", etc. This way, everybody will have to work with a common structure used by everyone and known and understood commonly. It will be easier to find help, as not only the original creator knows about the file structure, and it will also be easier to identify bugs. All in all, it comes down to a fixed structure of different classes of files reference in the ENG file with a specifically named include command (instead of general "Include") being more manageable and maintainable.

In order to find this structure, however, the general "Include" statement probably is the way to go, since it´s more flexible. This flexibility, however, is what would make it a heck to work with if everybody can have their own include system, which is why this flexible approach, IMHO, is not suitable for general public use. Simply too much of a hassle.

Cheers, Markus

[James Ross]

markus_GE, on 09 June 2014 - 01:21 AM, said:

It would be great to have some sort of cofirmation by a ORTS coder, if "Open Rails" really is the right name for the subdirectory - as I said, I know it´s possible, but I have never used it.

I believe it is "OpenRails" (no space) for the OR-specific version of files.

[markus_GE]

James Ross, on 09 June 2014 - 01:25 AM, said:

I believe it is "OpenRails" (no space) for the OR-specific version of files.

I´ll try it out later today, probably in the evening. Will have to know it as to put it to use with my DPU program anyway ;)



Speaking of DPU, however, as it will evolve, it will also provide a means for easy maintenance of thousands of files, writing values from an easily changebale template to each ENG file passed through it, replacing existing values.

Anyway, DPU can (and probably will) be adapted to any change in how ORTS handles ENG files, with or without includes of any form.



Thus, thinking about the idea of classified include files (see above post: idea of .COP, .BRK, etc. files), I guess it would be good to have them in ome common place like e.g. "TRAINSET\Includes\<ClassNameHere,Like"Brakes"or"Couplers>\<files>". The subfolder "LocoClasses" (files e.g. .LOC) (this is just an idea, though) would, however, require various other subfolders, such as "Includes\LocoClasses\<builders,e.g."EMD","GE",etc.>\<LocoType,e.g."SD40-2","C30-7",etc.>\<files>".

The reason for giving each class of locos, and more generally, each type of include files a file-type specific folder is to have all files of a specific class/type located orderly in one common folder, but allow for files with variations to be added easily and without messing things up too much.

I guess that´s enough brainfood for now. Back to working for school now :)

Cheers, Markus

[Genma Saotome]

Because *.inc is parsed exactly as-if it was found inside a .wag or .eng there is no particular reason to use different file suffixes... think *.txt, *.xls, etc., etc. It doesn't matter that the content varies, only that the software understands one *.txt file is handled like every other *.txt file.

WRT a central \Include directory... I do not think that would be a good idea at all. Most include files are specific to a mesh file. Moving them away from that mesh file should be done with caution.

Consider: Say you have purchased a goodly number of Marc Nelson's F-units. You're likely to have them spread across a handful of directories whose names are probably based on the Railroad that owned them. I'll wager the vast majority of *.inc files for all of his F-unit models are going to be the same w/o regard to how the model is skinned... and only a handful would be relevant to some other set of F-units from some other modeler (e.g., couplers). If that is true, there is no particular benefit in moving the *.inc files for Marc's models too far away from their meshes.

What does make sense (IMO) is to have something along these lines:

3dtrains
	Std Include  <--- used by all models from 3dtrains
	EMD F3
		Std Include  <--- used by only by F3 models from 3dtrains
		Santa Fe F3
		Southern Pacific F3
	EMD F7
		Std Include  <--- used by only by F7 models from 3dtrains
		Santa Fe F7
		Southern Pacific F7

where the top level include is valid for all models from 3dtrains (this might be nothing more than credits); the include files for the F3 and F7 models are specific to the meshes for the F3 and F7 models.

What is different about the above is there are more directory levels than we have used in the past for \Trainsets. This is why I said earlier there are some pathing issues to deal with.

Taking freight models as a different example:

Tim Muir's Models
	Std Include  <--- used by all models from Tim
	Reefers
		Std Include  <--- used by only by Reefer models from Tim
		SFRD
			Std Include  <--- used by only by SFRD from Tim
			RR-40-29
				Std Include  <--- used by only by RR-40-29 from Tim
				Mesh
			RR-40-32
				Std Include  <--- used by only by RR-40-32 from Tim
				Mesh
	Boxcars
		Std Include  <--- used by only by boxcar models from Tim
		SP B-50-13
			Std Include  <--- used by only by SP B-50-13 from Tim
				Mesh
		SP B-50-14
			Std Include  <--- used by only by SP B-50-14 from Tim
				Mesh
		USRA DS
			Std Include  <--- used by only by USRA DS from Tim
			CNJ
				Std Include  <--- used by only by CNJ USRA-DS from Tim
				Mesh
			MILW
				Std Include  <--- used by only by MILW USRA-DS from Tim
				Mesh
			etc.
			etc.
		etc.
	etc.

That tree is even longer.

When you take in both of those examples you'll note that additional releases from those two modelers could fit right in, no problem. Where things get sticky is when reskinners step in with their own releases. IMO the solution to that issue is to find a proper home for those new skins and to do so requires either more pathing and/or a formal way to handle texture substitutions (e.g., using two parameters: OriginalTexture (oldname.ace), ReplacementTexture (new.ace)). But solving that issue is, I think, premature.


Returning to the complex directory trees shown above... IMO it makes more sense to do something like that as a formal library off to the side somewhere than it does to create it all within \trainset... largely because most people have (and will continue to have) multiple instances of \Trainset some of which holding identical copies of many items. I think it would be better for whatever is in \trainset to point to that library. Something along the lines of:

GS_SP_97345
	Wag1 points to entries in the standard library
	Wag2 points to entries in the standard library
	Wag3 points to entries in the standard library

Throwing copies of the directory GS_SP_97345 into multiple \Trainset folders is no big deal now because all of the real data is sitting in one place... in the standardized library. But again... the issue is pathing.

Anyway... this is all pushing well into foggy terrain; My point in raising it is to observe there is still a lot of unsettled issues here. What looks good today might look mediocre tomorrow. Ideas need to be kicked around (I'm playing around with the Library concept and am doing copy/paste of directories into \Trainset; so far it seems to be the best approach to deal with one model used many places that I've used).

[markus_GE]

My reason for proposing multiple file extensions, each specific to a certain type of include file, thereby describing it´s contents, comes from proposing to have rules along which include files are to set up. I proposed to do it similar to the CVF and SMS files of MSTS, just outside of specific assets' folders, in some sort of library.

Add to or remove from that library one or the other folder level (such as creator), my above example was just a proposal along which lines it could work. Maybe even move that library out of trainset, the only thing I wanted to propose with that is, to have all include files collected in one place (or it´s sub-directories) to keep managing and linking to them easy (easier).

Actually, what you propose in your above "code snippet" illustrations looks very much along the lines of what I proposed, just a little more elaborate. One point I´m not sure about, though, with your proposal: Do you want it to become a common agreement that this is the structure to be used for include files? IE, do you want to standardize what goes into which include file in which sub-directory of the central library?

I know it isn´t necessarily a good idea to move a file specific to one single mesh away from that file (and for such exceptions, the Include statement could well be kept in my above proposal), but since the point about include files was to have a change made to one file affect many, many models, I guess one should rather create a set of good generic include files that can be used for many models and that get their own file extensions in order to differentiate them from more specific include files, only common to a single folder inside trainset. IOW, my above idea would include brake setup files, coupler files, diesel / electric / steam engine class specific files and so on, that can be more or less applied to any item in your "fleet" (depending on an individual file´s property, of course). Thus, the 3DT F3 you mentioned could (and why shouldn´t) use the same diesel engine setup, coupler and brake setup as the TA F3 that might sit way down the TRAINSET folder´s content listing. Of course, different railroad companies might require to use files a little different, but I explained above how my system would cope with such variations.

I think I don´t quite understand what you mean with the "pathing issue". Could you please explain your point there? :curiousPC:

Cheers, Markus

[Genma Saotome]

markus_GE, on 09 June 2014 - 12:09 PM, said:

Actually, what you propose in your above "code snippet" illustrations looks very much along the lines of what I proposed, just a little more elaborate. One point I´m not sure about, though, with your proposal: Do you want it to become a common agreement that this is the structure to be used for include files? IE, do you want to standardize what goes into which include file in which sub-directory of the central library?

I doubt any standard will be developed any time soon, if ever. What I was trying to do was point out how different things could be when you start working with include files.

markus_GE, on 09 June 2014 - 12:09 PM, said:

I think I don´t quite understand what you mean with the "pathing issue". Could you please explain your point there? :curiousPC:

Sure. Lemme start w/ the existing problem: I have a 6-8 "installations" of MSTS. Some of them are copies of the original MSTS tree and others are stripped down in some way and so are OR specific. Almost all of them use a large number of the same .wags -- at first glance some appear to be identical; one is for testing before a release another is for development and a third is for my own enjoyment. What keeps each set unique is only the one for personal enjoyment has any payware in it and the testing one only has stuff in it that is being distributed. So none of those three are the same. Then there are others that have some duplication but not as much as the first three.

Given those facts there are a whole lot of duplicates all over the place and keeping them identical is a PITA. So is installing something newly downloaded (and cleaned up).

I describe this as a many to many problem: Each route has many .wags and each .wag can be found in many routes. Generally speaking many to many equals a lousy environment for managing data.

Enter pathing. IF the wagon data line in each consist allowed a path before the directory name it would be possible to have a single occurrence of all wags because no matter where the consist file is located it always points to the correct location where the .wag is found. Except consist files don't allow for that. They don't handle paths. And that I can a pathing problem.

Second aspect: I hate "..\\..\\otherdirectorystring\filename", especially when it's "..\\..\\..\\..\\otherdirectorystring\filename". A mnemonic works kinda like a nickname: "my_mnemonic\otherstring" where "my_mnemonic" is defined elsewhere is, IMO far more easy to use, read, and understand because its definition is in ordinary path format... what we all understand... and what can be defined as anywhere, including on another disk drive. If you look at the example .wag structure I posted earlier you'll see loads of examples where these dots and backslashes would go. IMO more is less.

I admit that's all a personal opinion rather than a technical one and in fact I do understand what it means and how it works... but that said it also bothers me when a technical person haughtily tells an end user not to be so ignorant it's actually very easy to understand blah, blah, blah, except for the fact the end user usually has many other things worth remembering and this technical mumbo-jumbo being forced upon him isn't ever going to be one. So why not spell it out so he can read it in words just like everything else?

There are other potential examples... If a mesh file represents a design (think class) and what you see in-game are instances of that design, what makes each instance different from another is how it is skinned and not it's mesh or it's include files. Given that it probably makes sense to be thinking of textures belonging somewhere other than the same directory as the mesh... think 3dtrains F7 has mesh & include files and somewhere else is Dave's Reskin holding my replacement textures. By what means does OR know where to find my textures? The answer seems to be a path is documented somewhere (where doesn't matter right now). Absent that path to the replacement textures you have reskins being done the MSTS way: everything is duplicated, given a different folder name, thereby perpetuating MSTS duplication of lots of identical files.

[markus_GE]

Now I understand what you mean by talking about pathing - actually, it was too obvious, or more poetically, I just couldn´t see the wood for the trees. ;) :curiousPC:

Also, this got me to understand you "library" idea differently: While I would eliminate just duplicate include files, you would eliminate all duplication and create a library for all WAGs and ENGs, instead of just INCs. I have never had the problem of many installs, since I dislike mini-route installs after one has wrangled up all my MSTS stuff once, but I definitely see your point.

Thus, we have been talking about two things, thinking we were talking about the same... anyway, they should be easy to combine: Give all these ENGs and WAGs a central library, where they can sit in there "asset" folders (as I like to call the highest level of sub-directories of TRAINSET) and let every one of them be made mostly of (preferably standardized in what is in them and where they are located) include files that reside in their own (sub)library.


On the question of standardization: It now stands 1 : 1 pro : con standardization of what goes into which include file, located where in a library. Thus, what do others think about it (ORTS devs, content devs, simple users who like to customize their stuff, etc.)?


Also, instead of standardization, one could go the way of "recommended practice", by not defining e.g. an include file with brake code only as a BRK file or a coupler-only file as COP, but letting them stay INCs in a specific subfolder of a central library. Probably less coding in ORTS required, but may be harder to see at a glance which line in an ENG / WAG means what. However, it still keeps a good deal of maintainability and "supportability" (if everybody knows how the folder structure looks on more or less any computer, it´s easier to help one another in case of problems) while being a little more "open" than my original proposal.

Comments?

Cheers, Markus