Elvas Tower: Include file standards - Elvas Tower

Jump to content

Posting Rules

All new threads will be started by members of the Open Rails team, Staff, and/or Admins. Existing threads started in other forums may get moved here when it makes sense to do so.

Once a thread is started any member may post replies to it.
  • 6 Pages +
  • 1
  • 2
  • 3
  • 4
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

Include file standards Rate Topic: -----

#11 User is offline   espee 

  • Engineer
  • Group: Status: Active Member
  • Posts: 553
  • Joined: 09-January 10
  • Gender:Male
  • Location:Bridgetown, Western Australia
  • Simulator:Open Rails
  • Country:

Posted 20 November 2017 - 07:21 PM

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.

#12 User is offline   shadowmane 

  • Hostler
  • Group: Status: Active Member
  • Posts: 94
  • Joined: 27-November 17
  • Gender:Male
  • Location:Salisbury, NC
  • Simulator:Open Rails
  • Country:

Posted 27 December 2017 - 07:41 AM

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.

#13 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,307
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 27 December 2017 - 11:01 AM

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.

#14 User is offline   shadowmane 

  • Hostler
  • Group: Status: Active Member
  • Posts: 94
  • Joined: 27-November 17
  • Gender:Male
  • Location:Salisbury, NC
  • Simulator:Open Rails
  • Country:

Posted 31 December 2017 - 02:42 PM

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.

#15 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,307
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 31 December 2017 - 04:40 PM

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?

#16 User is offline   ErickC 

  • Foreman Of Engines
  • Group: Status: Contributing Member
  • Posts: 996
  • Joined: 18-July 17
  • Gender:Male
  • Location:Hastings, MN, US
  • Simulator:ORTS
  • Country:

Posted 31 December 2017 - 09:09 PM

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.

#17 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,307
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 31 December 2017 - 09:36 PM

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.

#18 User is offline   ErickC 

  • Foreman Of Engines
  • Group: Status: Contributing Member
  • Posts: 996
  • Joined: 18-July 17
  • Gender:Male
  • Location:Hastings, MN, US
  • Simulator:ORTS
  • Country:

Posted 31 December 2017 - 10:19 PM

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.

#19 User is offline   Lindsayts 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,849
  • Joined: 25-November 11
  • Gender:Male
  • Country:

Posted 01 January 2018 - 12:44 AM

View Postlongiron, 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

#20 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,307
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 01 January 2018 - 09:51 AM

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.

  • 6 Pages +
  • 1
  • 2
  • 3
  • 4
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users