[jonas]

Hi,

I can be wrong, but I have the impression that we are all watching in slow motion on a slowly araising mess about directories and formats of MSTS extending OR files.

• It may be that there are good reasons why the * .trk file in the OpenRails folder needs a blank line at the beginning and begins with "include (" ../___. Trk ")".

• It may be that there are good reasons why the carspawn.dat in the Openrails folder contains a list of CarSpawnItems, but is not called, for example, CarspawnList.dat, because its content differs fundamentally from the carspawn.dat from MSTS and can not just count as an extension. But on the other hand, if it were actually called CarspawnList.dat, it would finally be clear that it represents an new OR format and, according to OR policy, would have to be in the root folder of the route.

• It may be that there are good reasons why there can be another Openrails folder in the MSTS world folder, which contains additional world files with extensions, but which do not need a blank line at the beginning and also not with "include ("..\thisAndThat.w"). Instead, this world extension file begins just like any ordinary world file from MSTS.

• It may be that there are good reasons why the clocks.dat is in the Openrails folder, but the "animated.clocks-or" file generated from it is then in the root folder of the route.

• It may be that there are Open Rails policies that provide for MSTS extensions in Openrails folders and OR own files are to be saved in the root folder of the route.

• It may be that there are good reasons why the turntable.dat is seen differently than the clocks.dat, but I haven't hear any reason why so far (@Chris, you didn't answer me about this in this post :-)).

• It may be that there are good reasons why a user of a route should be forced to switch to a Json file. But if it is obviously possible with an Open Rails converter to convert the clocks.dat at runtime into the Json file animated.clocks-or, then this can always "virtual" happen unnoticed by the user as long as a clocks.dat is already available. After all, we are assured that clocks.dat will always be readable in the future. I think politics is being made here to "educate" the user to use Json formated files, so to speak.

And these points are only the ones that come to my mind on the fly. For example, I'm yet not familiar with Rob's weather files or the moving passengers on platforms by using carspawners etc.

I believe that many of us here have grown with this "OR extension files system" and are reasonably familiar with it, although I also have to keep thinking about where to change something and what to do, for example when I add a new Carspawner list to effect an existing world file.

But with the gaze of someone who only occasionally deals with Open Rails (such as friends of mine), I slowly but surely see a patchwork emerging. The structure of an MSTS route folder, which takes some getting used to for a beginner, is only made more complicated by the various possible locations of additional OR files.

This is not a criticism in the sense of a complaint (to whoever). In fact, I'm just worried that the various peculiarities and directory locations of the additional OR files will still be able to be overlooked in the future.

I guess my opinion is still like very similar to Carlo's, that OR files should only exist in one folder: "Openrails" in the route folder, regardless of whether the files are MSTS extensions or new OR files.

Greetings
Jonas

[R H Steele]

Jonas, much of your post is beyond my knowledge and certainly outside of any meaningful way for me to change...however, I also have wondered about

Quote

"It may be that there are good reasons why the * .trk file in the OpenRails folder needs a blank line at the beginning and begins with "include (" ../___. Trk ")".

-- and about some of the other items you mentioned. Seemed to me to unnecessarily adding complexities. But...as you stated...there may be a reasonable explanation.

[Genma Saotome]

AFAIK the reason is the OR team doesn't want to break MSTS compatibility and so like mushrooms in the spring all sorts of oddities are popping up everywhere because there neither a plan on how to handle this problem or a desire to simply cut the tie to the past by releasing "The Last MSTS Version".

Not having their own editors is part of the problem (note to anyone considering doing anything similar to the big task the OR team took on 10 years ago: Do your editors as early as possible because everything new will spring from that).

A genuinely new simulator (what Wayne wanted to accomplish when he started OR) must have editors that populate the new design plus conversion programs to drag old content into the future. We don't have that and there seems there is little to no probability it will ever happen. Perhaps I'm wrong about that -- I'd love to be corrected.

My bottom line: the OR team has done a fantastic job to modernize MSTS; It's given everyone another 10 years of enjoyment and for that alone they deserve our warmest thanks. But now it's a 2010 product with mushrooms growing out of it.

[cjakeman]

 jonas, on 15 April 2021 - 12:52 PM, said:

In fact, I'm just worried that the various peculiarities and directory locations of the additional OR files will still be able to be overlooked in the future.

Yes, I agree that it's gotten a bit messy, but that's the reason that I am trying to follow the policy with this new type of file and, of course, for new types of file in the future.

[cjakeman]

 Genma Saotome, on 15 April 2021 - 09:04 PM, said:

A genuinely new simulator (what Wayne wanted to accomplish when he started OR) must have editors that populate the new design plus conversion programs to drag old content into the future. We don't have that and there seems there is little to no probability it will ever happen.

That's still our direction of travel - just taking such a long time.

[Amtrak115]

 cjakeman, on 16 April 2021 - 06:18 AM, said:

That's still our direction of travel - just taking such a long time.

I glad to here that's still the direction of travel. One of the reasons I decided to take the plunge and started digging into the trackviewer effort was to understand where we are, and explore some "new" avenues to the future. and as stated in another post, without the capability to create/edit routes, activities, paths, traffic, etc. and in my opinion a capability to import from legacy into new formats is an absolute must have. The discussion on "New Consists" formats that was had several months ago is a good example to "moving" to ...what I'm calling Version 2.0 of OR (I know there are milestones that layout the path and there is even a link on the OR web page to that). We need more discussions such as that to define what the data files of that future version will look like. Then we need the utilities to create and edit those, then the developers of OR can concentrate on this new version rather than keep trying to band-aid 1.x with things that don't upset MSTS. Let me put it this way. if was decided that today, that only bug fixes would compromise anything done to 1.x, and any new features with new formats would only take place in 2.x...I'd be ok with that.

I stated programming back in the Mid '70's. My first job was in the Air Force and there were only a couple of hundred Officers with degrees in Computer Science. Most of the programming I did in the late '70's was in Assembly language of particular computers. (PC's were not invented yet). In one case to support the deployment of Command and Control software for the military, I had to write a "cross-compiler" that would take Jovial code (a Fortran like language that primarily the military used) that ran on Honeywell Mainframes. (think airplane hanger size building that held one computer) and convert that to a program that could run on a "mini-computer" (one 3' x 4' x 6' rack) on an airplane. We were able to deploy this critical software 2 years before any commercially available compiler was available for the mini-computer. The mini-computer had an OS, and that was it. everything else had to be written.

Compare that background with object classes, written in C#, written such that it could executed on multiple platforms, (Pc's, Mac's and Linux), you can get the idea that learning this "new" way of thinking is not a piece of cake. I have a leg up, as I understand programming. but learning a new language c# (not to hard), understanding the architecture of an Open Source effort (Many idea's, Many programmers, who come and go) and from my perspective an uncharted future is somewhat daunting, but I am making progress. To those who are currently developing OR Cjakeman, Genma Saotome, Perpetualkid, to name a few with Dave Nelson trying run herd on them and keep this forum alive, you have my appreciation.

Hopefully, my name will be listed as a contributor in the future.

[cjakeman]

 Amtrak115, on 16 April 2021 - 07:34 AM, said:

Hopefully, my name will be listed as a contributor in the future.

Looking forward to that, Barry.

[jonas]

What more information can be transfered by JSON compared to the classic MSTS STFormat?

(from https://www.ecma-int...dards/ecma-404/)
"JSON is a lightweight, text-based, language-independent syntax for defining data interchange formats. ..."

(from https://www.json.org/json-en.html)
"JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. ..."

Maybe, but not better than the MSTS STFormat! The last sentence is an assertion, at least when you compare it to the readability and writability of the MSTS STFormat.

"data-interchange format" means foremost an interchange between programs or databases as i think. Ideally, people should also be able to read such files, but to write less often.

Compared to the JSON format the superior ease with which one read and write the MSTS STFormat as a human (and not as a machine) is probably clear to me and an important function of these files!

An example:

STF

4
ClockItem( Uhr01_Jm.s analog )
ClockItem( Uhr02_Jm.s analog )
ClockItem( Uhr03_Jm.s analog )
ClockItem( Uhr04_Jm.s analog )

JSON

[
   {
 	"Name": "Uhr01_Jm.s",
 	"ClockType": "analog"
   },
   {
 	"Name": "Uhr02_Jm.s",
 	"ClockType": "analog"
   },
   {
 	"Name": "Uhr03_Jm.s",
 	"ClockType": "analog"
   },
   {
 	"Name": "Uhr04_Jm.s",
 	"ClockType": "analog"
   }
]

Why and when it was decided for Open Rails to prefere the use of JSON format?

What more information can be transfered by JSON compared to the classic MSTS STFormat?

MSTS can rightly be accused of some errors, but not that it chose a complicated interface format between the user and MSTS via external files: the MSTS STF files.

For the past few days I've been scouring the ET forum for previous or current arguments in favor of JSON. Again and again I only came across posts where there was talked of future Open Rails editors, parsers and the willingness of one or the other developer to use one or the other format. Technicians talk about technology, and I'm one of them.
But the external files are not only for cases where, for example, a timetable editor transfers its data to the Open Rails main program! They are the most important human-machine interface files and should therefore not only be somehow cryptically readable, but also easy to write by humans (especially laypeople).

(By the way, what format are the timetable files *.timetable_or in the folder OpenRails in the activity subfolder? :-)

For me, this means that one Type of brackets, spaces, apostrophe, indentations (tab key) and line breaks are enough symbols. I can easily think of content for an STF file, in the broadest sense with normal text, comparable to such texts as in literature or newspapers (depents of the paper you read of course :-). That hierarchical assignments is be represented by nested brackets is at least familiar to most people from mathematical notations. In any case, you don't have to know any programming language to read an STF file. Most of the time, it is intuitively understood from within itself.
In the JSON format, on the other hand, we are dealing with at least two types of brackets, with additional punctuation marks such as the colon and the comma next to the apostrophe or with the annoying expectation of a comma at the end of lines, but not for all lines.

So here (repeated :-) my simple question that I haven't found answered in the posts I have looking up so far:

What more information can be transfered by JSON compared to the classic MSTS STFormat?

[Genma Saotome]

I don't know beans about .json but that said I'd be surprised if it found this phrasing to be unacceptable:

[
{ "Name": "Uhr01_Jm.s", "ClockType": "analog" },
{ "Name": "Uhr02_Jm.s", "ClockType": "analog" },
{ "Name": "Uhr03_Jm.s", "ClockType": "analog" },
{ "Name": "Uhr04_Jm.s", "ClockType": "analog" }
]

That's not far off of SIMIS and IMO has the advantage of including the name of each parameter. OTOH if it must be formatted as you described it, above, yeah, that's a PITA.

FWIW I routinely convert MSTS multi-line data to single line format. MUCH easier to read and it moves over to excel very easily. A randomly selected example from the tsection.dat file:

TrackShape ( 30557 FileName ( SR_XtCrv_w_00340r05dB.s ) NumPaths ( 1 ) SectionIdx ( 5 0 0 0 0 30054 30054 30054 30054 30054 ) )

[jonas]

 Genma Saotome, on 16 April 2021 - 08:25 PM, said:

... I'd be surprised if it found this phrasing to be unacceptable:

[
{ "Name": "Uhr01_Jm.s", "ClockType": "analog" },
{ "Name": "Uhr02_Jm.s", "ClockType": "analog" },
{ "Name": "Uhr03_Jm.s", "ClockType": "analog" },
{ "Name": "Uhr04_Jm.s", "ClockType": "analog" }
]

ok, then I'll be clear here again: unacceptable is a big word, but compared to the STF, it is not acceptable for me for the reasons mentioned above. It is a deterioration in readability and makes it difficult to write, especially for people who have little to do with programming.

Note that there is no comma after the last }. What happens if a user also puts a comma there because he thinks it has to be like in the other lines? Does the parser then have a read error?

It can also be written in STF like this without all the colon, comma, apostrophe and two types of brackets:

ClockItem ( Name (Uhr01_Jm.s ) ClockType ( analog ) )
ClockItem ( Name (Uhr02_Jm.s ) ClockType ( analog ) )
ClockItem ( Name (Uhr03_Jm.s ) ClockType ( analog ) )
ClockItem ( Name (Uhr04_Jm.s ) ClockType ( analog ) )

I can be wrong, but where is the additional information contained in JSON format here.

I don't mean the question in my last post above as a rethoric one, so once again:
What more information can be transfered by JSON compared to the classic MSTS STFormat?