[cjakeman]

 Genma Saotome, on 18 April 2021 - 11:30 AM, said:

Pretty much as Jonas says, there is no apparent benefit to end users so it should not cost them anything to have it adopted.

Agreed. There is no apparent benefit to end users and it does not cost them anything either.

There is just a one-time conversion but only for those few people who have already created their own clocks.dat file. Nobody else will be affected.

[Genma Saotome]

 cjakeman, on 18 April 2021 - 01:28 PM, said:

No. JSON is a free format, meaning that spaces and new lines are not required. Use them as suits you.

Thank you for the information, I think in many cases fewer lines may be easier to adopt.

[Genma Saotome]

 cjakeman, on 18 April 2021 - 01:33 PM, said:

Agreed. There is no apparent benefit to end users and it does not cost them anything either.

There is just a one-time conversion but only for those few people who have already created their own clocks.dat file. Nobody else will be affected.

I was actually speaking of ALL stf files going over to .json. There are plenty that end users won't care about, world files for one (tho I know that will hit me), .sd for another, but once the conversation turns to .wags and .engs, .con files and the like there will probably be considerable resistance.

[jonas]

 jonas, on 18 April 2021 - 07:03 AM, said:

...But we have now landed here, where two (sorry) extortionate dialogues pop up before the activity starts. ...

 cjakeman, on 18 April 2021 - 10:28 AM, said:

...but this process takes place only once. Next time you run the route, the file is in place so the dialogues are skipped. ...

 jonas, on 18 April 2021 - 11:35 AM, said:

And in wich file the user then have to add further clocks? clocks.dat (STF) or animated.clocks-or (JSON)?

After a few tests, I can now answer the question myself: Better not in the Clocks.dat, because when I make a further change there, the two dialog boxes keep popping up again and again.
This is user education at its finest. After a change in the clocks.dat (STF), two dialog boxes always appear which must be confirmed with OK. On the other hand after an alternative change in the animated.clocks-or (JSON) no dialog boxes appear - according to the principle: electric shock or treats :-).

@Chris (and maybe also James), ​​I understand that it is actually meant nicely and was certainly quite complex to implement, not to exclude the few users who already used the clocks.dat (STF), because the official version is supposed to the goal that only the animated.clocks-or (JSON) should play a role.

But it was said about an offer to the user to convert the clocks.dat (STF) into the animated.clocks-or (JSON). Now pressure is exerted via dialog boxes not to use the clocks.dat (STF) any more. Either the user accept the animated.clocks-or (JSON) build when starting an activity or the clocks will not be animated; the dialog box says this in its last line.

Files like the clocks.dat (STF) and the animated.clocks-or (JSON) are one-way datatransfers. The user writes them, OR reads them ... and OR will always be able to read STF, right?
For the future, when only user-editors will edit the external files, the clocks.dat (STF) is obsolete anyway and nobody will miss it - automaticly! It will fade into insignificance even if it still exists in the route as a silent file witness of earlier days. But until then there is no need to train the end user on JSON first, while we ourselves do not yet know exactly when the editors will come.

(By the way, in the current version, an existing animated.clocks-or (JSON) is always evaluated by OR and the clocks will be animated, even if you click "No". I see this as a bug.)

Why should the old-fashioned user who would rather use the clocks.dat (STF) than the animated.clocks-or (JSON) be aware of the build of the animated.clocks-or (JSON)?
At the moment, both file formats are possible ... and that's great! We could even advertise it! It speaks for an application if it can process several formats, doesn't it?

That doesn't necessarily mean that we prefer the classic ST format and have changed the policies.

If OR might "quietly" build the animated.clocks-or (JSON) at the start, the end user doesn't need to know.

Finally, it would be best to leave it up to the user whether he provides one or the other format. OR would only have to give preference to the JSON file if both file types exist at the same time. And then a dialog box would really be appropriate here. It would tell the user that both a clocks.dat and an animated.clocks-or were found and therefore OR will continue to use the animated.clocks-or. That would lead the user to remove one of the two files, whichever is more important to him.

Am I go wrong to see it this way?

[cjakeman]

 Genma Saotome, on 18 April 2021 - 02:21 PM, said:

I was actually speaking of ALL stf files going over to .json. There are plenty that end users won't care about, world files for one (tho I know that will hit me), .sd for another, but once the conversation turns to .wags and .engs, .con files and the like there will probably be considerable resistance.

I'm sure you're right.


New types of file will be JSON but we have no plans to remove the ability to read STF files. Open Rails will continue to read .ENG and .WAG files.

[vince]

 cjakeman, on 19 April 2021 - 04:54 AM, said:

I'm sure you're right.
New types of file will be JSON but we have no plans to remove the ability to read STF files. Open Rails will continue to read .ENG and .WAG files.

Thank you for that!

vince

[YoRyan]

Chris, I'll echo my comments that I submitted on GitHub:

Quote

As I see it, there are two reasons to introduce a new JSON format:

1. We're introducing a new data format that has no STF equivalent.
2. We're writing a new content editor, in which case it would be counterproductive to write to STF. But such an editor could support importing STF files from MSTS, in which case the editor itself would function as an STF to JSON converter. (The path editor included in the Track Viewer, which both reads and writes STF, was a missed opportunity to demonstrate this kind of workflow.)

This clock format clearly falls under category 1. My preference, which I don't know how Jonas would feel about, would be to remove the STF code and use JSON exclusively for this new format. Failing that, we could retain support for both STF and JSON clock formats. But I don't see any room here for a conversion process.

Having just taken a look at the code, I've just discovered the prompt to convert from STF to JSON when launching Open Rails. And I have to agree with Jonas here: I don't think this is something we should be bothering players with. This kind of tool is really for content creators, the guys who have Blender, Photoshop, and Notepad++ installed and upload content to trainsim.com.

So, to repeat my previous position, I'd prefer to just drop support for clocks.dat entirely. This is a brand-new feature that hasn't even landed in the testing channel yet, so I don't believe there should be too many animated clocks out there? If there is an extenuating reason to keep support for the format (but remember, there's a cost to doing that, too, including testing and debugging code that will gradually fall out of use going forward), then we can do so, and also retain your converter program. But I'd like to see a reduced emphasis on it.

Jonas, what is your opinion on dropping STF in this case?

[jonas]

 YoRyan, on 19 April 2021 - 12:03 PM, said:

Jonas, what is your opinion on dropping STF in this case?

Hi YoRyan,

First, the answer: I find it difficult to guess how many people are now using the clocks. My guess a few days ago to Chris was maybe no more than 5 to 8 based on this thread? But may be it is too optimistic. And luckily I haven't finished my next UpDate of my Route AddOn yet. The clocks should then run in there. So I personal would be able to handle a file format changing.
For me the clocks have been a topic for 2 - 3 years, so my subjective impression is eventually wrong anyway :-)
My opinion on dropping STF I have expressed here in the last post of mine:

Quote

Finally, it would be best to leave it up to the user whether it provides one or the other format. OR would only have to give preference to the JSON file if both file types exist at the same time. And then a dialog box would really be appropriate here. It would tell the user that both a clocks.dat and an animated.clocks-or were found and therefore OR will continue to use the animated.clocks-or. That would lead the user to remove one of the two files, whichever is more important to him.

Maybe my last posts here in the thread lead to a wrong impression as far as my motivation is concerned. Personally, I can handle JSON. I find too much punctuation marks are used, but I can understand the criticism of the ambiguity of the STFormat. I am basically concerned with the end user who might be forced to use only JSON files in the future.



And second (the continuation of the next novel chapter, please skip if you fed up reading :-):
In my opinion, there is no standardized MSTS ST format at all, because with almost every dat, wag and eng file (and what they are all called) you always have to know in advance in which order the data is arranged in it. Each STF file has its own format. And files like "sigscr.dat", which also have the suffix dat, can hardly be understood as an ST format in our MSTS sense, rather as an external C file.
I see and therefore even welcome a more unambiguous file format, such as the json format, in which each date is provided with an identifier.

And at the same time I think it's maybe a bit of a shame that we (OR) didn't define our own format, a kind of hybrid format that combines the advantages of STF and JSON. Like JSON, consistently with an identifier in front of each date and only brackets as punctuation marks as in the STF, a kind of hybrit format this way:

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

instead of this:

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

It is clear to me that JSON with its two different brackets complies with the inheritance syntax of many object-oriented programming languages. But here I think that it should be left to the parser to assign them to program objects instead of expecting the user to use the correct bracket.

About the clocks.dat: As mentioned in my previous post, files like the clocks.dat or the turntable.dat are one-way data transfers from the (end) user to the application. In my opinion there is absolutely no reason why OR should ever write a clocks.dat or animated.clocks-or. Here the user wants to tell the application which clocks or turntables are available, not the other way around. And we (OR) will always be able to read STF. So why not the clocks.dat?
And if there should ever be editors for external files, they can be able to also read both, depending on which format the user has ready.

I think the argument of the amount of code for reading in is very smart, YoRyan, but it seems a bit 80s style to me when it comes to RAM limitations :-). But maybe I am wrong here and overlooking future devices with a lack of memory, such as cell phones or notebooks or playstations, etc. After all, the code for reading STF will always remain in OR.

My current state of knowledge on the subject of JSON files is:
The criterion that basically new OR files can only be introduced in JSON is wrong (only my opinion, no emphasis). Rather, I would say that new OR dual-way files are to be written in JSON (or in the above-mentioned own OR hybrid format), but the format of one-way files is decided by the user, at least with one-way files that are readed by OR only once while an activity start.

I hope this was now with less emphasis, in spite of the details again, all the writing here is exhausting for me too. I hope I've been reasonably factual and have been able to express all of my thoughts on the subject here and in the last few posts.

Best wishes
Jonas

[YoRyan]

You need special code and classes to handle any new STF format, including clocks.dat. So there is a cost - in terms of developer time and manpower, our most precious resources - to keeping it around, which is preferable to avoid.

An additional advantage of JSON files is that they can have schemas, which are constraints on the type and subset of values you can input into JSON fields. Text editors can read schema files and enforce these constraints. So with JSON, you basically get a proper editor for free. Needless to say, this is not possible with STF, let alone with whatever homebrew data format our developers (who, again, have limited free time) could come up with.

So, let's look at this from another angle. I'm currently planning a new consist editor that will allow, among other things, randomly generated trains. This editor will read and write JSON files. STF? Not a chance. It would cost me precious hours to custom-build an STF reader and writer, whereas JSON support is built into C# and it would take only a few minutes for me to implement reading and writing. That's JSON's real value-add, the ease with which it lets you get programming work done, not the subjective beauty of its syntax.

This is why I've stopped getting involved in these file format discussions - they're long-winded, they lead nowhere, and are irrelevant at the end of the day, because what's important is the new editor and its capabilities, not what the curious player sees if he or she happens to open one of the files it produces in Notepad.

[jonas]

Hi YoRyan,

 YoRyan, on 19 April 2021 - 04:28 PM, said:

You need special code and classes to handle any new STF format, including clocks.dat. So there is a cost - in terms of developer time and manpower, our most precious resources - to keeping it around, which is preferable to avoid.

I know what you are talking about, for example I have coded the "ExtClocksFile.cs" that reads the STF clocks.dat.

 YoRyan, on 19 April 2021 - 04:28 PM, said:

An additional advantage of JSON files is that they can have schemas, which are constraints on the type and subset of values you can input into JSON fields. Text editors can read schema files and enforce these constraints. So with JSON, you basically get a proper editor for free. Needless to say, this is not possible with STF, let alone with whatever homebrew data format our developers (who, again, have limited free time) could come up with.

That's why I asked "What more information can be transferred by JSON compared to the classic MSTS STFormat?" I didn't know this aspect about the schemas before.

 YoRyan, on 19 April 2021 - 04:28 PM, said:

So, let's look at this from another angle. I'm currently planning a new consist editor that will allow, among other things, randomly generated trains. This editor will read and write JSON files. STF? Not a chance. It would cost me precious hours to custom-build an STF reader and writer, whereas JSON support is built into C# and it would take only a few minutes for me to implement reading and writing. That's JSON's real value-add, the ease with which it lets you get programming work done, not the subjective beauty of its syntax.

Nobody, including myself, demands that such files you describe be written in STF now and in the future. I would even appreciate it if such json files were compressed and not openable at all by the end user. But this maybe a new CPU time and manpower issue again.

 YoRyan, on 19 April 2021 - 04:28 PM, said:

This is why I've stopped getting involved in these file format discussions - they're long-winded, they lead nowhere, and are irrelevant at the end of the day, because what's important is the new editor and its capabilities, not what the curious player sees if he or she happens to open one of the files it produces in Notepad.

Such a strict and one-sided statement as I am reading here amazes me, where the results of a discussion be anticipated and the subject of discussion is attempted to limit.
I hope I've always tried to consider both sides in my posts - admittedly, primarily that of the end user, but also the side of the developer.
I am not interested in "subjective beauty" or similar lapidary things and it is definitely not my intention to annoy you or others here in such a way. I'm really sorry and I apologize for causing this - I hope you can accept that.
I have now learned that the schemes in JSON format represent a real superiority over the STF format and that the coding of STF readers wears out manpower, which is of course a rare resource in a spare time project.
I can only assure you once again that my last posts were not about provocations, but actually about the end user (the curious player, who I sometimes be too) who uses external files to send data on a one-way direction to an application. The specific reason for this is the clocks.dat - exactly such a one-way file in my opinion.

Greetings
Jonas