[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"
            }
        }
    ]
}

[YoRyan]

gpz, on 08 August 2020 - 01:52 PM, said:

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?).

Yes!

gpz, on 08 August 2020 - 12:58 PM, said:

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?

Actually, I do agree. Well, I wouldn't use the "Train" keyword, but you could absolutely just infer the type of consist item from its file extension.

{
    "Item": "/MSTS/TRAINS/TRAINSET/acela/acela.eng"
},
{
    "Item": "/ORTS/YoRyan_PrivateCars/SurprisePrivateCar.consist-or"
}

The reason I was trying to abstract away file extensions was to keep the door open for future replacement ORTS formats like .engine-or and .wagon-or, but after familiarizing myself with James Ross's content manager proposals and thinking about the problem myself, I don't think we'll actually need to do this, since we'll be doing away with the MSTS folder structure entirely.

I'll update the spec after giving the matter some more thought.

gpz, on 08 August 2020 - 12:58 PM, said:

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?

To my mind, any construct that deals with the spawning of loose wagons and engines is called a "consist," be it a stringing together of other items ("list consist") or a kind of selection mechanism among alternatives ("random consist"). As has been extensively discussed, "consist" might not be the right word, but it's much more intuitive than something like "vehicle list" or "unit." Regardless, I favor the designation of a single umbrella term for the mechanism.

As for changing types, perhaps you want to introduce a randomization mechanic for one of the sections of your train. I'm sure it will happen all the time.

[Genma Saotome]

You guys are jumping ahead of me a bit... I was suggesting a structure for an ordered list of UNITS, not an ordered list of ordered lists. It may be that with a bit of abstraction everything melts into just one definition but I'm not ready yet to agree on that.

[ErickC]

I think there is some confusion of terms and concepts here.

When it comes to diesel units, the term "locomotive" can be used to describe either a single unit or several units coupled together and controlled from a single cab with multiple unit connections, as EMD outlines in their operator manuals. "Consist" is also the term used by the manufacturers to describe several units coupled together and controlled via MU. Again, the operator manuals state as such. I have met railroaders who swear the term was made up by foamers, and I have met railroaders who use the term extensively.

The constituent units of the locomotive that are coupled to the lead unit are not helpers. Much as model railroading has perpetuated the myth that plain bearings are called "friction bearings," MSTS and OR have perpetuated the myth that units other than the head unit are called helpers. This is, of course, false. Helpers have a very specific definition. Helpers have a separate crew, are generally located at the rear of the train, and are most often used for pushing heavy trains up hills. In the days of yore, coupling and uncoupling a helper locomotive onto a train required switching out the caboose, placing it behind the helpers, and then coupling the helpers to the rear of the train. This was, of course, for crew safety. With the days of the caboose long gone, helpers no longer need to engage in such tomfoolery, and helper sets use devices like HelperLink to read telemetry from the HOT and EOT, which allows them to receive brake data without being physically connected to the brake line, allowing helpers to cut off on-the-fly.

Cabless B units often have a basic control setup so that they can be moved around. Generally, the operator's station has a brake stand, a limited throttle, and an emergency brake valve. I always thought it would be interesting if OR was able to allow for separate controls when a cabless unit is operated from the hostler's station versus operated via MU from a cabbed unit.

Locomotives located throughout the train, and using radio equipment, such as Locotrol - not Locontrol - are not helpers. They are distributed power units, often called DPU for short. Locotrol is the main DPU control system in use in locomotives of all makes, a prime example being CP's infamous Locotrol-equipped SD40-2s. While it is presently a GE product, Locotrol was developed by another company, which GE later purchased. Early Locotrol setups were rather large, and were located in dedicated radio cars. Later Locotrol equipment was compact enough to be included in an extended EMD nose, and is why longer noses on EMD units equipped as such exist in the first place.

[YoRyan]

roeter, on 08 August 2020 - 12:55 PM, said:

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 Random[] type is intended to facilitate this, as well as the Pool[] type, which I am planning but will not work on until after the merge.

The Pool[] type will select one from a set of depleting alternatives. So if you want to go hardcore and model every engine with a unique road number, you could use this type to guarantee that the same engine never appears twice.

[Genma Saotome]

There was a comment earlier, I think from Ryan, that posed a question about my goals here. I could not reply then but can now.

What I have in mind is primarily the role performed by a conductor. I don't know if the same name is used elsewhere but I expect the responsibilities are.

For all of the 19th century, most, if not all of the 20th century, his job is the master of the train. He is responsible for knowing what cars are in his train and where they are to travel. He instructs the engineer for where to place cars or where to pick them up. He instructs the engineer in unusual movements, such as a saw-by. In short, a conductor does what there is in a complex path statement for these movements. And in a Timetable and Train Order environment he gets a copy of every train order, as does the engineer.

If you have no interest in performing the duties of a conductor then the current activity mode of a hand-holding path statement is fine. But if you'd rather be doing that role yourself then you want all those parts of the path statement removed so you can figure it all out on your own. That’s what I had in mind when I was writing about area control.

In this role the conductor-player needs to see the composition of his train (the player does not have a wheel report that shows him this information, nor is he likely to maintain such a document). This is why I was writing about adding certain new information someplace so it can be displayed in a f7 type display.


A secondary goal, somewhat similar, is about working a yard. I need to explain the work before making the argument about why it would be a good feature to address.

When a train comes into the yard and the locomotives and caboose, if present, have been cut off, the Yardmaster is given the waybills for the cars on that train by the conductor. His staff parses the papers, placing then in holders (think shelves for simplicity) that represent the track sin the yard. As they are placed somebody notes which car went where. This is the basis for the instructions given the switch crew that breaks down the train.

A similar process is used to build up a train only this time it is to pull all the cars from this track and then that track, etc, with each pull delivering the cars to a track indicated for building up an outbound train.

In both cases a fully fleshed out path statement could serve as the Yardmasters instruction to the switching crew. But if the inbound train is not already blocked they player may be faced with 4 moves for each car in the train (in, couple, out, in, uncouple, out); I cannot imagine anyone wanting to do that for an 80 car freight train nor can I imagine any Activity creator wanted to create that sort of path. Blocking solves that problem, for both real railroads and ourselves in this sim. A train could be broken down (or built up) with far fewer moves when the cars are in blocks. Once again there is a need for new parameters to hold information about the blocks so the player can see where one block ends and another starts so he can grab the right collection of cars.

There will almost always a handful of loose cars that require a different method of classification, usually empties and cars for local deliveries. These cars need new parameters too so the player can see what the deal is… that this car is empty, these two are for delivery to the south, these 3 to the north, and so on. IMO in this situation it’s another case for avoiding the highly intricate path and instead displaying enough information so the player can figure it out. Data like Consignee() and LadingWeight().

I think adding data to support these roles will increate the variety of things one can do in OR and as they are entirely new expand the realism as well.