[gpz]

How about defining a so called "json schema" for the new format, so we all know what we are talking about, and being able to propose specific changes, and not just talking into the fog? As an example, look at the glTF schema, it can be checked, how the big serious guys are doing this.

Here is a basic schema based on YoRyan's examples on the first page, added my own wishes of having nested objects, and being able to define a constraint.
For the top level tags:

{
    "$schema": "http://json-schema.org/2019-09/schema",
    "title": "train-or",
    "type": "object",
    "description": "The new OpenRails consist format",
    "properties": {
        "List": {
            "type": "array",
            "description": "An array of listElements. This ultimately represents a block or consist ordered sequence.",
            "items": {
                "$ref": "listElement.schema.json"
            },
        },
        "Random": {
            "type": "array",
            "description": "An array of randomElements. This ultimately represents an inventory list to pick units from.",
            "items": {
                "$ref": "randomElement.schema.json"
            },
        },
        "DisplayName": {
            "type": "string",
            "description": "The name that can be referenced in Consist or Train tags",
        },
        "MaxVelocityMpS": {
            "type": "number",
            "description": "Maximum velocity of the sub-elements",
        },
        "Durability": {
            "type": "number",
            "default": 1.0,
            "minimum": 0.0,
            "maximum": 1.0,
            "description": "Durability percentage",
        },
        "PlayerDrivable": {
            "type": "boolean",
            "default": "true",
            "description": "Whether it is to be listed in the player train/consist list",
        },
    },
}

This is for the ordered list tag under "List[]":

{
    "$schema": "http://json-schema.org/2019-09/schema",
    "title": "listElement",
    "type": "object",
    "description": "Ordered list of unit selections",
    "properties": {
        "Engine": {
            "type": "string",
            "description": "Reference to an MSTS .eng",
        },
        "Wagon": {
            "type": "string",
            "description": "Reference to an MSTS .wag",
        },
        "Consist": {
            "type": "string",
            "description": "Reference to another List type element",
        },
        "Train": {
            "type": "string",
            "description": "Reference to a Random type element",
        },
        "Flip": {
            "type": "boolean",
            "default": "false",
            "description": "Flips the (sequence of) unit(s)",
        },
        "Count": {
            "type": "integer",
            "default": 1,
            "minimum": 1,
            "description": "Selects and includes multiple of the referenced unit(s)",
        },
        "ConstraintOnSubSelections": {
            "type": "boolean",
            "default": "true",
            "description": "The sub-Train/Random should select always from the same pool",
        },
    },
}

And this is for the random inventory list under "Random[]":

{
    "$schema": "http://json-schema.org/2019-09/schema",
    "title": "randomElement",
    "type": "object",
    "description": "An inventory of units to select from",
    "properties": {
        "Engine": {
            "type": "string",
            "description": "Reference to an MSTS .eng",
        },
        "Wagon": {
            "type": "string",
            "description": "Reference to an MSTS .wag",
        },
        "Consist": {
            "type": "string",
            "description": "Reference to a List type element",
        },
        "Train": {
            "type": "string",
            "description": "Reference to another Random type element",
        },
        "Probability": {
            "type": "number",
            "minimum": 0.0,
            "maximum": 1.0,
            "description": "weight of probability",
        },
    },
}

[gpz]

Now seeing this, I have my first suggestion: The "Train" tag's name is quite strange, because that doesn't reference a _train_ in neither of interpretations appeared here recently. It only references a random-selectable inventory. It should be renamed to some more meaningful name, that represents, that it points to a pile of units that it will pick one from, not to a _train_. I propose renaming it to "SelectFrom".

[gpz]

It might also be a good idea to rename the "Consist" tag, to avoid using the MSTS name, and actually avoid using any name at all, thus making the future naming arguments pointless. I propose renaming it to "AddSequence" or "AddList"

[RR1]

Ok, thanks re your MU comments.

 YoRyan, on 06 August 2020 - 02:17 PM, said:

Some GE locomotives are also equipped with a radio system, known as "Locontrol," to bridge the gap via wireless radio.

Regarding DPU though, FYI Locotrol was developed in the 60's and GE eventually acquired the technology through acquisitions. Locotrol is not limited only to GE engines. In fact today its apparently on more than 8500 locomotives around the world.

[YoRyan]

 gpz, on 07 August 2020 - 03:11 AM, said:

How about defining a so called "json schema" for the new format, so we all know what we are talking about, and being able to propose specific changes, and not just talking into the fog?

Thanks very much for the schema. I agree that going forward, I would like to see suggestions accompanied by concrete proposals for the specification.

Regarding nested objects, I had considered them at first, but I don't believe they are necessary. The reason is because I would like to write a GUI editor for this format, which would then become the primary (if not sole) method of creating consists. It would be convenient to force users to name all consists for future reuse.

Now, this would appear to result in a highly cluttered CONSISTS directory, but stay tuned on that front, because as soon as the dust settles here, I would like to revive the concept of a content manager. This would enable Open Rails to load from and store consists in multiple, segregated namespaces of content.

 gpz, on 07 August 2020 - 03:16 AM, said:

Now seeing this, I have my first suggestion: The "Train" tag's name is quite strange, because that doesn't reference a _train_ in neither of interpretations appeared here recently. It only references a random-selectable inventory. It should be renamed to some more meaningful name, that represents, that it points to a pile of units that it will pick one from, not to a _train_. I propose renaming it to "SelectFrom".

The idea is that it references another .train-or file, hence the use of the "Train" name. The referenced train needn't necessarily be a "Random" type; it could also be a "List" type.

(Frankly, I'm now less convinced of the need for a "new" name for our native format, unless somebody brainstorms a more suitable name than "consist.")

 gpz, on 07 August 2020 - 08:30 AM, said:

It might also be a good idea to rename the "Consist" tag, to avoid using the MSTS name, and actually avoid using any name at all, thus making the future naming arguments pointless. I propose renaming it to "AddSequence" or "AddList"

Here, "Consist" is used specifically to reference an MSTS .con file.

[YoRyan]

 Genma Saotome, on 06 August 2020 - 08:00 PM, said:

:jawdrop2:
Much bad news deleted to save my brain.

Ok, will consider that fora while... will get back to you.

Rob is not saying that the TrainClass and TrainDirection fields shouldn't exist... it's just that you seem oddly fixated on stuffing all of it into the .con file, a context-free list of rail vehicles.

This information belongs in the activity, traffic, and timetable files - or in the "explore the route" menu for the player to define themselves. Full stop.

[Genma Saotome]

 YoRyan, on 07 August 2020 - 12:10 PM, said:

Rob is not saying that the TrainClass and TrainDirection fields shouldn't exist... it's just that you seem oddly fixated on stuffing all of it into the .con file, a context-free list of rail vehicles.

This information belongs in the activity, traffic, and timetable files - or in the "explore the route" menu for the player to define themselves. Full stop.

No, Rob is saying a real train in the UK -- under its official railroad name and number, can change both class and direction before its run is complete. THAT is news to me and IMO greatly complicates things.

As for the rest, I am still of the opinion there is some kind of construct that defines the complete set of units moving along the rails which is not the same construct as various subsets of the whole that are groupings of units contained therein. For now it doesn't matter to me what names are to be used, only that the two concepts are well defined and implemented as distinct things. As you observed earlier, all of the passenger units in the Acela example -- a list of units -- could be in many different circumstances -- those are a subset of the entire collection of units moving along the rails. I think we all agree on that. We do not yet agree on what to call those two things, nor have we settled on what data belongs with each one. That is not unusual for this sort of work (trust me on that as I did this stuff professional for nearly 25 years and I have to say doing it via posts has to be the most unproductive way I can imagine).

The other thing that concerns me is we're not thinking of the same situation where this data will be used. As best I can tell, you guys are thinking about what happens in an activity whereas I'm thinking what would a player like to see in explore route. I'm figuring if we have ideas that will work for explore route they should serve as defaults that can be revised for different Activities. In contrast, pushing Activity only solutions, while important, is almost a don't care for me. I am trying to help in that regard but it is not a priority for me.

[roeter]

 Genma Saotome, on 07 August 2020 - 01:04 PM, said:

The other thing that concerns me is we're not thinking of the same situation where this data will be used. As best I can tell, you guys are thinking about what happens in an activity whereas I'm thinking what would a player like to see in explore route. I'm figuring if we have ideas that will work for explore route they should serve as defaults that can be revised for different Activities. In contrast, pushing Activity only solutions, while important, is almost a don't care for me. I am trying to help in that regard but it is not a priority for me.

And please don't forget timetables. There are many and very deep differences between activities and timetables regarding the use of consist definitions and other things around it. So, in all, we're trying to push three pretty different sets of thoughts, ideas and necessities into one concept.

Regards,
Rob Roeterdink

[YoRyan]

 Genma Saotome, on 07 August 2020 - 01:04 PM, said:

The other thing that concerns me is we're not thinking of the same situation where this data will be used. As best I can tell, you guys are thinking about what happens in an activity whereas I'm thinking what would a player like to see in explore route. I'm figuring if we have ideas that will work for explore route they should serve as defaults that can be revised for different Activities. In contrast, pushing Activity only solutions, while important, is almost a don't care for me. I am trying to help in that regard but it is not a priority for me.

I didn't realize you were thinking in terms of "explore the route" mode, and I find this very notable, because that mode isn't really intended for this kind of structured gameplay, being that it lacks any AI traffic or static railcar spawning. At best, you can align the switches to access sidings and drop off cars from your train - but this is merely a form of optional "role-playing," since the simulator itself won't give you any guidance or track the progress of your objectives. And for explorer mode, that's fine. It's always been more of a casual "pick a route, consist, and starting location, and away you go" kind of deal, at least as I always understood it going back to the MSTS days.

So if you were looking for the ability to add custom destination tags to the cars of your train, I guess I can see why you would look to the .con format to do so, but the thing is that they wouldn't make any sense in the context of explore the route mode - since players would be under no obligation to honor them, and Open Rails wouldn't make any use of them, and thus they would be pure eye-candy. A consist alone is one train configuration among many you can choose to operate in explorer mode. A consist combined with routing instructions (as you propose) makes an activity.

 roeter, on 07 August 2020 - 02:19 PM, said:

And please don't forget timetables. There are many and very deep differences between activities and timetables regarding the use of consist definitions and other things around it. So, in all, we're trying to push three pretty different sets of thoughts, ideas and necessities into one concept.

Different, but perhaps not that different?

A "consist" as Kuju defined it is a list of railcars that can be spawned by the simulator. Activities spawn consists when services begin their runs, and similarly, timetables spawn consists when trainsets begin their first runs. Heck, a traffic (.trf) file bears a close resemblance to a timetable file, just without the ability for trains to divide and combine, or to terminate and become other trains - and for performance reasons, Kuju only simulated trains that run against the player's direction, but that's by no means an invariant.

[Genma Saotome]

 roeter, on 07 August 2020 - 02:19 PM, said:

And please don't forget timetables.
Rob Roeterdink

No problem. I have no experience using timetables but from your comments it is quite clear you have found situations that cannot be well handled by OR today, things that do seem relevant to the conversation.