[YoRyan]

Good points, Rob. I have updated the master post.

[Genma Saotome]

 YoRyan, on 10 August 2020 - 12:04 AM, said:

All,

I have been giving the your (much appreciated) feedback a lot of thought and have decided to perform a "hard reset" on this project, so to speak, by reformulating the data model. In particular, I think the railcar-attribute system suggested by Dave - just with some tweaks, like not imposing a locomotive/block hierarchy - would represent a more proper evolution of Kuju's consist model. Please read the updated matter in the very first post, which contains my thoughts on how we can generalize railcar spawning to future activity formats, and then feel free to resume this useful discussion.

Very reasonable decision. The change is incremental, not too big, and moves the sim forward.


One more thought on doing this is to wonder about the pro's/con's of enlarging what is contained in the ordered list of units vs. a separate block of data that describes the collection that makes up the control+power collection. At first thought the first approach seems reasonable but the more I think about it the more I think that might be a mistake. More thought is needed.

[R H Steele]

Reading & Watching all you hash this complicated subject out gives rise to two responses from me --- How very little I know about railroading, history of train sims, and data organization, and how lucky this project is to have folks like you that can discuss this issue in such an intelligent and cooperative manner. Kudos to all. Thank you for making this fine simulator better...takes time, effort, and reasoned discussion.

[RR1]

 YoRyan, on 10 August 2020 - 12:04 AM, said:

All,

I have been giving the your (much appreciated) feedback a lot of thought and have decided to perform a "hard reset" on this project, so to speak, by reformulating the data model. In particular, I think the railcar-attribute system suggested by Dave - just with some tweaks, like not imposing a locomotive/block hierarchy - would represent a more proper evolution of Kuju's consist model. Please read the updated matter in the very first post, which contains my thoughts on how we can generalize railcar spawning to future activity formats, and then feel free to resume this useful discussion.

A question which may be outside the scope of this current discussion. Will this new data structure/session concept allow for any given eng or wag file and associated .s file etc., etc. to be stored in only one hard drive location? This "Rolling Stock" directory could then possibly be organized into appropriate sub-directories based on how any individual wants to organize their rolling stock by whatever major attributes they desire. But bottom line, any given set of files defining any given eng or wag need only exist in one location. And then would it also be possible for any given eng or wag file to share common (.s file for example) associated files. I've accomplished something along these lines by using a database approach but would be interested to know if a similar consolidation of rolling stock could be accomplished "out of the box" with this new approach.

[YoRyan]

Yes, that's outside of the scope of a consist replacement proposal, but stay tuned, because I would like to discuss content management next once the dust settles down here.

Personally, I'm envisioning something very similar to what James Ross has previously proposed: a virtual file system that is assembled from multiple ZIP files and directories loaded in sequence. In this way, players and content creators would be able to organize their content into segregated namespaces ("/ORTS/YoRyan_USA1A_Timetable/Timetables/...", "/ORTS/NALW_GenesisPack1/RollingStock/...", "/ORTS/YoRyan_MariasPass5_EmpireBuilderActivities/Activities/...") rather than squeezing it all into a single MSTS data directory. In addition, I have been thinking about how ORTS content should be able to reference MSTS content and vice-versa.

[RR1]

James' proposal link is private. Is there a public version of his proposal?

[cjakeman]

 RR1, on 11 August 2020 - 04:53 AM, said:

James' proposal link is private. Is there a public version of his proposal?

No, but I think it might be better to move the entire thread into the public forum. There are 7 pages of posts from:

• James Ross
• wacampbell
• captain_bazza
• longiron
• roeter
• Genma Saotome
• smmille1
• cjakeman

I will ask them if they mind and then maybe we can get it moved.

[RR1]

Thanks!

[steamer_ctn]

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

Trains contain:

• A dispatcher symbol (if active when spawned)
• A priority class (if active when spawned)
• A maximum authorized speed (if active when spawned)
• A start time or trigger
• A spawn location
• Instructions to perform, such as passenger stops to make, locations to travel to, and pick ups and drop offs to make (unless in explorer mode)
• A sequence of one or more cars and their attributes

Cars contain:

• A reference to the rolling stock definition (.eng, .wag, or future format) to load into the simulator
• A starting orientation (forward or reversed)
• Initial states for pertinent controls, such as the reverser and pantograph
• A starting fuel or water level (for locomotives)
• A starting coal level (for tenders)
• A starting load (for freight wagons)
• An acceleration tolerance (durability) (for freight and passenger wagons)
• Data tag(s) used by by the current active session to specify and track objectives
  • For example, activity sessions might tag certain cars for drop off at a particular siding.
  • Timetable sessions would tag cars for use in $attach and $detach commands, succeeding the current method of associating cars with their originating consists.

For clarity, will each CAR have a separate attribute denoting its authorised speed?

Thus the TRAIN authorised speed could be determined by the minimum speed of the lowest rated CAR in the composition. This would be more in keeping with how I understand that railways determine the speed of a particular train composition.

Having said this, I suspect that different car speed limits may also apply depending upon track or operational conditions. For example, a tender locomotive may have a different speed limit depending upon whether it is moving tender first, or in its "normal" direction.

So perhaps the way to handle this is to have an attribute in CAR which OR can use to calculate the authorised speed limit automatically (In this case the TRAIN speed attribute would not be set by the user). If for some reason that it is necessary to override the default CAR values, then the user could set the TRAIN attribute.


EDIT: Another thought, if a train drops off a CAR with limiting speed attribute, then the TRAIN speed should increase to the new limiting attribute.

[Genma Saotome]

Ok, some thoughts that may or may not be useful for OR, based on some real world situations.

A train is a concept, not a physical thing. Yeah, weird, I know, but bear with me. As a concept it has a purpose -- going from A to B, it may have a name, expected arrival date and time, expected departure date and time for points A and B and it may occur every day of the week, 5 days only, Saturday and Sunday, or some other combination.

Shortly before it's expected departure time a collection of physical units are brought together, The status of each changes from Expect to be included in train ABC to is included in train ABC. IOW they need not be coupled together at any time but when they all are then the status of train -- the concept, changes from pending to ready to depart. An important wrinkle is that it may take two or more sections to complete the train. By section I mean another crew, locomotive, and cars, which for clearance purposes, are the same train.

It trundles along until it gets to the town of Midway where it breaks apart the coupled units, sets out 3, severing their relationship to the train, and picks up 2, Perhaps their status was Expect to be included in train ABC.

The understanding I want to emphasize here is the train does not need to be coupled together at all times, nor is its composition or physical order fixed.

Were this the steam era the train arrives at a division point and the locomotives, caboose, and crew all depart, leaving the cars as-is. It is still train ABC. A new crew, locomotives and caboose show up, attach themselves to the cars and the whole effort is repeated until such time the train arrives at its destination. Only then is it terminated.

A more modern scenario would more likely see only the crew and caboose cut away and a very modern scenario might see only a change of crew.
=========

Now the hard part... is any of that reelvant to OR? IMO very little, other than perhaps a touchstone, but I suspect there is one important notion that's worth looking at: That a train can be broken apart and still remain a train. Perhaps it is a don't care but not being sure myself I'd like to direct the matter to Rob on account os account of some of the functionality in the timetable spreadsheet. So Rob, what are you thoughts on this?