[Genma Saotome]

I want to write a blueprint for adding search tags to objects, stuff that describes the object but is not likely to be data used in-game. Some of the tags could wind up in .sd files, others in .wags or .engs, or possibly some new kind of file. Where it goes isn't part of discussion yet. I'm just researching what kinds of tag information would be useful.

I'm pretty comfortable laying out some ideas for static objects as well as US based rolling stock but have no idea how much of that would make sense in other countries. So this thread is intended primarily to collect information. All examples should be understood as intended to explain rather than specify how things should be coded in any files. I've also prefaced each tag with "Tag" to imply there is something there that can be used to locate tags... leaving the actual solution to the programmers

The first set of information that comes to mind is to identify who created the mesh and textures. Right now that's in the readme files but readme files can get lost.

So for ownership / IP data, the basics could be:

OpenRailsTags (
	IPTags (
		MeshTags (
			Mesh (
				TagMeshFile ( .s file name )
				TagMeshFileOwner( <persons full name )
				TagMeshLicense (Payware ! Freeware | Open Source )
			)
			repeat as needed
		)
		TextureTags (
			Texture (
				TagTextureFile ( .s file name )
				TagTextureFileOwner( <persons full name )
				TagTagTextureLicense (Payware | Freeware | Open Source )
			)
			repeat as needed
		)
	)
)

That allows for multiple mesh files going into one model as well as multiple textures.

Because many items are distributed as sets of models we could use include files to reduce the amount of redundant text. This example shows how many models could use an identical set of tags:

OpenRailsTags (
	Include ( <path><include file name.inc> )
)

where the include file would look like this:

Comment ( include file for IP Tags )
	IPTags (
		MeshTags (
			Mesh (
				TagMeshFile ( .s file name )
				TagMeshFileOwner( <persons full name )
				TagMeshLicense (Payware ! Freeware | Open Source )
			)
			repeat as needed
		)
		TextureTags (
			Texture (
				TagTextureFile ( .s file name )
				TagTextureFileOwner( <persons full name )
				TagTextureLicense (Payware | Freeware | Open Source )
			)
			repeat as needed
		)
	)

Because the include files are very flexible other groupings are possible.. an include file for all of the meshes and others for one or more texture files.


As for the tags themselves, it might make sense to add another for TagLicenseText(). I don't think there is a need for Copyright() because the ...TagFileOwner() and ...TagLicense() tags already address that.

Again, the whole idea here is to create a more firm link between content and who created it than is possible with a readme file as well as an aid to searching for stuff. Feedback?

[gpz]

 Genma Saotome, on 02 January 2015 - 11:58 AM, said:

Where it goes isn't part of discussion yet.

I think it is not possible to form an opinion without talking about where it goes. Because e.g. in collada and its derivatives like gltf, there is a dedicated place for copyright information. Please see the asset/copyright tag. So at least in case of the mesh file, writing this information also to our future eng file would lead to redundancy. (And I think I don't have to explain why it is a bad thing.) And in such a mesh file there is only a single tag available for adding this information.

[Genma Saotome]

There are a couple of possible locations for tags... some could go inside the mesh file, some could go as file property tags, others into ordinary files. For now I think just asking what are the tags that would be helpful is enough. Later on there can be another discussion to gain a better sense of what is the better technical solution -- and that might be a programmers-only discussion.
=============

Also, because I know James will want to know the answer, the problems I'm attempting to answer are:

Make it possible to find models w/o having to know their folder or file names, identify those characteristics that are used for building consists, being able to check distribution archives for license conditions (i.e., no payware) and to do so by

• Formalizing ownership assertions
  
• Standardizing search parameter names
  
• Placing search parameters in tight groups for easier reference

[Genma Saotome]

Here's what comes to mind for rolling stock:

OpenRailsTags (
	RollingStockTags (
		BasicForm ( Locomotive | Freight | Passenger | MOW | Multiple Use )
		CommonTags (
			TagStartYear ( nnnn )
			TagEndYear ( nnnn )
			TagOwner ( e.g., "Southern Pascific" )
			TagOwnerInitials ( e.g., "SP" )
			TagUnitNumber ( e.g., 2479 )
			TagPaint ( e.g., "Black Widow" | "Brown" | etc. )
			TagCommonName ( e.g., "F7" | Gondola | etc. )
			TagCountryOfUse ( e.g., U.S. | U.K | etc. )
			TagLengthRounded ( e.g., 40ft | 50ft | 89ft | 13m |etc. )
		)
		LocomotiveTags (
			TagBuilder ( e.g., EMD | Baldwin | etc. )
		)
		CarTags (
			TagTypeName ( e.g., XM | HT | RS | etc. )
			TagTypeCode ( e.g., A302 | B105 | etc. )
		)
	)
)

I think what's important here is creating some means to help distinguish one model from another by its appearance -- I'm suggesting start and end years as one means to bound an era of use and another tag for the paint scheme. That way we can find that GP9 in Black Widow paint w/o pulling up all those other GP9 models in some other scheme. Or alternatively select from a list of models that were around before 1955. stuff like that.

I've put basic names into TagCommonName() so simple descriptive names like Boxcar, Gondola, Coach, etc. have a place. I think this tag would appear in all cases. The specialization categories (i.e., AAR Codes like XM, HT and so on) are more arcane and so I've thrown them into a group of codes specific to cars. I'd use them but I figure not everybody else would.

Not all tags would be required... but for those that could be used I think I've got most of them.