[YoRyan]

Wikipedia has a nice section on JSON syntax. It isn't very complicated - just collections of keys and values that map to JavaScript data types.

[YoRyan]

Genericized the consist spawning code and made good progress on the JSON loader. Say hello to our very first JSON consist!

Attached thumbnail(s)

• 

[lineman]

YoRyan, on 12 July 2020 - 11:17 AM, said:

Genericized the consist spawning code and made good progress on the JSON loader. Say hello to our very first JSON consist!

I like that!! Good luck in continuing to advance this, what a great idea and implementation!

[YoRyan]

Implemented the ability to load rolling stock from other installation directories. Consists can now reference other consists.

{
    "Name": "Fake Acela",
    "Durability": 1.0,
    "List": [
        {
            "Engine": "3DTS_SJVRR_GP9_1754/3DTS_SJVRR_GP9_1754",
            "Profile": "Tehachapi Pass"
        },
        {
            "Engine": "3DTS_SJVRR_GP9_1754/3DTS_SJVRR_GP9_1754",
            "Flip": true,
            "Profile": "Tehachapi Pass"
        },
        {
            "Wagon": "3DTS_GATXTANKER/3dts_gatxtanker",
            "Profile": "Tehachapi Pass",
            "Count": 3
        },
        {
            "Consist": "kiha31a"
        }
    ]
}

Attached thumbnail(s)

• 

[R H Steele]

I'm trying to understand this thread...I'm liking what I see, but not completely comprehending it ( much like my first encounter some years ago wiith concept of include files. ). Eventually will there be a set of standard templates ( like your examples in this thread ) that will present a visual template for the end user?
Thanks for all your time and effort --- http://www.elvastower.com/forums/public/style_emoticons/default/sign_rockon.gif http://www.elvastower.com/forums/public/style_emoticons/default/hi.gif--- Regards, Gerry

[YoRyan]

There will certainly be a written manual section. If the stars align, I might also be able to crank out some kind of consist editor. Have to learn WinForms, though...

[roeter]

I see that the consist still has a 'name' field, additional to the filename.
When referencing the consist, e.g. in timetable or indeed in another consist, does one have to use the filename or the 'name'?

Having to use the name can be confusing as the name is not shown on the 'outside'.
If one has to use the filename, than what purpose does the name field serve?

MSTS data was littered with these double (or even triple) names. My view is that any new datastructure should eliminate these doubles and triples.
Unless a consist file can hold more than one consist definition, I do not see any usefull purpose for a name field, as one can just as well use the filename as reference.

Regards,
Rob Roeterdink

[YoRyan]

That is a good point. Note that the .con format actually has three names:

• The filename before .con
  
• The "TrainCfg" name
  
• The "Name" name

The first two are usually interchangeable, but this is not necessarily true, which can lead to ambiguities. (For the record, OR always uses the filename.)

The new format drops the TrainCfg field, leaving the filename and the Name field. I think there is still value in retaining both, because the Name field is used by the launcher to present a friendly name in the consist menu, and sometimes you want to use different semantics for these names. For example, I prepend all of my personal consists' filenames with "YoRyan_"; I wouldn't want that to show up in the launcher list.

[YoRyan]

Consist randomization is working!

{
    "DisplayName": "1x Marias Pass Yellow Beam Car",
    "Durability": 1.0,
    "Random": [
        {
            "Wagon": "US2FCARYE2/us2fcarye2",
            "Probability": 0.3
        },
        {
            "Wagon": "US2FCARYF2/us2fcaryf2",
            "Probability": 0.7
        }
    ]
}

{
    "DisplayName": "Fake Acela",
    "Durability": 1.0,
    "List": [
        {
            "Engine": "3DTS_SJVRR_GP9_1754/3DTS_SJVRR_GP9_1754",
            "Profile": "Tehachapi Pass"
        },
        {
            "Engine": "3DTS_SJVRR_GP9_1754/3DTS_SJVRR_GP9_1754",
            "Flip": true,
            "Profile": "Tehachapi Pass"
        },
        {
            "Consist": "beamcar",
            "Count": 16
        }
    ]
}

...but I do not yet have the locomotive picker implemented, which will require more code and some launcher changes.

Attached thumbnail(s)

• 

[longiron]

congratulations. Always great to experience progress when you are working a project.

[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.