Elvas Tower: OR consist format - Elvas Tower

Jump to content

Posting Rules

All new threads will be started by members of the Open Rails team, Staff, and/or Admins. Existing threads started in other forums may get moved here when it makes sense to do so.

Once a thread is started any member may post replies to it.
  • 24 Pages +
  • « First
  • 4
  • 5
  • 6
  • 7
  • 8
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

OR consist format Let's talk details Rate Topic: -----

#51 User is offline   NickonWheels 

  • Conductor
  • Group: Status: Active Member
  • Posts: 327
  • Joined: 05-December 19
  • Gender:Male
  • Simulator:ORTS
  • Country:

Posted 21 July 2020 - 07:24 AM

 darwins, on 21 July 2020 - 06:29 AM, said:

1. Steam locomotives with tenders need to be defined as a single unit = Loco1 or whatever - no point have loose tenders... (Not forgetting articulated locomotives or master and slave diesel units...)


Indeed there are many real and modelled articulated steam engines (also some diesels and electrics) but ORTS can only handle them like have an engine without tender up front and then another with tender in the rear position; and both operate independantly. This is terribly unrealistic though having a new consist format can encourage to split the characteristics of an articulated locomotive to their resprective parts.

For example something like a BigBoy only has adhesive weight and two cylinders on the front section while the rear has this as well but also the boiler (stuff like ORTSEvaporationArea etc.), if they work in some kind of dependancy laid out possibly by such consist format plus obviously the tender all those folks enjoying such locomotives (or like to enjoy as currenty it´s messy) would have something at their hands. There may be other bugs regarding steam locomotives but this feels like the elephant in the room...

#52 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,350
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 21 July 2020 - 09:30 AM

I too have had frustration w/ multiple models necessary to make up one locomotive. Tim Muir's very fine MILW electrics won't work in OR because activating the air pump only works for the lead unit. The other three units remain offline due to multiple .wags necessary for each unit. The problems described both here and above has been kicked around for years and it seems there are enough combination of problems and parts as to intimidate everyone thinking about solving this mess. A real shame.

#53 User is offline   NickonWheels 

  • Conductor
  • Group: Status: Active Member
  • Posts: 327
  • Joined: 05-December 19
  • Gender:Male
  • Simulator:ORTS
  • Country:

Posted 21 July 2020 - 10:38 AM

 Genma Saotome, on 21 July 2020 - 09:30 AM, said:

I too have had frustration w/ multiple models necessary to make up one locomotive. Tim Muir's very fine MILW electrics won't work in OR because activating the air pump only works for the lead unit.


Well Dave, there is indeed no satisfactory solution for this. I rebuilt the MILW electrics and on part of the EF-4s the bogie sections are .wag files in order to have the center part to be the real engine. One downside of this is that the bogies have different wheel diameters but .wag files only know one kind of this. Maybe it is a shame such things slip through many fingers without much consideration... Because crafting such models in multiple pieces is not a bad idea, ORTS is just quite late upon linking them together, which I think is something that cannot be done by simply deploy a new consist format. This is one problem too big for an easy solution...

#54 User is offline   YoRyan 

  • Conductor
  • Group: Status: Active Member
  • Posts: 391
  • Joined: 19-February 20
  • Gender:Male
  • Location:California, United States
  • Simulator:Open Rails/unstable
  • Country:

Posted 21 July 2020 - 10:40 AM

I suggest that the way to handle articulated locomotives is to extend the engine format to support articulated locomotives. If a steam locomotive and its tender are inseparable, then they should appear in the consist editor as a discrete unit. It makes little sense to define these kinds of constraints in the consist file.

 Genma Saotome, on 21 July 2020 - 09:30 AM, said:

The problems described both here and above has been kicked around for years and it seems there are enough combination of problems and parts as to intimidate everyone thinking about solving this mess. A real shame.

I mean, I'm glad to see yourself and everyone else bringing these issues up, but I wonder if we might be having unreasonable expectations of what the consist/wagon list can do. It's not a SQL database of every conceivable piece of railroad equipment. It's not supposed to define how steam locomotives consume coal. In every other train simulator - MSTS, Trainz, Rail Simulator/RailWorks/Train Simulator, Run 8, Zusi, BVE, World of Subways, Tram Simulator - the "consist format" is nothing more than a list of wagons and/or engines that can be repeatedly and predictably spawned. That's it. The exception is Train Sim World, which includes a probabilistic substitution feature that the "Random" consist in my proposal is modeled after.

So let's all think carefully about the problems we'd like to solve and decide which parts of the simulator are best suited to tackle them. I know it's exciting to have our first native data format, but it's just one piece of the puzzle.

#55 User is offline   YoRyan 

  • Conductor
  • Group: Status: Active Member
  • Posts: 391
  • Joined: 19-February 20
  • Gender:Male
  • Location:California, United States
  • Simulator:Open Rails/unstable
  • Country:

Posted 21 July 2020 - 10:46 AM

 Genma Saotome, on 21 July 2020 - 09:30 AM, said:

Tim Muir's very fine MILW electrics won't work in OR because activating the air pump only works for the lead unit. The other three units remain offline due to multiple .wags necessary for each unit.

By the way, what's the reasoning behind this behavior? It would seem to violate our stated objective of MSTS compatibility.

#56 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,350
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 21 July 2020 - 08:02 PM

AFAIK it is caused by having multiple .wags between the several .engs. T%he lead unit behaves as it should. When you need to pump up the brake line the trailing air pumps do not activate. That's all I know. I suppose it could be something in the .eng files that is improperly coded but I don't know what that might be. Having only 1 of 4 air pumps working makes it hard to run things on a mountain railroad.

#57 User is offline   cjakeman 

  • Vice President
  • PipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 2,866
  • Joined: 03-May 11
  • Gender:Male
  • Location:Peterborough, UK
  • Simulator:Open Rails
  • Country:

Posted 22 July 2020 - 10:30 AM

 Genma Saotome, on 20 July 2020 - 06:04 PM, said:

Rather than carrying a name along from MSTS days it would be better to leave it behind -- and do so with as many of them as possible so when the old word gets used in conversation or code everyone knows it means only the KUJU definition. THAT is why I recommend Train and Block over consist, that is why I think Operation should replace Activity, .fcar and .pcar replace .wag. Hanging on to obsoleted names impairs understanding and leave to door wide open to making mistakes. One is not going to make a typo with .Block, nor misunderstand on receiving that file that it will not be the same as if it were .con; The name and all of its contents are new.

Very sensible observation, Dave. Agree wholeheartedly.

#58 User is offline   R H Steele 

  • Executive Vice President
  • PipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 3,438
  • Joined: 14-March 13
  • Gender:Male
  • Location:known universe
  • Simulator:Open Rails
  • Country:

Posted 22 July 2020 - 11:33 AM

Quote

Rather than carrying a name along from MSTS days it would be better to leave it behind -- and do so with as many of them as possible so when the old word gets used in conversation or code everyone knows it means only the KUJU definition. THAT is why I recommend Train and Block over consist, that is why I think Operation should replace Activity, .fcar and .pcar replace .wag. Hanging on to obsoleted names impairs understanding and leave to door wide open to making mistakes. One is not going to make a typo with .Block, nor misunderstand on receiving that file that it will not be the same as if it were .con; The name and all of its contents are new.

Re: Leaving behind the Kuju definitions and concepts ( con, eng, wag, etc. ) and start using new definitions for OR is eminently sensible and logical. The benefits of a clear distinction in terminology between MSTS and OR should be obvious to all. I don't understand what the discussion is about...just start using these.fcar; .pcar; Block; Train; Operation for Activity, perhaps shortened to ".ops" for .act. If there's gonna be a vote...I know which way I'm voting.


#59 User is offline   YoRyan 

  • Conductor
  • Group: Status: Active Member
  • Posts: 391
  • Joined: 19-February 20
  • Gender:Male
  • Location:California, United States
  • Simulator:Open Rails/unstable
  • Country:

Posted 22 July 2020 - 01:37 PM

I agree that it would be good to dispense of this ambiguity. So how do you all feel about adopting the term "Wagon List" instead? The new file extension would be .wagonlist-or rather than .consist-or. Timetables already refer to instantiated wagon lists as "trains"; a new activity - err, operation file format would do likewise.

This change, by the way, would require a substantial overhaul of the manual, which is currently littered with "consist."

#60 User is offline   conductorchris 

  • Vice President
  • Group: Status: First Class
  • Posts: 2,345
  • Joined: 24-March 10
  • Gender:Male
  • Simulator:Open Rails - MSTS
  • Country:

Posted 22 July 2020 - 04:23 PM

Regarding terminology:
"Block" is an American freight term that does not even carry over to passenger operations. Trains that split to different destinations have "sections" rather than blocks. Actually, I don't even think block is a universal term as I've heard "classifications" used as well. Some term that denotes a sub-consist makes sense to me and "section" does carry that meaning more than "block".

"consist" isn't even an American railway term in the freight railroad world - it is more common among railfans and model railroaders and often refers only to the engines. In the old days railroads had "consist books" for passenger trains, listing the equipment regularly assigned to each train. Still, I googled it and the dictionary definition does say: "a set of railroad vehicles forming a complete train"

According to wikipedia, the UK equivalent of "consist" is "formation", "set", "set", or "unit. It also says that "trainset" is equivalent to "consist," which I think is only true in the passenger train world. Looking at the way wikipedia has it laid out (https://en.wikipedia...ology_in_Europe) it would seem that our use of the word "consist" should really be "train".

I'm going to propose that we call the new format "train" (instead of consist or wagon-list).

It seems clearer, simpler, more prototypical, more descriptive and more accessible to beginners.

I'm going to further propose that we use the term "section" or "set" for the consists/loose consists/blocks, etc that are included into a train. And of course a train can include sections, other trains and engines and wagons as specifically defined or randomized in the "train" file. (when you think about it, this all makes sense and corresponds to real operating practice. For example imagine when a rush hour commuter train breaks down. Standard operating procedure is for another train to couple onto it and proceed. From an operations perspective, the two trains now become one train with one designation.)

I would suggest it would be useful to have "section" files as a separate format designation even if the format is identical to the "train" file, because it helps the user keep track of the difference in purpose.

"set" might be a better name than section because it conveys the meaning of a set of equipment that could be reused over and over for different trains. Block and set are not identical concepts, but are close enough that they could be conflated into one format.

There is a third file type we should specify and that is the list of equipment to be drawn from when a "train" or "set" calls something random. That file would have a list of wagons or engines and (like the others) a comment field. Open rails should be able to check if the selected wagon or engine is present in the TRAINSET folder and make a different choice if it isn't, so we can make long lists of possible cars that will still work if people can't or don't want to download all required stock.

In American usage, the word for equipment assigned to a specific use is "pool". I think that might be a bit of an esoteric term, unfriendly to newcomers. I'm not sure what else to call it though.

Ryan, I continue to be very excited by your work here. Thanks for taking it on.

Christopher

  • 24 Pages +
  • « First
  • 4
  • 5
  • 6
  • 7
  • 8
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users