[espee]

From my experience when using FreightAnims; you must include the size line in the wag section, all my models failed if I included the size line in an include file. OR needs the size first before it knows where to place the FA's. Maybe my wag files are wrong ?

I then broke up the other data into include files.

Also the last line must be an include line else OR looks for a parameter or variable called sound or name... as you have done Sound and Name lines must be above an include line.

Australians just use AU in their folder naming convention, but if they are prime folders on your computer then maybe AUS would work.

[shadowmane]

Wow. I love this idea. I think, however, instead of (or in addition to), you should be thinking along the lines of manufacturer, not country. For example, EMD makes locomotives for multiple countries. For Europe, they make them with two cabs. For most other markets, they make single cab versions. You would simply break these engines down by manufacturer, given that they probably run on the same frame, only built in different ways, with different power. Is there any real difference, framewise, between an SD70ac and an SD70Mac? Yes, there will be slight differences, but those aren't enough to call for a new shape file. If going forward, the modelers would break the engines up into different parts that assemble upon rendering in the game, it would simplify the process. The same goes for just about any piece of rolling stock you can imagine.

So breaking it down by manufacturer, and by type (passenger, freight, intermodal, diesel engine, steam engine, etc.) would get you closer to where you want to be than breaking it down by country. North America basically uses the same stuff from Mexico to Canada with slight differences based on the needs of the customer.

I love this idea.

[Genma Saotome]

I think it might be adding too much complexity.

These are all reference files, not .eng and .wag files (or folders). There's no reason why a specific .eng could not refer to .inc files stored in a different country folder.

Something to consider: Not everyone is a locomotive enthusiast; Builder doesn't work very well for .wags.

I suspect what you would really like is the structure of my master library, where I put The One Official Copy of .eng and .wag files to be copied into mini-routes (either by symbolic link or old fashioned copy). In this Library I have done something similar to what you describe: Locomotives, Freight, Passenger are near the top of the tree, within each are lots of folders that separate gobs of .eng or .wag files into groups of similar features -- a folder for each type of freight car for example. I'll send you a PM with more specifics.

My point in mentioning this is it can be customized specifically to how the person thinks about his equipment roster. No two people need to do the same structure. I think you'd really like doing something like this.

[shadowmane]

Sorry, I got fixated on engines. That setup was wonderful. Thanks for the PM. I might be able to use it one day. As far as the include files, they would be in the individual stock file, correct? Or would they be somewhere else? And the shape files would be stored somewhere else. I think I'm starting to see a type of file system for OR shaping up here. You have the game itself. Then another set of folders for the shape files of common stock and engines. Then the route files with their specific engines linked to include files.

Here's a question that comes to my mind about the makeup of rolling stock and engine files. I assume you can use the same shape on multiple renders of stock. Why, then, do people create a shape file for every wagon or engine in the game? I've noticed this in dealing with files from trainsim.com. If you have the shape (.s) file, you have the shape for the piece of rolling stock. All you have to do is alias the ace files to the shape file and you're done. Or am I missing something? Perhaps you have to attach the .ace files to each .s file? I've not worked with re-painting rolling stock, so I don't know.

[Genma Saotome]

Second question first: The mesh file requires the list of textures and how the textures are applied to the mesh. Right now there is not an established way to provide a substitute list to deliver to the game software. Because of that the guy who makes the model has two choices: Make n number of folders, each holding files for one car or locomotive with all ofhte mesh files having an identical list of textures. The creator then creates several versions of whatever textures have the numbers on them, varying the art so each folder he has created has an identical list of files, all of them being pretty much identical, except for the one texture that varies per the value of the number it will display. There are a few extra tweeks needed for the .eng or .wag as well. His alternative is to return to the mesh file at it's source and use a uniquely named texture name for what holds that number and then save the mesh file with a u ique name. He repeats that for each of the different numbers he wants. In this case he needs only one folder. Everything that is shared across all of the .s files is present, no more than one of each texture file is needed... and whatever texture has to be unique is there using a unique name so there are several of those. Ditto for the .wag and .eng files,

Follow me so far?

Almost everyone prefers to make and distribute models using the first method and so that's what you see. BNy my own nature I tend to swim against the tide when I think it makes sense to do so and so when faced with a set of folders containing the same mesh by varying only by the car or locomotive number I sit down, uncoimplress the .s file and edit the name of the one texture that must be unique. I then same the mesh under a unique name and rename the one texture as well. Wehn I'm done doing that to everything in the set of folders I merge them all into one folder, usually renaming it to a class name (e.g., going from SP98475, etc, etc., where each folder identifies one car to a folder named GS_SP_B-50-11 where GS means drop bottom gon, SP is the railroad, and B-50-11 is the specific class that is modeled. Any reskins can simply be added to this folder.

I hope that makes sense.

Over to the first question (about where the include files go). The answer is a bit complex so let me start with the most simple case: Couplers. It is my opinion that most countries railroads would use only a handful of different couplers over the course of a century. For models of North America freight cars you could get by with numeric data representing just three different couplers fot the years between 1910 and the present. If that is correct, it makes no sense to repeat all of those lines in every .wag... far better to create three .inc files and record the three types of couplers that way and stick an Include() statement in the .wags. The question you asked is where do the .inc files go? I'm proposing a folder called common.fleet; to handle multiple countries I think it makes sense to add a handful of folders to that, each marked for where in in the world the car or locomotive was used, such as \common.fleet\USA. The individual .inc files for US equipment go there.

Any type of equipment that is utilized by the vast majority of .wags and .engs should also go there... so .inc files for brakes are a good candidate.

The there are lots of situations where it makes sense to create an .inc file for just a handful of .wags or .engs; From what I can tell this occurs frequently when one modeller releases a mesh textured for lots of different instances -- 12 locomotives lettered for the XYZ railroad and another 12 identical models textured for the ABC railroad. The solution I'm proposing for this case is to start with a folder called common.model and add sub-folders that describe what uses them. For example, \common.model\USA\3dtrains\F7 locomotives. This approach works really well for stuff from payware vendors.

The last situation is where nothing but the .eng and .wags of one folder are going to use the .inc file. IN that case put them with the .eng or .wag folder. I do this when I want different ladings... I'll set up multiple .wags that are uniquely named but are of the same freight car. Each of these .wags will reference a different .inc file where each .inc file is a different lading. Consider gondolas... you can get the same car number, one is loaded and the other isn't and there are several different types of loads that have been distributed. It makes perfect sense to leave the .inc file that holds all of the weight variable data in the same folder as the .wag itself.

Make sense?

[ErickC]

I think that, depending on the scope of the project, it could greatly reduce storage requirements where there will be multiple iterations of the same mesh, so long as we can come up with a way to reassign textures. 3D cabs add another layer of problem, though. The 3D cab, by default, uses its own unique set of textures located in the /cabview3D folder. If you insert a relative texture path into the shape, you can then tell it to load textures located anywhere you want, but I wonder how this will all work with a system where we can specify different texture folders for a single model. If I do an NS and an ATSF paint job on one model, what you see out the cab will be totally different (and there is no reason for someone like me to make 2D cabs anymore).

MSFS handled it by having the models in one subfolder, and a separate folder for the textures. The configuration file had a line that read "texture=" that sets a path to an alternate texture set. So if the line is blank, the game looked for textures in a folder titled "texture" . If the line said "texture=n331sw," for example, it would look for a folder named "texture.n331sw" .

I don't think such a system is necessarily applicable in this case, but it has good points that we might consider.

1.) The external and internal model are in one place. Anything that adds a relative texture path applies to both

2.) You can have a single model apply to all variations (this is our goal here with the common.model folder, I think)

3.) You can have a single set of physics parameters apply to many different repaints (useful for a fleet of identical equipment)

4.) FSX actually added a texture configuration file to each texture folder that gives the sim alternate places to look for textures. The upshot of this is that if I have a single image that is common to all models, I can put it in one texture folder, and then omit it from the others, and put a texture.cfg in each texture folder specifying the paths.

The FS system has drawbacks, though:

1.) We enjoy a much, much greater degree of flexibility. As MSFS matured, most of the physics data moved to the aircraft configuration file, meaning you don't have the flexibility we have where each .eng specifies its own model and whatnot and can be completely different, which allows us to have many different locomotives in a single folder (which greatly reduces clutter in the trainset folder).

2.) It's set up around a totally different system than we have.

I think it has some ideas that we might be able to appropriate, though. The big thing I think we can take from FS is the idea of configuring multiple texture paths. This ties in with the greatest strength of the MSFS system that set the standard for OR: we already set relative paths for things like sounds and cabview textures anyway. We can easily adapt the texture.cfg concept into the existing architecture. Let's say we create a new section for the .eng file that looks like this:

	ORTSTexturePaths( 2
						( Path "texture.1" )
						( Path "texture.common" )	
	)

Let's say that this is a locomotive, and that the external model mesh is located in the same folder as the .eng and .sd files, the 3D cab mesh is in a subfolder named cabview3D, the external model textures are in a subfolder named texture.1, and the cab-only textures are in a subfolder named texture.common. The paths would be relative, meaning they would work seamlessly with your way of putting things in a common.model folder. Let's say this section overrides all texture paths - 3D cab and freight shapes included - and tells the sim to look for textures in only those two places for this locomotive. The sim first looks for all texture folders in texture.1, finding most of them, it loads them. But it can't find all of them. So it falls back to texture.common, finds the rest, and then loads those. Let's say I do a repaint. Well, this repaint uses a different .eng file, and the texture paths look like this:

	ORTSTexturePaths( 2
						( Path "texture.2" )
						( Path "texture.common" )	
	)

This locomotive now uses the same meshes for the cab and external model, but loads an alternate set of textures for the external model (and the parts using the same texture names in the 3D cab). The sim can't find the cab textures in texture.2, so it looks in the other folder, finds the common textures, and presto! The problem is solved and the storage requirements have been reduced by several models and several texture files. We can now do everything they do in MSFS, but without the limitations imposed by the structure (I've long felt the MSTS system was more flexible and far superior, especially when we start talking about SMS files and the ability to specify paths). If we allow freight shapes to be superimposed over the 3D cab as well, we have some powerful methods available to us. The content creator can now create a bare-bones mesh for a locomotive body, put the portions of this bare-bones body that will be visible from the cab in the 3D cabview mesh, and then do road-specific details via freightanim. The sim loads textures from the paths set in the .eng file, so now each locomotive can have its own set of details, whatever unique textures the developer wishes, and still use a pool of common meshes and textures for the base model.

Rolling stock, similarly, could use one shape and multiple .wag files, with each specifying a texture path. If you wanted to attach a freight shape that resides in another directory, and has textures located there, no problem: just add that directory to the texture paths.

[Genma Saotome]

I proposed something similar to James (I need to poke around and find the url for you).

It all goes back to the KUJU design. I rather doubt much thought was given to how much content would be created by end users... a lot of what was delivered has a certain just-ship-it stench hanging to it. IMO the entire approach to .wags, .engs, and .con pretty much reeks.

For starters, there is no "law" that asserts a game object has to be the same bytes from womb to tomb. We should be able to take n .s files, put them into a collection object for placement via route editor, and have the game see them as the original n objects, each with their individual LOD's. Same for .wags: Give me mesh files for trucks, couplers, and brake gear and I'll make a mesh for the rest of the boxcar. There is no reason why the instructions for the assembly need to be repeated in every .wag so put it all into an .inc file and an Include() into the .wag and your done. Do another Include() that points to those textures used in common with many .wags and stick the unique replacement list into the .wag (e.g., the texture with the car number on it).

There are many ways to greatly increase both modularity AND reduce redundancy.


p.s. You mention the need for a certain amount of uniqueness. One way to do that is simply leave certain parameters out of the .inc file entirely. I do that w/ all exhaust parameters. Left in the .wag they're an open invite for people to come along and tweek values. For other matters we can simply take advantage of the fact that OR does not care how many occurrences there are of the same parameter, it'll simply use the value found in the last one it read. So if you wanted to change something about the power of a locomotive, regard the .inc file for those parameters as the default and just add into the one .wag the few lines you want to tweek. Just make sure to put them after the Include() statement that points to the default values.

[ErickC]

I was working on the base assumption that most developers were working from your idea. While I'd probably maintain my own hierarchy and folder structure for my own content, I think that for many users your method is a good way to manage things. I was just giving an example of how a set of texture paths within an eng file might look and how we might use such a method to solve a lot of problems (if your preferred method was to specify brakes, couplers, and so on in separate files and then use the include function to tie them all together in a minimalist eng or wag file, this would just be another small set of parameters in that file). I think that the flexibility offered here is tremendous, one who doesn't like dealing with physics could include lots of tried-and-true parameters from a default stockpile, one who prefers to do it all themselves can put it all in one eng file or their own set in their own set of folders. You'll find no disagreement from me on the methodology, my execution might just be different is all.

For many developers, even your idea of assembling whole models from standard component meshes would be useful. I semi-frequently upload source files for minor assemblies, a developer could do roughly the same thing while maintaining control of their source files with your method. If they used the idea of searching for textures only where specified, they could set the relevant texture paths so that no subassembly would necessarily be tied to one set of textures (or a common path could be specified for multiple pieces of stock to minimize storage requirements). The only real danger here is the problem of dependencies with respect to content using those other files, that is, files can disappear sometimes.

[Lindsayts]

longiron, on 20 November 2017 - 03:34 PM, said:

I believe "include" file standards are a good thing - but I'm very fuzzy on what's available for include and what's not. Perhaps some baseline is needed for those who aren't deep into this area yet.

Thanks

The parsing routines for text files(I cannot at the moment remember what OR call these) is general for all (almost?) text files, so one can use includes for anything that is repeated. Effectively the sky is the limit.
You do have to keep an eye on the order of the includes is in some instances OR expects a particular order. Another trap for new users is brace matching, You MUST use an editor that highlights matching braces.

Another thing to watch for is OR does not flag multiple definitions of the same parameter, it just uses the last one found.

The conversion process, changing a normal file to one that uses includes is a bit of a challenge, but one soon learns the ropes, and its such a HUGE benefit. For instance its great for getting such things as braking to be consistent throughout all the rolling stock.

Lindsay

[Genma Saotome]

What I've done to follow the safe path is to stick parameter lines into a specific .inc file based on the physical device being represented by those parameters. Meaning only the lines about couplers go into a coupler.inc file, only the lines about lights go into a lights.inc file. That gets you quite a ways along to achieving reusable blocks of data.

Where things get a bit more sticky are parameters related to weight and the physical characteristics of the model, to name two.

For the mesh, I'm placing parameters into an .inc file I called <name>_mesh_defined, where <name> is some descriptive label for the class (or design) of the model, stuff like SD-9 or USRA_SS. The parameters I put in there are not about devices but instead the whole model. An example:

COMMENT ( "PRR_X29_MESH_DIMENSIONS.INC" )

	Type ( Freight )
	Size ( 3.1m 4.6m 13.45m )
	WheelRadius ( 33in/2 )
	InertiaTensor ( Box ( 3.1m 4.6m 13.15m ) )
	NumWheels ( 8 )
	DerailRailHeight ( 4cm )
	ORTSTrackGauge ( 4ft 5.5in )	
	ORTSRigidWheelBase (5ft 6in )
	ORTSBearingType ( Friction )
	ORTSUnbalancedSuperelevation ( 6in )

When I'm done, a typical .wag file looks like this:

SIMISA@@@@@@@@@@JINX0D0t______

Wagon ( Sleeper106_Palm_Dome 
	comment ( Spec : ACF 10-6 Sleeper )
	WagonShape ( Sleeper106.s )
	FreightAnim ( "Sleeper106_Palm_Dome.s" 1 1 1 )
	Include ( "..\\Common.Fleet\\USA\\Std_Type_H_Coupler_Generic_Draft_Gear.inc" )
	Include ( "ATSF_Super_Chief_Palm_Sleeper_Mesh_Dimensions.inc" )
	Include ( "ATSF_Super_Chief_Palm_Sleeper_Weight.inc" )
	Include  ( "ATSF_Super_Chief_AC&F_Sleeper_Lights.inc" )
	Include ( "..\\Common.Fleet\\USA\\Std_Single_Pipe_AB_1_B_Brakes.inc" )

  	Sound (	"GenFreightWag1.sms" )
	Name ( "PS - ATSF Palm Dome 10-6" )
)

The above car came in a payware set and there are a dozen or so similar cars in the one folder. Because I do not expect to see the same mesh reskinned for other railroads it made sense to me to leave the .inc files I created in the same folder as teh .wags. The two exceptions are for couplers and brakes which belong in the common.fleet folder, just as you see above.

[shadowmane]

Wow. You guys do much more tinkering with physics than I do. For me, if the train just goes where I want it to, I'm doing well. I've never driven a real train, so I have no frame or reference on how it's supposed to "feel" to operate it.

[Genma Saotome]

shadowmane, on 01 January 2018 - 10:04 AM, said:

Wow. You guys do much more tinkering with physics than I do. For me, if the train just goes where I want it to, I'm doing well. I've never driven a real train, so I have no frame or reference on how it's supposed to "feel" to operate it.

IMO the stuff that is most commonly wrong in stock MSTS files is the Friction() data. Get that corrected and you'll be about 75% of the way to pretty darn realistic. I'd guess brake data would be number two in the list to examine and as needed fix.

[shadowmane]

I would love to see your system setup. I read over at Trainsim how you did it from a post put up a little over a year ago and it's opened my eyes. But I'm still wrapping my head around it. If I could see the complete filesystem setup with all of the folders and subfolders it would really help me. I'm still struggling to set up a mini-route without using Route Riter. I know it can be done by copying some files into the four folders, but I'm not clear on what is needed. I know some of the older routes I use need the MSTS files, but I'm not clear on which ones. I know the /Global folder is important, but I don't want to copy all of the files from MSTS when they aren't needed. I know those files are important for the routes that have the install batch file.

I've primarily stuck to some of the older fictional routes. Fantasii makes my system struggle, as does LIRR. Zigzag is pretty much useless to me at present. I saw how some of you have the game set up with all of the routes in one folder, and all of the rolling stock in another folder/subfolder setup with other files pointing the game to those folders. I would love a system like that for myself, but I have a lot to learn just about aliasing engine and wagon files.

[Genma Saotome]

In reply to Gerry's comments here, some additional generic thoughts that would be off topic in his thread.

Gerry, good to see you are still pushing thru stuff.

WRT \common_OTRS, I don't see any need to designate any folder with OR or ORTS when it is only Open Rails that will make use of it. It's sort of redundant in the same way \Trainset_msts would have been redundant in 2001.

Were the common.snd and common.cab folders a KUJU idea or did the come from the community? At any rate when I started to fiddle w/ include files my central repository went thru several name changes, much as you have seen in your own work, and finally turned to common.something as it seemed to make good sense so I think "common." is a good convention to follow (IMO including the dot) -- looks like you mostly agree too, but what is the best word to use for what follows???

I picked common.fleet only on account of the word fleet suggesting something rather pretty universal to most everything in \trainset but perhaps it is not the best choice. Is there a better word to use? Common.Roster perhaps? Common.Equipment? That might be better... how does Common.Component sound? That gets to the heart of it but I'm not sure it would be grasped as quickly by others. Do you have any suggestions?

I note your use of \Locomotive. I've thought about that too... it's really tempting. If we go with that perhaps it would be better to use an abbreviation - \Loco; I know folks are used to the string "eng" but truth to tell that big machine we see rumbling down the tracks is not an engine, it's a locomotive -- the engine is inside the locomotive (and in the old days was the cylinders and coupled driving wheels). We don't call automobiles engines -- look at that Ford engine taking that corner! -- let's not call locomotives engines either.

I've not received much feedback on my ideas of using country codes as an organizing method... perhaps it is not needed after all. Further thought on my part leads me to consider I'd probably be doing unique mini-routes for different countries in which case it would be pretty automatic to achieve the same organization I was thinking about... I expect others would do so too... another reason to drop it. Any thoughts on that?

Last topic: \common.fleet with or without \common.model; I did not start out with \common.model... everything went into the \common.fleet folder. It quickly became apparent the major issue with this related to distribution, not storage. What does one do when you have identical classes of locomotives from multiple people, each with their own ideas about what values to use in their .eng or .wag files? How do you keep an updated set of files from one guy squashing that the other guy did? What to do with stuff you have edited yourself? That led me to use folder names like "\SD-7 from BLW" (and as you noted the PW people could be doing their own thing, something like "\BLW\SD-7"). Point is there could quickly be a lot of these folders. After trying several approaches I settled on this concept: \common.fleet would hold only .inc files that either the community has accepted as the best on offer... or that I, for my own files, have designated best IMO. Everything else... all that stuff we leave alone, etiher because we don';t know a better answer, don't care, or just havn't got around to editing, all that stuff, isn't the best on offer and so it belongs in a different folder. At first I thought all those files will stay in the same folder as the .wags or .engs that use them and that worked until I took on Tim Muir's USRA cars. LOTS of the same car design from one guy spread across LOTS of individual folders. I concluded I needed to try something different for Tim's car's -- \common.model and quickly concluded it would be a good solution for many payware models as well.

So I do think there is a need for (at least) two \.common folders: One holding .inc files that are understood to be the best values you will use, really which means not too many folders, and a different \common. folder to hold all the files for one mesh file that have been skinned many different ways... and include the modelers name because some other modeler may be distributing his own mesh files for the same thing (think EMD locomotive models).

WRT further dividing the \common folder(s). Rather than use country codes I suppose one could divide them up with \Loco and \Car... or \Loco, \Freight, and \Pass tho perhaps that's too many. Thought son that?

[Metro4001]

Question gents. I downloaded the Tyler Bundy Paducah Geeps and they are TOP DRAWER stuff. However, they have an Open Rails folder with an include .eng file. There's not much documentation regarding the folder or it's content in the read me so I initially replaced the MSTS .eng files with the OR files. After getting an error in DPU I realized that these files were supposed to supersede only certain aspects of the MSTS .eng parameters and were to remain in the OR folder. However, it seems that OR is reading both files and that has caused issues when dealing with the exhaust. My geeps are smoking way too much. And I changed the color on one of the SW switchers as a test but it still spewed black smoke. How is the OR diesel block supposed to work? Do we need to delete certain MSTS parameters in the original file so OR won't read them any longer?

Also can the OR diesel block exhaust parameters be explained a bit better? Does the idle setting account for both smoke rate and magnitude? What are exhaust dynamics? Transient color? If this is already existing documentation could someone kindly point me in that direction?