Posted 05 October 2017 - 01:23 PM
FWIW I spent many years working as a Data Architect -- not the physical stuff DBA's do but the business analysis side -- helping management reveal the true nature of the data they needed, how it was different than the systems they had purchased, and documenting it all in a standard notion. Much of this work was conducted in JADS -- Joint Application Design Sessions -- me, a group of managers, and an open floor debate over meaning and purpose. For most of my career I had business-unit responsibility, which usually meant world wide and I finished up with company-wide responsibility, also world-wide. And I was VERY good at this, no doubt in large part to my INTP personality. MANY time there would be arguments over what something meant. In almost all cases the problem would be solved with the realization they were using one word to describe two very different concepts. Come up with a second phrase, pull the two concepts apart and give them different names and suddenly everybody was all smiles.
This problem of different meanings has been an ongoing problem for anyone working on any train sim (perhaps Run-8 is the least affected): Is a consist (.con file) the one and only concept we need? Kuju provided that... and sort of something else called a loose consist, but what we have in fact are a train, a collection of locomotives joined for MU operation at the front end, another kind acting as helpers, a string of cars used for scenery, a block of cars traveling unchanged from point A to point B, a cut of cars (i.e., a temporary collection that will be reformed by switching actions), ladings and weights varying per the activity in which they are used, and a trainset (e.g., a seldom if ever changed set of passenger cars), and multiple .s files to create a single locomotive just to name what comes to mind. Some of those might properly collapse together but IMO not all of them should go into just one or two concepts. Different data, different life cycles, different in-game functionality.
All of those could be abstracted enough to handle as a .con file... but is that the best answer? With regard to the effort to program solutions, maybe yes... but is it also the best answer for end users or for features in the game? I strongly suspect the answer is no, that one concept -- consist as physically implemented as a .con file, isn't enough.
Just one example to make the point: If we define a collection of locomotives that are operated as one and apply the colloquial term used in North America -- a lashup -- and the logical assembly of several .s files into one locomotive -- lets call that .loco -- we can solve several existing problems, such as today's failure to properly recharge the brake line using the very nicely modeled Milwaukee Road box cabs -- 4 physical locomotives represented by (IIRC) 10 .s files -- a collection of .eng and .wag files). A .loco file concept could "assemble" the multiple .s files, with their .eng and .wag data into one unit in-game, and a .lashup file holding all four locomotives instructs the game to handle commands issued from the cab as if they were a single locomotive.