[YoRyan]

 gpz, on 08 August 2020 - 02:29 AM, said:

In my opinion the "Train" keyword in the current form is a clear weakness. There must be a distinction if it is for "selecting 1 from a pile" or it is "merge a sequence".

To me, it seems clear - if you add a "Train" reference to a List[] consist, that's merging a sequence, and if you reference a Random[] consist, that's selecting from a pile.

Using dedicated keywords would seem to limit our flexibility. In the future, I intend to add more consist types, like ranked preferences and equipment pools. Would we be required to add more keywords for those? What if I change one of my consists from a List[] type to a Random[] type; will I have to go back and repair all of the referencing consists?

(By the way, if it's the "Train" name you object to, I am increasingly of the opinion we should just stick with "Consist!")

 gpz, on 08 August 2020 - 02:17 AM, said:

Consider the following scenario. There is a fixed "List[]" of units, call it an EMU. There are multiple EMU-s collected into a "Random[]" pile, of color red. There is another "Random[]" of blue EMU-s. I want to form 2xEMU-s for a service. These 2xEMU-s can be any color, but both EMU-s in the consist must be the same color. To accomplish this, I form another "Random[]", let's call it RegionalEmus, that contains two elements: the red EMU-s and the blue EMU-s. Then I create a "List[]" of two RegionalEmus "Random[]" elements, named 2xEMU, with a constraint described above. Some services in a day has a 3rd EMU, that goes to a further smaller city, so I define a 1+2×EMU "List[]" with two elements: a RegionalEmus "Random[]" and a 2xEMU "List[]". The point is the flexibility. With a new format such a flexibility should certainly be possible.

 roeter, on 08 August 2020 - 04:46 AM, said:

Fully agree, this is exactly what happens with trains formed of multiple MU. The definition of a MU cannot be random, as it is a fixed formation. But the definition of a train or part of a train can be random.
The reverse can also happen. A freight train may consists of a fixed number of blocks, as that is the load assigned to that train, e.g. to supply a set of clients at a certain location. But the formation of each block itself could be random (and even empty!) depending of the required transport needs at that time.
Say, for instance, that a freight train takes blocks for industries I1, I2 and I3. One day, the group for I1 consists of 3 wagons, I2 of 2 wagons and I3 of 4 wagons.
But the next day, it may be that the block for I1 is empty, I2 has 7 wagons and I3 only 1. Such a freight actually passes my house a couple of days a week, and I do regularly see such variations.

Both cases are fully supported, and are exactly the kinds of scenarios I envisioned for this system.

While the top-level "activity consist" (or "train") will be restricted to being a List[] type, it will be able to reference other consists that can be of other types, which in turn can reference yet more consists. Nesting is quite possible via the reference system; it's just that every consist has to have a filename, so no "anonymous" nested consists are allowed.

I am open to supporting anonymous nesting, too, but in the long-term I still see an editor as being the primary way to create consists, so I don't know how many people would make use of such a feature.

 roeter, on 08 August 2020 - 05:14 AM, said:

To 'translate' this to the new concept, each unit (presently 'wagon' class) should hold data which holds information about the consist through which it was created. This should at least be the 'lowest' level (lowest block level), but preferably the full hierarchy level of that consist.

So actually, I do not envision giving the activity or timetable subsystems access to the consist hierarchy. As far as they're concerned, the consist is just a flat formation of wagons.

Of course, if they spawn multiple consists strung together, they will be able to retain information on which cars were spawned by which consist, but they'll only have access to the top level.

I am also open to changing this, but I'll have to see some proposed used cases and attributes.

[Genma Saotome]

Good discussion here guys.

Question:are there any required data in a random list of units that are not found in the "pre-defined" list of units? Not the header, the list of ordered units. And are there any required data in the "pre-defined" list of units not found in the random list?

If yes, then the argument they are different objects is fortified; if no then they sound to me to be the same object where one is populated with rows differently than the other one.

[Genma Saotome]

Considering the feedback I wonder if this proposal will meet with your agreement: A flat file, .json or SIMIS as required, that is an ordered list of units and a friendly name, with no other data, conceptually akin to.

CallOutName ( "a string" )
Units (

Unit (Path-to-unit unit-file-name)
repeat as desired.

)

It's purpose is ONLY to serve as a list of units. It's real purpose will be specified by actions taken elsewhere, a matter to be determined later in this discussion.

In reference to Rob's post (up two) this is probably what he refers to as his lowest level of grouping, which he called block.

It seems to me that could be created as a product of some randomizing procedure just as well as by an end user in a con editor, or an end user with a text editor. Such a file could be put to use in whatever file construct describes an entire train... or as a loose consist placed somewhere in a route.

I think we all agree on that... and where there is a spread of opinions is what to do with any additional data that logically could slip into that construct. Examples include origination and destination names for the entire grouping as well as lading names, lading weight, consignee name for indivudual freight units as well as others I suppose.

WOuld you all comment on this please so as to make clear where we all are on this specific question?

[roeter]

 YoRyan, on 08 August 2020 - 09:23 AM, said:

So actually, I do not envision giving the activity or timetable subsystems access to the consist hierarchy. As far as they're concerned, the consist is just a flat formation of wagons.

Of course, if they spawn multiple consists strung together, they will be able to retain information on which cars were spawned by which consist, but they'll only have access to the top level.

I am also open to changing this, but I'll have to see some proposed used cases and attributes.

That would be just the same as what is possible right now, and it seems a waste to throw away the advantages and additional options using the hierarchy would offer. I can see no plausible reason why access to this hierarchy would be denied to the processing.

As for an example : have a look at the demonstration timetable for the Springfield Terminal route, available here.
All detach/transfer actions except those for full trains are defined using the consist names.

Please take a look at the definition for trains BMFreightTrains:NB_A, and STFreight:106A.
The consist and detach details for these trains would be made a lot easier if the hierarchy of the consist definition could be used. Moreover, it would be far less vulnerable to errors. The consist and detach details need to be in exactly the same sequence otherwise the detach action will fail. If changes are made, they need to be made at all locations where this sequence is used. If the hierarchy information would be used, any changes would need to be made in the consist definition only.

Regards,
Rob Roeterdink

[roeter]

 Genma Saotome, on 08 August 2020 - 11:05 AM, said:

Good discussion here guys.

Question:are there any required data in a random list of units that are not found in the "pre-defined" list of units? Not the header, the list of ordered units. And are there any required data in the "pre-defined" list of units not found in the random list?

If yes, then the argument they are different objects is fortified; if no then they sound to me to be the same object where one is populated with rows differently than the other one.

There is a difference between random selection and random creation.

Random selection is a selection of units from a collection at the time the consist is defined, and this selection will result in a list of units which is indeed similar to such a list created in any other way. The result is a fixed list, and the consist will be the same each time it is created.
This is what is available now in various programs.

Random creation is a selection of units from a collection at the time the consist is spawned, i.e. created in the program. Details required to create this consist is the collection from which the selection must be made, plus selection information like frequency and limitations (e.g. unique per consist, or unique per world).
The consist will look different each time it is created.
Such random creation does not yet exist.
The required data differs from the contents of a fixed consist so there is a valid argument that it should be a separate class.

Regards,
Rob Roeterdink

[gpz]

 YoRyan, on 08 August 2020 - 09:23 AM, said:

To me, it seems clear - if you add a "Train" reference to a List[] consist, that's merging a sequence, and if you reference a Random[] consist, that's selecting from a pile.

Using dedicated keywords would seem to limit our flexibility. In the future, I intend to add more consist types, like ranked preferences and equipment pools. Would we be required to add more keywords for those? What if I change one of my consists from a List[] type to a Random[] type; will I have to go back and repair all of the referencing consists?

Yes, as many different type of actions defined, as many keywords are needed. Following your logic, you could remove also the Engine, Wagon and Consist keywords, and could perfectly merge them into the sole Train keyword, don't you? Also note, that your Random[] data type is actually NOT a consist, it is a totally different thing. Why do you keep calling that a consist, and why do you think anyone would change a List[] consist to an unordered pile? These are two totally different things. Keeping them separate is not limiting flexibility, it is structuring data.

[roeter]

 Genma Saotome, on 08 August 2020 - 11:22 AM, said:

Considering the feedback I wonder if this proposal will meet with your agreement: A flat file, .json or SIMIS as required, that is an ordered list of units and a friendly name, with no other data, conceptually akin to.

CallOutName ( "a string" )
Units (

Unit (Path-to-unit unit-file-name)
repeat as desired.

)

It's purpose is ONLY to serve as a list of units. It's real purpose will be specified by actions taken elsewhere, a matter to be determined later in this discussion.

In reference to Rob's post (up two) this is probably what he refers to as his lowest level of grouping, which he called block.

It seems to me that could be created as a product of some randomizing procedure just as well as by an end user in a con editor, or an end user with a text editor. Such a file could be put to use in whatever file construct describes an entire train... or as a loose consist placed somewhere in a route.

I think we all agree on that... and where there is a spread of opinions is what to do with any additional data that logically could slip into that construct. Examples include origination and destination names for the entire grouping as well as lading names, lading weight, consignee name for indivudual freight units as well as others I suppose.

WOuld you all comment on this please so as to make clear where we all are on this specific question?

Would be a good first step. Personally, though, I would love to see random creation introduced as well (see previous post). That's something I've been waiting for for a long time.

Regards,
Rob Roeterdink

[gpz]

 YoRyan, on 08 August 2020 - 09:23 AM, said:

Both cases are fully supported, and are exactly the kinds of scenarios I envisioned for this system.

While the top-level "activity consist" (or "train") will be restricted to being a List[] type, it will be able to reference other consists that can be of other types, which in turn can reference yet more consists.

Perfect! I'm sorry for misunderstanding you, I actually interpreted one of your preceeding comments, that nesting is not yet possible. But this is good news, let's take the nesting as solved. :)

[gpz]

 Genma Saotome, on 08 August 2020 - 11:22 AM, said:

WOuld you all comment on this please so as to make clear where we all are on this specific question?

It was confirmed by YoRyan, that nesting his new List[] type structures is already implemented, which means that one can include sub-consists (blocks) into bigger consists, and those into even bigger consists, with randomized selections at creation time possible at any level (@YoRyan, did I interpret well?). However the friendly names ("DisplayName" keyword) of the sublevels in the current implementation are not preserved, but Rob argues for yet to preserve them. Your envisioned use case also supports the argument of implementing this. :)

[YoRyan]

 Genma Saotome, on 08 August 2020 - 11:22 AM, said:

Considering the feedback I wonder if this proposal will meet with your agreement: A flat file, .json or SIMIS as required, that is an ordered list of units and a friendly name, with no other data, conceptually akin to.

Yep, your data model is right on the money here.

Side note: It's fine if you prefer to use SIMIS for illustration purposes, but be aware that it's OR policy not to use it for future formats.

 Genma Saotome, on 08 August 2020 - 11:22 AM, said:

I think we all agree on that... and where there is a spread of opinions is what to do with any additional data that logically could slip into that construct. Examples include origination and destination names for the entire grouping as well as lading names, lading weight, consignee name for indivudual freight units as well as others I suppose.

WOuld you all comment on this please so as to make clear where we all are on this specific question?

In my view, such information would go into a new kind of section or file, call it a "Service," that resembles the consist format but adds additional desired attributes.

{
    "Road": "BNSF",
    "Service": "X214",
    "Priority": "express",
    "List": [
        {
            "Consist": "/ORTS/YoRyan_BNSF_Consists/2xPower.consist-or"
        },
        {
            "Consist": "/ORTS/YoRyan_BNSF_Consists/24xIntermodal.consist-or",
            "Origin":
            {
                "City": "Chicago"
            },
            "Destination":
            {
                "City": "Seattle"
            }
        }
    ]
}