cjakeman, on 17 April 2021 - 03:13 AM, said:
... For the developers, JSON gives us a well-understood, dependable, standardised base to work with, whereas parsing STF is a bit dodgy, undocumented and unfamiliar to new talent.
The intention is that content creators will have editors to work with and not spend much time looking into the files.
Amtrak115, on 17 April 2021 - 03:45 AM, said:
... Having users being able to muck with data files from a application standpoint is very bad.
In principle, I agree with that when it comes to bank account data, for example :-), but if you want a user-open system you need interfaces. ...and so far I thought that we want that.
Amtrak115, on 17 April 2021 - 03:45 AM, said:
MS/Kuju made the decision to use the "classic STFormat" for any data that needed to be stored or persisted between execution sessions.
I see it the other way around. Data that are saved between the sessions, such as in the * .sav files, can not simply to be opened and edited with Notepad.exe and are therefore compressed.
Amtrak115, on 17 April 2021 - 03:45 AM, said:
The reason everyone started looking at the data and mucking with it, was the tools used to generate those files either didn't exist or were insufficient to satisfy user needs.
I seriously doubt this point of view, that users only started looking into the external files because of this.
If Kuju had wanted to exclude the user as much as possible in order to protect the application, then all external files would have been delivered compressed and encoded. But I made the effort today and freshly installed MSTS. I actually wanted to show a list of the uncompressed files here, but decided not to because there would have been far too many - the overwhelming majority of file types are uncompressed! When looking through the new installation on the HDD, I was surprised that almost all(!) Files, except for the * .s and * .w files in ROUTES or GLOBAL (and of course dll's and similar) are uncompressed. All possible suffixes like: * .sd, * .dat, *, tdb, * .tit, * .rdb, * .rit, * .haz, * .ref, * .trk, * .srv, * .path, * .act, * .con, * .eng, * .wag, * .ws, * .trf, * .cvf, * .mrk, * .env and * .fbk are available as uncompressed ST format by default and can be opend with Notepad.exe by everyone!
The MSTS TechDoc files also clearly show that MS/Kuju specifically invited to edit and expand the external files of the MSTS. Only three TechDoc files are mentioned here as examples:
• How to Create Marker Files.doc (* .mrk files)
• Conversion of Shapes and Textures 1.01.doc (* .sd files)
• How to Make a Car Spawner.doc (carspawn.dat)
A quote from the last mentioned file:
"The type of traffic spawned is not set up within the Route Editor, but in a file called carspawner.dat which is located in the root directory of the route you are editing. This is a simple file that can be edited in any Unicode text editor. This file is basically a list of shapes you wish to have generated as traffic. Determine the name of the shape you wish to have as traffic (there are many cars, mopeds, vans and trucks supplied within the various routes of Microsoft Train Simulator) and add it to the list. The number at the start of the file is the total number of lines of shapes you have added. If you want a certain shape to appear more frequently than another shape, give it multiple entries, updating the number at the top of the list."
If that doesn't invite you to change external files (without a special editor!), what else way do we expect?
It seems to be a legend that frequently keeps popping up that the user was only forced to "fumble around" in the external files because of the absence of editors. This legend seems to be renewed again and again for years, especially here in the forum in various posts, but also in other places on the Internet. But I say very clearly: MSTS wanted the user to expand external files such as Carspawn.dat etc. without special editors. Certainly only to a smaller extent, but the user should be able to read STF files and, above all, write them.
Kuju would certainly have liked to supply editors too, but the release time pressure that existed for some reason ;-) probably prevented that.
Of course, from Kuju's point of view, the really more complicated files, such as a local * .tdb, should never be fiddled with with Notepad.exe. Most user know that this is the death of any route of course.
Amtrak115, on 17 April 2021 - 03:45 AM, said:
The use of JSON or other formats provides a readily available storage for data the program needs to be persisted not for a user to muck in.
Who apparently decided so casually and when that the user (in contrast to MSTS) should better be excluded from editing files in Open Rails? ... which chapter did I skip?
Hey :-), we support the world's largest range of digital content :-) - it's still a cool thing to read this for me!
Thanks to Chis' tip, after reading this
previous thread on the topic, my impression has strengthened that all in all, programmers have agreed on JSON with each other. There were also cautionary voices that feared the exclusion of users, but technical enthusiasm outweighed the discussion.
Among the users of my add-on (now more than 80 people) I get sometimes a feedback from them. I am therefore sure that the less readability of the JSON format will not be well received and that users will feel left out. And the announcement of OR editors for the justification of the JSON format of the external files was more than 10 years ago?
Maybe we need a clarification of terms: By users I mean people who occasionally play an activity and for whom it can mean a whole weekend of joy when they discover how, for example, they can insert a line in a Carspawner.dat in such a way that a "new" car previously downloaded appears during an activity. I often see myself as an user too when I make quick, small changes in all kinds of files while laying tracks in order to test this or that. As a route builder you could of course also call me a developer. But by developers I always mean the Open Rails software programmer here.
Amtrak115, on 17 April 2021 - 03:45 AM, said:
While I agree that STFormatted data is easy to read, however you have to be careful modifying that data because in a lot of cases numbers are not always what they seem to be. Ex. In signpost data, there is usually three numbers stored. "238 000030.0 1.0", (totally made up) the first number "238" is not really a value but a representation of bit flags that tells the code how to read the rest the of the data.
Even in the JSON format you have to be careful with any changes. But I agree with you that by assigning names to each individual date in the JSON format, we have more Clarity.
In your STF example "238 000030.0 1.0" it could be better written like this even in STFormat:
ThisAndThat_Item (
ThisAndThat_BitFlag (238)
X(000030.0)
Y(1.0)
)
Perhaps for me it is simply a matter of avoiding the two different types of brackets, the colon and the comma at the end of the line in the JSON format for the usual better readability of the STF files:
For new files created by OR, a kind of strict STF-OR standard instead of JSON:
A classic MSTS STF entry like this one:
Object (
UiD ( 27 )
FileName ( Uhr03_OR_Jm.s )
Position ( -119.654 1 241.807 )
VDbId ( 4294967295 )
)
would look like this for new OR files:
Object (
UiD ( 27 )
FileName ( Uhr03_OR_Jm.s )
Position (
X ( -119.654 )
Z ( 1 )
Y ( 241.807 )
)
VDbId ( 4294967295 )
)
What should definitely be forbidden are proper names that follow identifiers without brackets, such as the proper name
House here and unnamed lines of numbers such as (
1 0 0 0)
matrices ( 1
matrix House ( 1 0 0 0 )
)
Correct would then be:
matrices (
matrix (
Name ( House )
VectorX ( 1 )
VectorY ( 0 )
VectorZ ( 0 )
VectorQ ( 0 )
)
That would still be better than
real JSON for readability:
matrices : [
matrix : {
"Name" : " House",
"Vector01X" : "1",
"Vector01Y" : "0",
"Vector01Z" : "0",
"Vector01Q" : "0",
}
[
Because if you can do without the apostrophe in JSON format (
seen here), we end up with:
matrices : [
matrix : {
Name : House,
Vector01X : 1,
Vector01Y : 0,
Vector01Z : 0,
Vector01Q : 0,
}
[
Now replace the colon and curly brackets with normal brackets and replace the comma with closeing brackets, we end up here again:
matrices (
matrix (
Name ( House )
VectorX ( 1 )
VectorY ( 0 )
VectorZ ( 0 )
VectorQ ( 0 )
)
It's just calmer and more familiar to read.
But I guess it is too late for such proposals, despite
objections like that at the time. That was at least three years before I started at ET.
So...
Amtrak115, on 17 April 2021 - 03:45 AM, said:
having said all this, the premise of your first post is still valid, Is OR going to continue to just expand/cludge the old MSTS data or is there a plan for the future?
Log In
Register Now!
Help
