[Genma Saotome]

Would there be any harm to either MSTS or OR to append a (reasonably) standard set of metadata to .wag and .eng files?

Something along these lines for everything:

BuilderName( string )
DateAcquired ( YYYY-MM )
DateRetired ( YYYY-MM)
PaintScheme ( string )
DatePaintIntroduced ( YYYY-MM )
DatePaintReplaced ( YYYY-MM )
UnitNumber ( int )
UnitNumberPrefix ( string )
UnitNumberSuffix (string )

with (perhaps) additional metadata specific to different types of rolling stock, for example for locomotives:
BuilderModelName ( string ) <--- e.g., SD-9
OwnerModelName ( string ) <--- e.g., Cadillac
OwnerClassCode ( string ) <--- e.g., EF-5

for freight cars
AARClassCode ( string ) <--- e.g., XM
OwnerClassCode ( string ) <--- e.g., X29

and so on.

Obviously there will be differences from one country to another and perhaps from one era to another but there should be a core set that is applicable to the vast majority of things. The more arcane, country specific metedata can get defined by those who know what's of use and then go along for the ride, so to speak.

Can it be done?

[EricF]

Since we know that MSTS ignores unknown text in .eng/.wag files as long as they don't cause open parenthesis errors, adding a metadata shouldn't be a problem. It will just need a standard format so Open Rails knows what to do with it.

I tested on the default Dash9.eng file -- Between the "Description" and "EngineOperatingProcedures" I added a new section named "ORTSMeta (" , dropped a few dummy text lines below by copy-pasting your suggested ones, and closed the parenthesis on the following line. Launched the default Marias Pass route with the modified Dash9.eng and a default consist in explore mode in MSTS -- it ran fine, no errors as expected. OR didn't care either, with the same modified .eng file.

I like the idea. Now if we could come up with a standard metadata format, it could open the way to create a standardized format for equipment data -- whether for displaying information, or supplying OR with references that could affect the simulation. If sufficiently standardized it could also be used by third-party tools in a predictable way. Interesting.

[Genma Saotome]

EricF, on 26 July 2016 - 03:50 AM, said:

Since we know that MSTS ignores unknown text in .eng/.wag files as long as they don't cause open parenthesis errors, adding a metadata shouldn't be a problem. It will just need a standard format so Open Rails knows what to do with it.

I tested on the default Dash9.eng file -- Between the "Description" and "EngineOperatingProcedures" I added a new section named "ORTSMeta (" , dropped a few dummy text lines below by copy-pasting your suggested ones, and closed the parenthesis on the following line. Launched the default Marias Pass route with the modified Dash9.eng and a default consist in explore mode in MSTS -- it ran fine, no errors as expected. OR didn't care either, with the same modified .eng file.

That's right, but I think it's wise to run the idea past the OR team before proceeding.

EricF, on 26 July 2016 - 03:50 AM, said:

I like the idea. Now if we could come up with a standard metadata format, it could open the way to create a standardized format for equipment data -- whether for displaying information, or supplying OR with references that could affect the simulation. If sufficiently standardized it could also be used by third-party tools in a predictable way. Interesting.

It shouldn't be too hard. A header, such as you suggested with "ORTSMeta (" isn't technically necessary but is useful for purposes of keeping things from being scattered all over.

As for why I think something like this is needed, all we've got now is whatever gets put into Name(). That field quickly gets overloaded. So all I've done in the first post is list a bunch of metatdata that I would like to use when searching for something. I have an editor that does wildcard searches on sets of files and the people who do coding for consist editors could do something similar for their products. So long as it's reasonably standard stuff they can look into -- BuilderName(), PaintScheme(), Owner() alone would let somebody look for Alco, Tiger Strip, Southern Pacific and get a list of a dozen models instead of hundreds.

Eric, do you have any thoughts on useful metadata fields that I missed?

[EricF]

Dave, your suggestions for metadata fields are excellent for categorizing equipment -- particularly for building consists and cataloging stock.
For operational purposes, you could add categories such as Refrigerated cars (Iced/Mechanical) <- String value

Metadata fields could also be used by ORTS to set parameters which might affect how it behaves -- for instance:
MSTS legacy stock (yes/no)
Air Brake equipment type (24RL, 26L etc. for US types; European types would need to be added)
Bearing type (Roller/Friction) <- String value
Brake Shoe Type (Cast iron, composition etc.) <- String value

All things that could also be incorporated into improved OR file formats, but it could be useful to allow for a few simple additions in structured metadata to "clue" OR onto how to handle some broad aspects of MSTS legacy files. It could enhance backward compatibility and set broad performance/behavior characteristics with a relatively few simple, structured values.

At the very least, it kind of opens a way of thinking more about how to design the configuration files in the future.

[Genma Saotome]

EricF, on 26 July 2016 - 01:25 PM, said:

Dave, your suggestions for metadata fields are excellent for categorizing equipment -- particularly for building consists and cataloging stock.
For operational purposes, you could add categories such as Refrigerated cars (Iced/Mechanical) <- String value

Metadata fields could also be used by ORTS to set parameters which might affect how it behaves -- for instance:
MSTS legacy stock (yes/no)
Air Brake equipment type (24RL, 26L etc. for US types; European types would need to be added)
Bearing type (Roller/Friction) <- String value
Brake Shoe Type (Cast iron, composition etc.) <- String value

All things that could also be incorporated into improved OR file formats, but it could be useful to allow for a few simple additions in structured metadata to "clue" OR onto how to handle some broad aspects of MSTS legacy files. It could enhance backward compatibility and set broad performance/behavior characteristics with a relatively few simple, structured values.

At the very least, it kind of opens a way of thinking more about how to design the configuration files in the future.

All good points, Following up on your suggest of MSTSLegacy() all sorts of ideas surface... perhaps things like PriceTerms ( Payware ! Freeware ), MeshCreator ( names ), ArtworkCreator( names ), DownloadSite ( home page url ) would be of use. I'd make use of PriceTerms ( Payware ! Freeware ) when selecting things for inclusion in a consist file I wanted to distribute. I dunno the next the are really useful in .wag or .eng files. But being just ideas, sure, toss 'em in the pot and see if they make it tot he end of the process.

You mentioned a couple of ideas for stuff that's already present (or could be inferred from) the .wag and .eng data. I don't find that objectionable but I do think it's worthwhile to think about its utility. Is the purpose of the metadata to document the model or to provide the most useful information for searching? One could make a case either ways on that. For myself, I'm fond of information and so left to my own I'd probably create too many metadata fields. Somebody else who just values some extra help in search isn't going to value the extra nor will he be willing to document the extra when he releases a .wag or .eng. So perhaps the old advise of "less is more" applies here.

[Jovet]

I would vote for a group be called Metadata that encompasses all of this information.

[cr-stagg]

To add to EricF's suggestion: I have begun adding a Symbol to the Name line of Engines made for or modified for ORTS. * for textures that won't display in MSTS. $ for 3dCabview. @ for ORTS engine folder. Having a Metadata entry for these things would improve the ability to sort rolling stock. Perhaps a "Compatibility" entry could be required where a value of 0 = MSTS only, 1 = ORTS only and 2 = MSTS or ORTS. A value of 2 would require an ORTS engine folder for separate physics. With such a field CEs could be modified to filter based on that Metadata.

[Genma Saotome]

Charles, per your suggestion:

Compatibility (
	UseInOR ( string )  <---- { Y | N }
	UseInMSTS ( string )  <---- { Y | N }
	NumPolys ( Int )
	DefaultTextures (
		UsesAce ( string )  <---- { Y | N }
		UsesDDS ( string )  <---- { Y | N }
		All2^nSquare ( string )  <---- { Y | N }
	)
	CabView ( string )  <--- { 2D | 3D }
)

The thinking behind the UseIn...() pair instead of a single numeric value is to avoid the complexity that would occur if there were more than two choices. With only two choices you need 3 values. For three choices you need 7 values. For four choices, well, a lot of values. I'm not saying there will be lots of different sims but it might come to pass that different versions of OR introduce compatibility issues. If that were to occur it would be easy to add more Usein...() lines than to expect people to grasp a single number covering all the possible combinations (think ESD_AlternativeTexture() as one such example).

The meaning behind the word Default in DefaultTextures is to say this is what the mesh file uses. I've long been pushing for the ability to assign replacement textures. As all we know today is what the mesh has I include that and leave all metadata related to replacement to be defined at some future date. Perhaps using Original or perhaps Mesh are a better choice than Default.

I do have some reservations about using some of the above. For example, if you have UseInMSTS ( N ) then of what use are the polys, textures, and cabview parameters WRT compatibility? The may be useful as general search criteria but I question whether there is a need to list all the possible ways an OR only file lacks compatibility with MSTS. IOW, I think

Compatibility (
	UseInOR ( string )  <---- { Y | N }
	UseInMSTS ( string )  <---- { Y | N }
)

is sufficient, with the others existing elsewhere (where they may be subject to further discussion of utility).

Your thoughts?

[conductorchris]

Perhaps Goku and conbuilder would add to their consist editors the capability to search these fields, which would make finding stock for consists much easier.

Having metadata fields could set the stage for activities and consists that have random engines and wagons based on a criteria. That could be pretty cool.

With that in mind, it seems important to have fields for commodity (load) and/or load/empty.

Other metadata fields I could imagine useful are: author and/or source

And I didn't see Railroad (ie, reporting marks) as a field - that seems basic.

Some simplifications:
- condense the dates for acquired, retired, paint into one date range
- Change "BuilderModelName, OwnerModelName, OwnerModelCode" to "class" and add a "builder" field

Personally I would really love to see a date range included in metadata since I see a lot of screenshots that show errors in this regard.

Putting everything into a metadata area would allow anyone to put in any metadata field, although it would be good to have standardization as much as possible. It would also make it so the consist builders can just search for any term in it (like tags) or choose specific fields to search.

Christopher

[cr-stagg]

Seems to me that an activity creator or even a casual user would not be interested on why or why not an item was compatible but would be interested in whether or not it is compatible. Beyond that knowing that the item had ENG/WAG files with physics written for the particular Sim would speedup selection of which items to use. Knowing that a 3dCab view while slight useful would not be necessary.

Some recent discussion about "new releases" by a vendor and repaints by some users has me shaking my head at what some are calling "MSTS & OR Compatible". I find that NO effort has been made with the ENG files to incorporate ORTS. None of the installs are provided specifically for one sim or the other and none are using the OpenRails folder for a second ORTS only ENG file. Except for those with DDS and ACE files these releases are no more "Compatible with OR" than add-ons created 10 years ago.

But what can you expect when a repainter uses a GP30 to create a GP39 and does not update anything in the ENG file except the Wagon and Engine lines and the Shapeview line and even leaves the Description section saying GP30 with the specs for a GP30 rather than GP39. Then uploads it calling it an MSTS/ORTS engine.