OR consist format Let's talk details
#11
Posted 06 July 2020 - 11:18 PM
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.
#12
Posted 07 July 2020 - 12:05 AM
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
the world's largest range of digital content.
and I fully support that this should remain.
#13
Posted 07 July 2020 - 03:13 AM
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
#14
Posted 07 July 2020 - 04:27 AM
Csantucci, on 07 July 2020 - 12:05 AM, said:
"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.
#15
Posted 07 July 2020 - 05:32 AM
#16
Posted 07 July 2020 - 06:14 AM
#17
Posted 07 July 2020 - 07:42 AM
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.
#18
Posted 07 July 2020 - 09:25 AM
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
#19
Posted 07 July 2020 - 09:49 AM
Hobo, on 07 July 2020 - 06:14 AM, said:
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:
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 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 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:
#20
Posted 07 July 2020 - 10:10 AM
Genma Saotome, on 06 July 2020 - 10:40 PM, said:
...
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:
Agreed, but that's a topic for a future Activity Editor. :)