[darwins]

Just another thought for this, how about adding a conditional operator?
Particularly for passenger trains some vehicles were part of the formation on certain days of the week or at certain seasons of the year.
So in MSTS format I might have a consist defined for Mondays only, another for Fridays and Saturdays and another for Tuesday, Wednesday, Thursday - all for summer and another daily for winter.
Then I choose the consist from that list in the timetable or activity. By putting conditionality into a consist file it can link with timetable mode. It can check the day of the week and season of the year with the timetable and adjust the consist accordingly.
I have one consist file for that train instead of half a dozen for one service - timetable and consist sort out which cars to include.

[Csantucci]

I agree that the .con file could be extended to incorporate new features. One of them has been partly mentioned by Dave, and it is related to (OR) freight animations. The presence of OR freight animations could be inserted in the .con file, so that having a single, base .eng or .wag file many variations of the same trainset could be generated in the .con file. This includes both continuous freight animations (like coal, sand and so on) and static freight animations; I'm thinking here e.g. at locomotive numbers (starting from a single locomotive .eng file locomotives with different numbers could be defined), as well as freight like containers, trucks and so on.
Inserting a probability of presence of a trainset, as proposed by Ryan, is also a good idea, which extends very well the activity randomization features.

As can be seen, I have explicitly mentioned .con files. In fact, while I of course I'm in favour on extending file formats, I'm not enthusiastic about changing file formats, if there aren't real advantages for that, that are greater than the disadvantages. To be clearer I don't see a real advantage in writing

"flip": true

instead of

Flip()

while I see major disadvantages: the first ones coming in mind are new consist editors needed, when there are good ones available now, double parser needed within OR (because backwards compatibility should be kept): in the homepage of the OR website we can read

Quote

Open Rails: free train simulator that supports
the world's largest range of digital content.

and I fully support that this should remain.

[roeter]

Interesting points here, a couple of those have been on my mind for a long time and some steps towards it have been set in timetables.
Here's some thoughts on it.

Blocks.
Blocks, or portions, is the way in which trains used to be configured, and sometimes still are. This does not only apply to freight trains, but also to passenger trains which often had 'portions' (or through coaches) to various destinations.
So, the concept of blocks is very important and would be very welcome.
In a sense, the concept of consists being a set of blocks has already been implemented in timetables, as a train can be formed of a selection of consists. Moreover, a wagon always remembers its original consist name, which allows this name to be used in $detach and $transfer commands, even if that wagon has been already been transfered between trains.
If the concept of blocks is introduced in the consist editor, it should be set up and work along the same lines such that the blocks can be referenced in timetable commands.
To allow this in a proper way, the following rules should be applied.

• A block name is unique.
  
• A wagon always remembers its original blockname.
  Perhaps a timetable command could be introduced to set new blocknames, e.g. when trains are reformed or exit from pools.
  
• The relevant commands in the timetable logic must be extended to allow the use of /block additional to the present use of /consist ($detach and $transfer commands).

Random consists
There are, ofcourse, random consist generators, but all these do is create a consist from a random list but once created, that consist is as static as any other.
So, whenever you run a timetable or activity, any trains you encounter always look the same.
For a long time now I have been considering real random consists, that is that the consists are (re-)generated each time you start a new run.
The problem is that this is actually quite complicated.
One concept which I have been thinking about is to use 'placeholder files'. So, when building a consist, you do not select an actual wagon but a 'placeholder'.
Say you want a 40ft box car in your consist.
You may want a specific model, so you then select an actual wagon.
But, perhaps you just want one from a specific company, for which you have multiple models. You can then select a 'placeholder', which is just a list of references to the 40ft boxcars of that company.
Or, you want one from any company in a specific region. In that case, there should be a 'placeholder' which is a list to lower-level placeholders with boxcars per company.
Etcetera - you can have many cross-sections by area, era, type, load or whatever.

The consist is build using these placeholders and when a run is started, the program selects the actual wagons.
Now, each time a new run is started, your freight trains will look different.
Ofcourse, you still can build fixed consists if you want to, e.g. for fixed block trains.

The 'formation' concept mentioned above does point in this direction. If properly set up and worked through, it offers great potential.

New format
I'm very much in favour of setting up a new format with proper definitions for the new features which can be introduced.
Trying to squeeze everything into the existing consist format will only make things more complex. Requiring two parsers is no obstacle, and actually would even be better if backward compatibility is to be maintained - the present parser for the consist files is just left in peace, which guaranties the required backward compatibility. The new parser will allow much more room for new features and experiments, which is essential for real new development.

Regards,
Rob Roeterdink

[cjakeman]

Csantucci, on 07 July 2020 - 12:05 AM, said:

I don't see a real advantage in writing

"flip": true

instead of

Flip()

When writing files by hand, there is no advantage, but mostly files should be written by an editor. The advantage comes in parsing the files, as parsing JSON files is well understood and pretty much bug-free. The same cannot be said for MSTS-format files where bugs still lurk today.

The idea is that MSTS-format files should be translated into the OR formats automatically as needed and the editors should deal only with OR-format files.

[NickonWheels]

Speaking about probability, if there is no in-file dependancy between those two engines you may still have outcomes where both engines are present and those where neither one is present, just as a footnote...

[Hobo]

How would these new additions and changes affect the original consists now used ? Would everything we use now be backward compatible to the new system and would the present Con Editor by Goku still be usable ?

[Genma Saotome]

Something to keep 9in mind: there could be no problem keeping existing .con files and the .con editor so long as there is a conversion program to whatever the new definitions are. Each .con file could be construed as having one locomotive block and one car block as well as be the basis for a new Train file. If the end user wanted to break up that one car block he could do so in an editor or perhaps even the current con editor, creting a new block. A quick edit to the Train file puts everything back together again.

What we get by having that conversion program is the means to introduce new file structures w/o throwing away all of the information contained in the existing structures. Each person could continue to use the currently avaiulable con editor to create something new, run it thru the conversaion program, and use the new file structures in
the game. At some future date a replacement for the curren5t con editor gets developed and hte conversation program could be eventually
depreciated.

In case it is not clear, the rough idea I presented above should be seen as one man's perspective on a goal to work towards, not as The Solution To All Our Problems, much less one large task. To get it closer to a good goal does require itteration and inputs from multiple perspectives. As far as ultimately getting around to implementation, definitions for attributes can be added on one date, loaded with values on another, displayed on a third (or any other combination of dates acceptable to whomever is doing the work, so long as the advance the code towards the goal.

[vince]

Morning Dave,
This is exactly what I lobbied for more than 10 years ago when Open Rails was just getting started; Don't dump the years of development of routes and rolling stock. Make is better and able to be improved!

Like the old saying 'Don't throw the baby out with the bath water.'http://www.elvastower.com/forums/public/style_emoticons/default/bigboss.gif

Regards,
vince

[YoRyan]

Hobo, on 07 July 2020 - 06:14 AM, said:

How would these new additions and changes affect the original consists now used ? Would everything we use now be backward compatible to the new system and would the present Con Editor by Goku still be usable ?

Folks, to be clear, existing .con files will of course continue to be loadable by Open Rails. This is a new, optional format that could be created by hand or by an eventual new consist editor. Having our own format gives us breathing space to be able to experiment with new features, like cross-installation profile loading and data tags.

Whether or not TSRE will support the new features is a decision that is up to Goku.

Genma Saotome, on 07 July 2020 - 07:42 AM, said:

Something to keep in mind: there could be no problem keeping existing .con files and the .con editor so long as there is a conversion program to whatever the new definitions are. ...

What we get by having that conversion program is the means to introduce new file structures w/o throwing away all of the information contained in the existing structures. Each person could continue to use the currently avaiulable con editor to create something new, run it thru the conversaion program, and use the new file structures in
the game. At some future date a replacement for the curren5t con editor gets developed and hte conversation program could be eventually
depreciated.

cjakeman, on 07 July 2020 - 04:27 AM, said:

The idea is that MSTS-format files should be translated into the OR formats automatically as needed and the editors should deal only with OR-format files.

The way I envisioned this, we would keep both parsers around, but have them both load the same (overhauled) TrainCfg data class. Manual conversion would be possible in the new consist editor in the MSTS->OR direction only. But I'm open to criticism on this front, too...

Csantucci, on 07 July 2020 - 12:05 AM, said:

As can be seen, I have explicitly mentioned .con files. In fact, while I of course I'm in favour on extending file formats, I'm not enthusiastic about changing file formats, if there aren't real advantages for that, that are greater than the disadvantages.

As Chris mentioned, the advantage of migrating to a JSON format is that it would be dramatically easier to parse and extend, which is why JSON has been designated as the format of choice for future Open Rails data formats. And observe that if we add our own .con parameters, those .con files would no longer load in MSTS. As Rob put it...

roeter, on 07 July 2020 - 03:13 AM, said:

Trying to squeeze everything into the existing consist format will only make things more complex. Requiring two parsers is no obstacle, and actually would even be better if backward compatibility is to be maintained - the present parser for the consist files is just left in peace, which guaranties the required backward compatibility. The new parser will allow much more room for new features and experiments, which is essential for real new development.

[YoRyan]

Genma Saotome, on 06 July 2020 - 10:40 PM, said:

Starting with Block: In North American practice the concept of Blocks is perhaps 70 years old with most roads adopting it maybe 50 years ago. The basic idea is this: when a train leaves a yard you don't have an apparently random sequence of cars in your train; you have one to n blocks of cars with each block having a specific destination, usually somewhere well across the country but a block could also be the just-before-midnight yard transfer used to avoid per diem payments.. All cars are part of a block, all trains are collections of blocks. Conceptually cars that are handled in-route are, effectively, in an in-route block, or if you will, a loose consist block.

...

First things first - thank you for such a thoughtful proposal. I like the concept of activities and consists setting attributes on wagons. I'd just caution that we need to keep flexibility in mind here - a new consist format can be expected to hold anything from an articulated tram to an ICE trainset to a 100-car North American freight train. And while it would be nice if all of our rolling stock came in shiny new .wagon-or and .engine-or formats that consolidated all of the duplicate road number and loaded/unloaded variations, for the forseeable future, we will have to work with railcars that lack this metadata.

Given all of the feedback so far, it seems to me we need to support the following concepts:

• Blocks and Trains
  
• The "placeholder" concept mentioned by Rob
  
• A means to set parameters that can be referenced by future .engine-or and .wagon-or formats

Genma Saotome, on 06 July 2020 - 10:40 PM, said:

Oh, one last thing, please get rid of loose cars in the Activity file; each individual listing should be replaced by a block specification.

Agreed, but that's a topic for a future Activity Editor. :)