[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. :)

[Genma Saotome]

 YoRyan, on 07 July 2020 - 09:49 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...

Up to you programmers but if I was on your side of the fence I would complain. Would it not be better to have the code act upon the new formats ASAP so the old objects and methods could be depreciated? That way maintaining things would be as it is now: just one way of doing things.

It's up to you guys... but it is also your time in play.

[YoRyan]

The simplest method that I can see is to extend the TrainCfg class with the data fields and functionality we want, and then to write a parallel parser for the JSON format. This is a much simpler task than one might assume due to the ease of working with JSON.

* With the caveat that my assumptions could be completely wrong, and circumstances might well change once I start writing code. :)

[Genma Saotome]

If it will help any, an example using the SIMIS file type (only because I know how to do that)
Train (

TrainUiD ( Int )
TrainName ( string )
MaxVelocity (default values; could be replaced by Activity process data )
TrainClass ( string: 1 to 5 plus Extra )
TrainDirectionOfTravel ( string -- East, West, North, South )
BlockList

Block (

BlockUiD ( Int )
BlockFileName ( String ) <--- I am assuming all of these files are in the same directory
BlockOrder ( 1 )

)
Block (

BlockUiD ( Int )
BlockFileName ( String )
BlockOrder ( 2 )

)
Block (

BlockUiD ( Int )
BlockFileName ( String )
BlockOrder ( 3 )

)

)

)

BlockFile (

BlockName ( (default values; could be replaced by Activity process data )
BlockOrigin ( (default values; could be replaced by Activity process data )
BlockDestination ( (default values; could be replaced by Activity process data )
Roster (

Uid ( int )
Path ( string )
FileName ( string )
RosterType* (

RosterTypeName (Engine, Wagon, etc. ) <-This identifies what specialized attributes to expect next, if any.
LadingName (String )
MassLading ( real, Unit of Measure )
ConsigneeName ( string)
ConsigneeLocation ( string )

or

FuelLevel ( real )
WaterLevel ( real )
etc.

)

Uid ( int )
Path ( string )
FileName ( string )
RosterType ( [indent]
<relevant data for this entry>

)
etc.)
)

)


It should be fairly clear what .con file data migrates to either Train or Block files. Anything new is mostly for information to display in-game. The exception is MassLading() which would necessitate calculating Davis A, B, and C in the program as well as adding MassEmpty() and DavisFormulaID() to .engs and .wags. The effect of doing this would be to transform most rolling stock to an empty status with final mass determined by either default values in .wags and .engs or variable values from the Activity process. This normalizes the data to more closely reflect real world railroading.


* RosterType may be a very poor choice for a name; What I'm getting at here is to identify what kind of rolling stock appears in the next block of data -- locomotives, freight cars, passenger cars, anything else that comes to mind where each one of those types may present a unique set of attributes tot he program specific to that type.

[Genma Saotome]

 YoRyan, on 07 July 2020 - 12:53 PM, said:

The simplest method that I can see is to extend the TrainCfg class with the data fields and functionality we want, and then to write a parallel parser for the JSON format. This is a much simpler task than one might assume due to the ease of working with JSON.

* With the caveat that my assumptions could be completely wrong, and circumstances might well change once I start writing code. :)

Sounds like there could be a two step effort here: A conversion of some number of existing file types to .json and a migration from the KUJU data content to whatever new content is wanted for a future OR.

[YoRyan]

Will update the original post as I evolve the proposal, as I have just done. Removed recursion as it seems too complex for correspondingly little gain.

Dave, the properties you propose seem better suited to a new activity format. Activity designers would want to control things like fuel and cargo levels. There are no doubt some data tags that belong in the consist format, but perhaps not very many, since a single consist can expect to be spawned many times during the same session.

[Genma Saotome]

 YoRyan, on 09 July 2020 - 12:43 AM, said:

Dave, the properties you propose seem better suited to a new activity format. Activity designers would want to control things like fuel and cargo levels. There are no doubt some data tags that belong in the consist format, but perhaps not very many, since a single consist can expect to be spawned many times during the same session.

I agree entirely.

The issue here is whether or not there is utility in having defaults and if so will the task of over-writing them be an acceptable process. Not having defaults means all of that data needs to recorded in the Activity file area yet those files would only up updated (or append) data to other objects. IMO this really needs a GUI based editor driving transactions -- Pick a train from this list (a routine step), ok now here is the list of locomotives and the attributes you might want to (must) provide new values, here is the list of cars in that train etc, etc, here is the next train.... Defaults could greatly minimize that task. Or not. At this stage it is hard to tell. In this case my role is to put the question on the table.

FWIW, some time ago Chris and I discussed using .inc files to alter a .con file as it is read into the loader. I think it is in the developing features forum. It might be a more straightforward way to accomplish things and a different .inc could be specified for each spawning..

I suppose the second factor to consider is which object inside the program will all of those variables newly added to activity file wind up? I suspect in places like the train, engine and wagon objects. That doesn't require the same attributes to also be in the original flat files but there might be some good-enough reason to have them.

[YoRyan]

Okay, I think I've worked out how randomized player consists should interact with the launcher. Basically, we give the player a choice of lead locomotive, and then go from there.

Hopefully I'll be able to start writing some code soon.

[Genma Saotome]

Ryan, does the team already have a SIMIS to .json translation utility?

[YoRyan]

We do not. You could write a 1:1 translator that copies the exact property names and values, but that would be pointless without a functional loader, or knowledge of what the native OR formats would look like. It might make sense for .eng, .wag, .sd, and route definition files, which we probably wouldn't alter substantially, but in the case of .con, I plan to drop certain Kuju fields and relocate some others. That would need to be explicitly programmed into a translator; a one-size-fits-all-SIMIS-files approach is not suitable.

It's like trying to convert your old records to XML when you haven't even defined the new schema.

[Genma Saotome]

I was thinking more along the lines of taking files I know and then looking at what they look like in .json.

These days I can struggle and maybe accomplish some simple things in Ruby but that's about it. SQL and data modeling remain very strong.