[Genma Saotome]

>Perhaps you could pen a section for the manual on how you set this up?

This thread describes what I was doing at the time. I expect today it is slightly different but not significantly so.

[Goku]

thegrindre, on 03 April 2017 - 12:41 PM, said:

There is one thing I'd be interested in and that would be a small graphic profile from the shape file for display.
I'm not so fond of Convoi's method (Takes up too much room on the hard drive) but at least something to look at, anyway.

Today's computers are so fast, that I think it is better to always render shapes in realtime, like TSRE Consist Editor do, instead of saving shape images on the disk.

[thegrindre]

Sure, doesn't matter to me. Convoi uses bitmat images and that takes up hard drive space so another way is fine IMO.

http://www.elvastower.com/forums/public/style_emoticons/default/oldstry.gif

[Eldorado.Railroad]

Trying to be upbeat about this is going to be hard, but I will try!

There have been others who have created consist editors, and sadly either they are payware with a terms of service that I do not want, or the creators have added to the list of abandonware without source code.

At least OpenRails is supposed to outlive us all. The code is still there to compile, if the tools to compile them are still around.

Some ideas have been centered around databases of sorts, but the creation of those databases and how they "look" has always been a bit of a conundrum. We are going to have to settle on some kind of key, yes that kind a key, the database kind, maybe even multiple keys. When your collection of wagons and engines goes well past 1000 finding things is a problem. There are numerous .eng and .wag files out there from various sources, payware or otherwise, that all have "their own ways" of doing things. A user ends up having to edit every .eng/.wag file to conform to some kind of "standard" so that you can find things. This is a huge PITA.

The consist editor, MUST accommodate long names, explicit ones. The consist editor MUST allow for various font sizes too, one size cannot fit all. I speak from experience here. The level of frustration and compromise on having to re-edit .eng/.wag every time you realize that you cannot use more than X characters is a major PITA.

In a very short list and not conclusive, you will have to deal with dead engines, loaded and unloaded wagons, etc. All of these need to be clear to the user, somehow. I agree with Goku, a selected piece of rolling stock should be immediately (well within reason) visible. As a sidebar, for the longest time, I have wished for OpenRails to have its own shapeviewer, that understands, non square textures, DDS textures, etc. Other things like random consist creation are also very handy to have.

The proof will be in the pudding, I hope I can signal the shortcomings in the beta of this idea, once it is released.

Thank you for undertaking this challenge, along with a good activity editor, it is crucial.

[Genma Saotome]

Many interesting points made in the previous post....

Eldorado.Railroad, on 09 April 2017 - 08:15 AM, said:

Some ideas have been centered around databases of sorts, but the creation of those databases and how they "look" has always been a bit of a conundrum. We are going to have to settle on some kind of key, yes that kind a key, the database kind, maybe even multiple keys. When your collection of wagons and engines goes well past 1000 finding things is a problem. There are numerous .eng and .wag files out there from various sources, payware or otherwise, that all have "their own ways" of doing things. A user ends up having to edit every .eng/.wag file to conform to some kind of "standard" so that you can find things. This is a huge PITA.

Years ago I argued on behalf of using a dbms to solve all of the unmanaged relationships between track and intereactives but it was far too early in the project for anyone to care about. Perhaps it'll return as a point of serious conversation.

The big problem here is not database design or the applications used to put in or take out information, it's what happens when the end user does something (or his PC does something) and the integrity of either the database or of rows in the database is broken. I don't know of any good way to help him out of the jam he will be in.

But for those willing to take the risk -- probably a rather small risk -- using a database as a repository from which either flat files are produced or is accessed by the OR code, a whole lot of issues would be successfully addressed, from proper referential integrity for interactives to 3rd normal form for creator-attributed versions and their revisions of content like .engs and .wags.

Eldorado.Railroad, on 09 April 2017 - 08:15 AM, said:

The consist editor, MUST accommodate long names, explicit ones. The consist editor MUST allow for various font sizes too, one size cannot fit all. I speak from experience here. The level of frustration and compromise on having to re-edit .eng/.wag every time you realize that you cannot use more than X characters is a major PITA.

Which argues for display windows that can be expanded or shrunk as needed.

The fundamental issue here is absent complete management within a custom application, one that presents you with all the metadata you need (thereby allowing the file name to be both hidden from view and probably just a serial number), we're going to put a lot of that metadata into the filenames: Road initials, unit number, type of unit, overall appearance of unit, optional but important features (like a white extra flag), and date range within which the model, in this appearance, was used. Or as they say, a real mouthful: "WP F7A #913 Silver small letters extra 1950-54"

Eldorado.Railroad, on 09 April 2017 - 08:15 AM, said:

In a very short list and not conclusive, you will have to deal with dead engines, loaded and unloaded wagons, etc. All of these need to be clear to the user, somehow.

IMO there is a need for some conceptual re-thinking: Take the mesh file and call it a class from which a variety of subtyped objects can spring, each of which get defined as individual game objects ahnd you solve lots of problems. For example, take a mesh for a particular U.S. diesel locomotive: A EMD SD-40. One file. Now add a subtyped variant: the skins it will display (yes, I know those are defined in the mesh but here I'm speaking of what the OR software will actually display. One mesh, many sets of skins, varying by railroad, railroad paint scheme, unit number, etc. etc. Maybe hundreds of variations. Yet there are a whole lot of data parameters specific to the mesh rather than any one variant, in fact, the majority of data parameters are probably true for the mesh. One mesh, one set of data parameters, many variants each with their own list of skins. What the game needs is a copy of all of that for each displayed loc0omotive. What the user should have on his PC is one mesh file, one set of data parameters (there may be multiple files here because a lot of the data is actually common to a lot of different locomotives -- think couplers), and a big bunch of tiny files listing the skins... and maybe a lot of metadata too. Reskinners then distribute only the last kind of file. End users would no longer have to put all of those reskinner files in separate directories -- they could have a single folder labeled UP "SD-40" and have 100 reskinning file sin there instead of having 100 folders labeled UP SD-40 6001, UP SD-40 6002....

IOW .eng and .wag files as we know them would be obsolete and the number of folders in \trainsets would be reduced considerably. The original mesh file and all of those data parameters could be read whether the game object was going to be a UP skinned SD-40 or a Santa Fe SD-40, or any other railroads SD-40. Who knows, maybe they get stored in a directory called Mesh Files and the convention is to mark everything their with the creators name -- "Barry_Munro_s_SD-40". If we're lucky, that'll be a folder name and it will contain an assembly file to points to as many individual mesh files as are needed to make up a whole locomotive. Meaning physical variants are dealt with here. What this really doess is it make the physical nature of the model wholly independent of its skinning and assigns most of the data parameters to the physical model. One model folder set off tot he side, many reskinning files placed into \trainsets, each of which is so tiny who cares about the cost of doing a copy/paste everywhere!

Eldorado.Railroad, on 09 April 2017 - 08:15 AM, said:

As a sidebar, for the longest time, I have wished for OpenRails to have its own shapeviewer, that understands, non square textures, DDS textures, etc. Other things like random consist creation are also very handy to have.

IMO Shapeviewer needed to be replaced at least 8-10 years ago. The graphics are bad, the displayed area far too small, and having one, permanent point for rotation is no good at all for anything larger than a small locomotive or car.

The only really insightful thing Shapeviewer does in the hierarchy window -- it shows the draw counts.

[espee]

Quote

IMO Shapeviewer needed to be replaced at least 8-10 years ago. The graphics are bad, the displayed area far too small, and having one, permanent point for rotation is no good at all for anything larger than a small locomotive or car.

Agreed on most points, but... if you hold down the CTRL key then you can mouse around to any point for rotation.

[conductorchris]

The database approach was used by the Yardmaster consist editor, although of course it was grafted on top of the MSTS way of doing things. In the end, I found Goku's good search functions to be easier to use than a database. I think this suggests some kind of hybrid - a search engine that searches across a lot of fields (accommodating users who break their data and also legacy content) and probably defined fields that are part of the .wag file to encourage content creators to be sure that information exists in the first place.
Christopher

[James Ross]

Eldorado.Railroad, on 09 April 2017 - 08:15 AM, said:

Some ideas have been centered around databases of sorts, but the creation of those databases and how they "look" has always been a bit of a conundrum. We are going to have to settle on some kind of key, yes that kind a key, the database kind, maybe even multiple keys. When your collection of wagons and engines goes well past 1000 finding things is a problem. There are numerous .eng and .wag files out there from various sources, payware or otherwise, that all have "their own ways" of doing things. A user ends up having to edit every .eng/.wag file to conform to some kind of "standard" so that you can find things. This is a huge PITA.

I would suggest that the database goes with the new content structure (content manager, etc.) more than the consist editor itself, but we definitely want people to be able to find their content!

conductorchris, on 10 April 2017 - 06:27 AM, said:

The database approach was used by the Yardmaster consist editor, although of course it was grafted on top of the MSTS way of doing things. In the end, I found Goku's good search functions to be easier to use than a database. I think this suggests some kind of hybrid - a search engine that searches across a lot of fields (accommodating users who break their data and also legacy content) and probably defined fields that are part of the .wag file to encourage content creators to be sure that information exists in the first place.
Christopher

This sounds roughly like what I have been considering, i.e. we load up a bunch of fields (including any metadata fields we add), and do a minimum of simple text keyword matching on the whole lot.

Eldorado.Railroad, on 09 April 2017 - 08:15 AM, said:

The consist editor, MUST accommodate long names, explicit ones. The consist editor MUST allow for various font sizes too, one size cannot fit all. I speak from experience here. The level of frustration and compromise on having to re-edit .eng/.wag every time you realize that you cannot use more than X characters is a major PITA.

Genma Saotome, on 09 April 2017 - 12:29 PM, said:

Which argues for display windows that can be expanded or shrunk as needed.

I am not sure on font size configurability (beyond the obvious "it will use the OS size") but I would certainly want all user-provided values to be fully displayed either by default (due to auto-resizing display) or manually (e.g. resizable columns).

As an aside, I expect this tool to be built as a simple Windows.Forms app, which means we immediately have access to plenty of battle-tested UI components (like grids with resizable columns).

Eldorado.Railroad, on 09 April 2017 - 08:15 AM, said:

In a very short list and not conclusive, you will have to deal with dead engines, loaded and unloaded wagons, etc. All of these need to be clear to the user, somehow. I agree with Goku, a selected piece of rolling stock should be immediately (well within reason) visible. As a sidebar, for the longest time, I have wished for OpenRails to have its own shapeviewer, that understands, non square textures, DDS textures, etc. Other things like random consist creation are also very handy to have.

The viewing of the content is important for sure, but I think that should only be added once we have the very basic functionality working.

Maybe adding that functionality would also be a good opportunity to refactor some more code and make it possible to build a shape viewer-like tool as well.

Genma Saotome, on 09 April 2017 - 12:29 PM, said:

Years ago I argued on behalf of using a dbms to solve all of the unmanaged relationships between track and intereactives but it was far too early in the project for anyone to care about. Perhaps it'll return as a point of serious conversation.

It can certainly form part of the discussions; I have some reservations on how much it'll actually solve, but we should at least look into the practicalities of using something DBMS-like in the content.

Genma Saotome, on 09 April 2017 - 12:29 PM, said:

The fundamental issue here is absent complete management within a custom application, one that presents you with all the metadata you need (thereby allowing the file name to be both hidden from view and probably just a serial number), we're going to put a lot of that metadata into the filenames: Road initials, unit number, type of unit, overall appearance of unit, optional but important features (like a white extra flag), and date range within which the model, in this appearance, was used. Or as they say, a real mouthful: "WP F7A #913 Silver small letters extra 1950-54"

We can add editing into the consist editor, perhaps? Given it'll need to be involved with all the key fields for finding content, it might also be a suitable place to edit some of it.

Genma Saotome, on 09 April 2017 - 12:29 PM, said:

IMO there is a need for some conceptual re-thinking: Take the mesh file and call it a class from which a variety of subtyped objects can spring, each of which get defined as individual game objects ahnd you solve lots of problems. For example, take a mesh for a particular U.S. diesel locomotive: A EMD SD-40. One file. Now add a subtyped variant: the skins it will display (yes, I know those are defined in the mesh but here I'm speaking of what the OR software will actually display. One mesh, many sets of skins, varying by railroad, railroad paint scheme, unit number, etc. etc. Maybe hundreds of variations.

I have not yet got my head around how we'd set up this mesh/parameters/textures collection but in principal I like it.

[Genma Saotome]

James Ross, on 10 April 2017 - 10:48 AM, said:

I have not yet got my head around how we'd set up this mesh/parameters/textures collection but in principal I like it.

James, perhaps this model will help (revised April 12 -- text revisions highlighted thusly):



Notation

• Rectangle: A discrete entity. Several may be required to make an object.
  
• Lines between entities. Describes the relationships between entities. "Crows feet" signifies many on that side. A zero on the line indicates optionality.
  
• Text is the verb describe the relationship as seen from the parent -- singular -- entity.
  
• The unique identifer(s) listed are the natural keys -- the non-physical keys. In some cases the physical keys will be the filename. In other cases a list name. Using the natural keys help helps convey how certain combinations of keys define the criteria for will eventually become either a file or a list.

Across the top row are the traditional mesh and texture files, however OR wants to define them. The Images entity is the list of textures in the .s file.

Second row, on the left: Everything within the yellow rectangle represents what it takes to make a physical model along with it's game parameters and should be held in one file. By physical I mean as many mesh and parameter files as are needed to represent the physical nature of any model -- meaning without skins. As implemented this would be a single object holding two lists.

Second row, on the right: Everything in the green rectangle makes up the list of textures the model will use when it is displayed. Everything within the green rectangle should be in one individual file. The TextureList entity may be hard to understand; what I'm trying to document is this: If you say texture a replaces texture b it stands to reason texture b, as named here, is actually listed in one of the mesh files. In fact, it may stand to reason you should actually say which mesh it is listed in. With that understanding I think you'll grasp the reasoning behind all of the natural keys that are present. Identifying the need to deal with that is the simple part. The hard part is how does one go about doing that? Well... have fun! :blush:

Continuing, this object may or may not include parameters to override what was specified at the mesh level (the entity in the lower right). For instance, it is reasonable to assume people might want to customize the values of exhaust thereby making each model in-game unique. I havn't bothered to detail out the thinking here... regard it as a post-it note requiring further thought.

Bottom row, left. Individual files containing parameters and their values for specific game features -- think .inc files. One such files might be for Type D couplers, another for Type E, and a third for Type H. Similar files for different brake stands, etc. etc, etc. The point here is such files could be used by many different Complete Physical Models -- type E couplers were used to 50 years on North American freight cars w/o regard to car design.

Bottom Row, center: A one to one relationship between all of the data and what the OR software will have internally. Logically you should see this relationship as OR reading all of the data for a single .wag or .eng -- a 1:1 relationship between a program object and a single set that is a list of flat files. The OR portion parameters could be identical to the set of flat files, could be a superset, whatever you need that is the active body of data rather than the static values read from the files. The point is this is the interaction point.

Bottom Row, right, as mentioned above, a post-it note to remind one to think more on how to handle over-rides.

Given this, then what you have here is a single assembly definition that takes 1 to n mesh files and makes that definition available to 1 to n different skin files, each of which have their own list of textures to use on those meshes*. The complete body of information is then presented to OR for its use. Whether than "presentation" takes the form of a single file or several is up to you but IMO the better answer is several.

*I've not bothered to detail out what may be required to ensure the integrity of the mesh to texture assignments, largely because it would add a level of complexity to this presentation which isn't needed at the moment.


Do understand this is about 30 minutes of thinking and so you may well discover illogical flaws. It's just meant to get you started.

[James Ross]

Genma Saotome, on 10 April 2017 - 03:36 PM, said:

Do understand this is about 30 minutes of thinking and so you may well discover illogical flaws. It's just meant to get you started.

Thanks, that does make things very clear.

I guess we kinda already have the three boxes on the left, with .s files for the mesh, .wag / .eng for model physicality, and .inc files for the parameters, but nothing to do with skins, and the textures are mixed into the mesh.

Am I right in thinking that activities/etc. would refer to the skin file, as that uniquely identifies all the other files (if I've understood correctly)?

One of the things that was going through my head reading this the other day was, how does the mesh/skin get authored? It's unlikely that many, if any, export formats, exporters, or tools really do this separation - although you can certainly build texture-less meshes, you then have an issue identifying textures for faces and UV coordinates.

Seems like it could work if the skin file assumes that you want the texture as named in the mesh, then a default skin file is going to be nothing more than a pointer to the complete physical model file + skin name/description. But to make a reskin, you simply create a skin file referring to the same complete physical model file + skin name/description + a mapping of textures (map name a to name b?) + any parameter override files. Does that seem okay?