[jonas]

 jonas, on 19 April 2021 - 03:34 PM, said:

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

An addendum: I think that, among other things, this line in my penultimate post was a cause for anger. I apologize for that. I meant that rather jokingly and was not aware of the serious background. It wasn't on my mind that, among other things, rare manpower could be meant here and only memory limits came in to my mind as an idea - RAM memory of course - not my brain memory. Thats another question :-)

[YoRyan]

Jonas,

I should be the one apologizing, actually; I'm sorry. I didn't mean to come across as trying to shut you down or anything.

The context you may be missing (I'm not sure how much forum archaeology you've performed since you've come on board) is that we've discussed new file formats several times before, most recently a new consist format proposed by myself last year. And, to be blunt, I found it difficult to discuss such topics with non-programmers. Most people - it's only natural of them - think in terms of features, windows, buttons, and other tangible things they can interact with on their screens, while file formats are kind of abstract and easy to misunderstand. So while I was discussing a new way of storing sequences of rail vehicles, I was inundated with requests for new game operating modes and support for articulated engines - things that were tangentially related, but, I felt, were not properly within the purview of a replacement consist format.

Since then, I've felt that the way forward is to design the file formats around the eventual editor, rather than the other way around. So I'm happy to discuss file formats with you, but with the small caveat that we should not "miss the forest for the trees," as we say in US English. Let's put the user first. :)

(By the way, let me state that I vehemently agree with you that RunActivity.exe should never modify game content.)

[Csantucci]

IMHO keeping the clocks.dat file should have been the solution here. Another decision has been taken for the official OR.
It is my intention that ORNYMG will behave as follows:
- keep accepting clocks.dat and interpreting it natively, without conversion, to keep compatibility with existing content without user intervention and to avoid runtime or pre-runtime changes to content files;
- accept also the new JSON-format, because a goal of ORNYMG is that contents running on official OR should run also on ORNYMG;
- in case both files are present, consider only the file with the JSON format, again to keep compatibility with the official OR releases, and generate a warning message in the logfile stating that clocks.dat has been skipped due to the presence of the JSON file.

[xavivilla]

I will give my humble opinion.

As an end user, I don't care what format the extended files are. As an end user, what I'm interested in is starting an activity on a route, checking that I have all the elements involved in it, and executing it. At most, being able to create a paths, a consists and traverse a part of the path in explorer mode. But for all this, it never interacted with the .pat or .con files, I don't need to see them in a text editor, nor know what their structure is.

Things change when you are a content creator. So, if you are interested in the structure of the folders and the files within them. And if you have to know how these .dat files are written (in all their varieties). .ref, road and track databases, and other files related to routes, vehicles or activities. And here I see two options for the Open Rails team, either the structure of the new .json files is fully documented or specific editors are provided for each type of file in which the content creators enter the values ​​and these editors generate the files .json. Although the ideal would be both, good documentation and editors.

Regarding the controversy of the clocks.dat (STF) or animated.clocks-or (JSON) file, my opinion is that the route creator, at the time of publishing the route, should do the conversion and thus the end user would have nothing to do.

[Laci1959]

In Hungary, only one track, the "Alföld 7.3", is more than 2,000 kilometers today. They are trying to follow the renovation that is taking place in reality. This means 3-4 platform hours per station. So far we’ve been thinking about working, but now I’m very insecure. It may not be because we do not know the JSON language. There is no programmer among us

[cjakeman]

 xavivilla, on 20 April 2021 - 01:41 AM, said:

Regarding the controversy of the clocks.dat (STF) or animated.clocks-or (JSON) file, my opinion is that the route creator, at the time of publishing the route, should do the conversion and thus the end user would have nothing to do.

Thanks, Rui. That is the intention of my proposal.

[YoRyan]

But, Chris, we have a dialog box that displays when you launch Open Rails and have a clocks.dat file in the current route. That's placing the burden upon the player, not the creator.

[jonas]

Hi,

I like Carlos suggestion above.

As far as the JSON format is concerned, it seems that I stung too naively into a wasp's nest, although I tried to read and overlook the relevant threads of the past. So I'm sorry again to everyone for the dust I raised when fundamentally question the JSON format.

My now modest opinion is that I would like to ask again to reflect on my categories of one-way and dual-way external files that I have brought into play. clock.dat and animated.clocks-or are one-way files in this sense. They pass on data from the user to the application, not the other way around.
It looks different if there will be an editor for the clocks. The whole question of the file format will fade away automatically. If an appropriate editor can be used, nobody will try to make a manual change (e.g. with Notepad.exe or similar) - neither in the clocks.dat nor in the animated.clocks-or.
In the case of dual-way external files, which are written by the machine and read by the machine, only the developers should decide which file format should be used - of course!
In any case, the aim is for all external files to become dual-way files in the future if I see this right.

But until the appropriate editors exist, the user is expected to write the content of clocks or turntables into the files by hand. And at least as long as we already have STF readers for such files, I would want to accommodate the user with the old STF format.

@Chris, I don't think we would violate the current Open Rails Policy in this way. At least as long as the "ExtClocksFile.cs" is still "on board". Is it still in use?

@YoRyan, my last thought here doesn't solve the manpower problem in general, I can see that. When I think about it, I realize that instead of coding the "ExtClocksFile.cs" (an adaptation of the "ExtCarSpawnerFiles.cs") ), I should rather have dealt with coding an editor for the clocks.dat / animated.clocks-or. But to be honest, that far exceeds my skills in C# :-). Here we have the lack of manpower - again, you are right about this.

Greetings
Jonas

[YoRyan]

I don't quite understand our collective obsession with STF, because it's just not a very good format for writing files by hand, either. Data types are ambiguous (is that a string or a number?), and there's no schema system to give you fancy autocompletion assistance, unlike with JSON. What about timetable files? They're not STF. Microsoft Train Simulator was a half-finished product rushed to market, not the pinnacle of software engineering.

I don't feel too strongly about this issue, so I'm not going to block the pull request over the presence of a clocks.dat STF reader, but I'm just not seeing the extenuating circumstance to keep it around, considering that in all likelihood only one clock file currently exists in the world.

Chris intends to make automatic converters from .eng, .wag, and so forth to JSON, the "dual-way" concept that you've discussed. Personally, I'm not convinced of the need for them at all. I'd rather have editors instead.

[Laci1959]

 YoRyan, on 20 April 2021 - 07:50 AM, said:

But, Chris, we have a dialog box that displays when you launch Open Rails and have a clocks.dat file in the current route. That's placing the burden upon the player, not the creator.

Even if you no longer have a clocks.dat file because the track creator deleted it after the conversion? Even before release?