[conductorchris]

Regarding consist names

In the old days when filenames were short things like BuNoWC31, it was obvious that the file name would frequently not be the name the train was referred to.

In the states, trains can have multiple names. At least three formats are used, sometimes all at once:
- The leading locomotive number and direction (with reporting marks if "foreign"). So for example: "CCCX extra CR 1531 north" ... a train I crewed for the Cape Cod Central Railroad, running on the Bay Colony Railroad using Conrail GP15-1 #1531 and going west, which is timetable north.
- Train Number or symbol. For example: "Amtrak 91" or "ELOI" (Conrail Elkhart to Oak Island frieght) or #324 (the New England Central RR freight running on today's Connecticut River line - which might also be referred to as "NECR 3851".
- Train name. For example "Silver Star" (also known as Amtrak train #91) or "The Speed Merchant" (hot overnight New Haven RR merchandise freight) or "Jessup Turnaround" a local on the B&O between Brunswick and Jessup.

Christopher

[James Ross]

 YoRyan, on 06 July 2020 - 04:33 PM, said:

The new format will use the "consist-or" extension and it would supersede any .con file with an identical base name, in all contexts (activity, timetable, explorer). A JSON consist will specify a display name, maximum speed, durability percentage, and whether or not it is listed in the player consist list. The format is flexible enough to introduce other kinds of metadata, but I do not plan to do so at this time, as from what I can tell, most of that stuff falls under the purview of activity mode.

Thanks for taking this up, it looks like a very solid proposal!

Everything I've not commented on below, I strongly approve of. Repetition is a nice addition!

 YoRyan, on 06 July 2020 - 04:33 PM, said:

Engines, wagons, and consists can be loaded from other installation profiles. The string supplied must match one of the installation profile names entered into the settings table.

{
    "Engine": "3DTS_SJVRR_GP9_1754/3DTS_SJVRR_GP9_1754",
    "Profile": "Tehachapi Pass"
},

I feel like this option is premature; the profile names are entirely user-controlled and this will likely need to change when we start putting things into our own file structure.

 steamer_ctn, on 06 July 2020 - 09:52 PM, said:

Can I suggest that if this is potentially going to be the first step for an OR only simulator, rather then a tweak of MSTS stuff, that a full "literature survey" be undertaken (perhaps with the help of some community members) to allow any appropriate needs that have been suggested over the years to be considered, for example like this one.

This will help develop a list of all the identified needs and desires? Then the question becomes what items are relevant, and finally a specification can be developed as a result of this?

How would these changes be captured in any OR consist editing tools?

I do not believe this feature, as currently reflected in the opening post, needs a full literature survey to go ahead and be experimented with. It is important that we all know it is experimental, though! (This means I absolutely do not expect/want any 3rd parties publishing content using it right now.)

Where such a survey will help, however, is in fleshing out the feature to ensure it covers a reasonable range of desired outcomes and that will be necessary before we begin fully supporting this. Hopefully, an editor will be implemented somewhere in between. :)

 Csantucci, on 07 July 2020 - 12:05 AM, said:

As can be seen, I have explicitly mentioned .con files. In fact, while I of course I'm in favour on extending file formats, I'm not enthusiastic about changing file formats, if there aren't real advantages for that, that are greater than the disadvantages. To be clearer I don't see a real advantage in writing

The plan has always been to create our own formats, as we're doing here, but also that we won't remove MSTS formats or stop supporting them.

 YoRyan, on 07 July 2020 - 10:10 AM, said:

• A means to set parameters that can be referenced by future .engine-or and .wagon-or formats

I don't see anything explicit in the current proposal for this, so I hope you're on the same page as me there: this is very probably going to be required, but it should come later, once we start thinking about engine/wagon formats. As long as we are careful not to prevent adding this later (something I think we get almost for free in JSON), it's fine to not include it right now.

 YoRyan, on 09 July 2020 - 12:43 AM, said:

Removed recursion as it seems too complex for correspondingly little gain.

Does this mean you can only link one level from consist -> consist?

 YoRyan, on 09 July 2020 - 12:43 AM, said:

Dave, the properties you propose seem better suited to a new activity format. Activity designers would want to control things like fuel and cargo levels. There are no doubt some data tags that belong in the consist format, but perhaps not very many, since a single consist can expect to be spawned many times during the same session.

This is going to be a lovely big conversation when we figure out how we can do a new form of activities. :)

[YoRyan]

Pleased to hear from you, James. :)

 James Ross, on 18 July 2020 - 04:59 AM, said:

I feel like this option is premature; the profile names are entirely user-controlled and this will likely need to change when we start putting things into our own file structure.

I see. Nevertheless, the feature has been implemented, and to me, it seems useful. Perhaps there is a middle ground whereby we could mark this option as especially experimental. A consist editor could also offer to correct profile names that are missing or have been renamed.

 James Ross, on 18 July 2020 - 04:59 AM, said:

I don't see anything explicit in the current proposal for this, so I hope you're on the same page as me there: this is very probably going to be required, but it should come later, once we start thinking about engine/wagon formats. As long as we are careful not to prevent adding this later (something I think we get almost for free in JSON), it's fine to not include it right now.

I agree, and the good news is that JSON.NET makes adding new fields ridiculously easy, by maintaining a 1:1 mapping between C# classes and JSON data. (Theoretically, no additional code has to be written to serialize the new consist classes.)

 James Ross, on 18 July 2020 - 04:59 AM, said:

Does this mean you can only link one level from consist -> consist?

What I meant to say is that within a single file, you cannot embed a Link consist in another Link consist, or a Random consist in a Link consist, etc.; you must split off the "sub-consist" into a new .consist-or file and link to it with a Consist reference. There are no restrictions on Consist -> Consist links except that they themselves cannot be recursive, so A -> A is prohibited, and so is A -> B -> C -> A.

[Genma Saotome]

I'm disappointed. It seems the purpose here is simply to be using a file suffixed with consist_or. I DO appreciate a careful evolution but this seems far too cautious.

For years I've been asking FOR train and block files, all of the .con parameters shift to one of those files and with minimal additional code (to read the list of block files to find the cars). No other attributes need be added in the initial release (unless there is time and interest on the part of the developer).

Trains and Blocks do have specific attributes not provided for in MSTS, only some of which can be enabled in the proposal under consideration (block stuff). Adding them to .con files having no locomotives IS a block file so define it as such. All loose consist lists are equal to a block file were they so set up, so define those as such. In effect, a block file equals a loose consist. A train file is one or more locomotives and a list of block files. ALL North American train operations have used these concepts for at least 70 years, possibly longer. Over those years the term block often referred to the grouping of locomotives making a train a collection of blocks, one of which was locomotives.

These are not hard concepts nor do I think the implementation is daring.

IMO it is long over due to do add something that is actually new,

[YoRyan]

The initial implementation is complete and ready for code review. It includes the necessary changes to the launcher (new locomotive picker menus) and content checkers. Quite a massive patch... it will no doubt take some time to get through the process.

 Genma Saotome, on 20 July 2020 - 12:37 PM, said:

Trains and Blocks do have specific attributes not provided for in MSTS, only some of which can be enabled in the proposal under consideration (block stuff). Adding them to .con files having no locomotives IS a block file so define it as such. All loose consist lists are equal to a block file were they so set up, so define those as such. In effect, a block file equals a loose consist. A train file is one or more locomotives and a list of block files. ALL North American train operations have used these concepts for at least 70 years, possibly longer. Over those years the term block often referred to the grouping of locomotives making a train a collection of blocks, one of which was locomotives.

I am sorry to hear that you're disappointed, but I still believe that this is the appropriate amount of information for a loose consist file. The "train" attributes that you speak of are better suited to the activity and timetable files, where the context of a train - its origin, destination, and switching maneuvers - is instantiated and available. A consist file that describes a single San Joaquin formation of 5 California Cars can be loaded multiple times, but there is only one (or none of) "Train 710 from SJQ to BFD."

So think of the consist files as "blocks," and the activity and timetable editors as defining "trains." Currently, timetables permit the designer to load multiple consists in sequence (as JSON consists will now do). When we develop a new activity format, we could extend activities to support this feature, with the addition of useful data tags. A "train" would no longer be defined as a single consist file, but rather a sequence of consists, each with their individual attributes:

• Engines
  
• Cut 1 (origin, destination)
  
• Engines
  
• Cut 2 (origin, destination)

The use of such a system would be entirely up to the activity designer where it makes sense. Not every activity will model prototypical North American operations.

[Genma Saotome]

I've no issue with redefining teh concept of consist as the concept of block. IMO renaming it would make that clear.

I also agree that the body of information labeled "Activity" should be used to provide many attribute values. The question is whether that is the only means to do so. I'm concerned the absence of default values may present a workload that some will regard as too much and/or repetitive. As an example, a loaded coal hopper. There is no sense in recording LadingMass() and LadingName() in every "activity" group of files when it's obvious the values are, effectively, defined at the mesh file stage.

Similarly, if you rep4at a reefer 7 times and each one is loaded w/ Melons from Firebaugh CA you could define all of that information in the "Activity" group of files... or once in the block file -- using the block again in any number of trains, or if Techachippi is the only route you use PFE Reefers on, setting the values in the .wag file.

All three could be valid. If done properly each successive stage from .wag to "activity" could overwrite whatever was previously recorded. I suspect many folks would accept whatever was in the .wag file for all instances of use. Others, like myself, would take full advantage for the three-layered default-to-activity-specific feature.

[YoRyan]

 Genma Saotome, on 20 July 2020 - 02:25 PM, said:

I've no issue with redefining teh concept of consist as the concept of block. IMO renaming it would make that clear.

Very possibly. On the other hand, we've also an international audience to consider, and the term "consist" is a natural carryover from MSTS. Shall we put it to a vote?

 Genma Saotome, on 20 July 2020 - 02:25 PM, said:

I also agree that the body of information labeled "Activity" should be used to provide many attribute values. The question is whether that is the only means to do so...

All three could be valid. If done properly each successive stage from .wag to "activity" could overwrite whatever was previously recorded. I suspect many folks would accept whatever was in the .wag file for all instances of use. Others, like myself, would take full advantage for the three-layered default-to-activity-specific feature.

Yes, I agree, there is a nice hierarchical progression from .wag to .con/.consist-or to .act/.timetable-or. Nothing in the proposal precludes the addition of future fields, overrides, or default values; it's just that I haven't worked out what those would be. For example, I'm not familiar with the freight animation system, but it seems like a natural fit for the consist file.

Indeed, any future fields must have sane default values, since there will always be the lingering problem of .con files...

[Genma Saotome]

 YoRyan, on 20 July 2020 - 02:46 PM, said:

Very possibly. On the other hand, we've also an international audience to consider, and the term "consist" is a natural carryover from MSTS. Shall we put it to a vote?

No, I know how issues turn out -- it's always the same.

So Ryan, I'm going to bow out now... it is my once or twice a year foray into whatever is or is not happening in OR. I wish you a good experience working on a large program like this and I thank you for the time you put into it. None of this would ever have happened w/o volunteers like yourself. :cheers3:


p.s.
Professionally speaking with data it is always important that the name is precisely understood and not open to multiple interpretations -- every disagreement i encountered professionally over the name of something was due to quite different concepts tagged with one name. A classic example would be a class name applied to several wholly different specializations when the argument was about the specific and not the general..

Rather than carrying a name along from MSTS days it would be better to leave it behind -- and do so with as many of them as possible so when the old word gets used in conversation or code everyone knows it means only the KUJU definition. THAT is why I recommend Train and Block over sonsist, that is why I think Operation should replace Activity, .fcar and .pcar replace .wag. Hanging on to obsoleted names impairs understanding and leave to door wide open to making mistakes. One is not going to make a typo with .Block, nor misunderstand on receiving that file that it will not be the same as if it were .con; The name and all of its contents are new.

[YoRyan]

Thanks, Dave. Please know that your input is appreciated.

It's clear that the new system is so flexible that it goes beyond what the term "consist" traditionally refers to, i.e. a complete formation of engines and wagons. Instead, what we will have are more like blocks, or rather building blocks of wagons, each with potential property overrides. So perhaps "wagon list" would be a more suitable term that does not carry the MSTS baggage.

[darwins]

Jumping in I must say I have never heard the concept of blocks before, but I do like the idea that Train = Loco1 + Loco2 + Block1 + Block2 + Block3 - at least in terms of traditional locomotive hauled trains.
It makes a lot of sense to me because trains were often made up of a number of 'sets' of stock, some of them semi-permanently coupled within the sets, so it would be an easier way of assembling trains within activities or timetables.
There are two provisos to the above approach:
1. Steam locomotives with tenders need to be defined as a single unit = Loco1 or whatever - no point have loose tenders... (Not forgetting articulated locomotives or master and slave diesel units...)

2. Multiple unit trains presumably need to be blocks that do not require a locomotive - so there needs to be something different in their definition to unpowered blocks. (Also other self propelled vehicles or blocks that can not work in multiple.)