Include file standards
#11
Posted 20 November 2017 - 07:21 PM
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.
#12
Posted 27 December 2017 - 07:41 AM
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.
#13
Posted 27 December 2017 - 11:01 AM
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.
#14
Posted 31 December 2017 - 02:42 PM
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.
#15
Posted 31 December 2017 - 04:40 PM
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?
#16
Posted 31 December 2017 - 09:09 PM
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.
#17
Posted 31 December 2017 - 09:36 PM
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.
#18
Posted 31 December 2017 - 10:19 PM
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.
#19
Posted 01 January 2018 - 12:44 AM
longiron, on 20 November 2017 - 03:34 PM, said:
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
#20
Posted 01 January 2018 - 09:51 AM
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.