[Hack]

Pardon me for jumping in, but can't new features be added to the current file formats so that they would be ignored by MSTS yet be easily read by OR? That might require a new header and/or token file, however.

[gpz]

As part of the 3D format war I would like to draw attention to a new kid on the block: glTF

This is a relatively new format, project started (in Hollywood style) "by the creators of Collada" in 2012, and was renamed from its original name COLLADA2JSON to glTF. It is a kind of super-COLLADA, created with the aim of removing the shortcomings of COLLADA: its bloatedness with unnecessary attributes stored by the editor program, the as-many-kind-of-structuring-as-exporters, CPU-intensive loading. It consists of a JSON format high level structure description file, a binary vertex and index array storing file aimed for loading these arrays directly into the corresponding programming structure without a need for further processing, and of course the texture files. Currently it is at stage 0.8, but there is a good chance it will become a standard, since the maintainer is the same as for COLLADA: the Khronos group. A COLLADA to glTF converter and the parser for the JSON description file in JavaScript resides in GitHub repository.

I am bringing this up because the JSON model format would fit perfectly to our future new JSON format OR files, and the binary data of the mass indices makes this format to a level of DDS in GPU-compatibility, more than anything else.

[Stefan PAITONI]

Hello,

I am trying to give my point of view, Sorry if it's not clear,
As it was said, Route Editor is not very complex in its principle. It's quite easy to locate objects, select them, edit them, etc...
The main window can work like our current simulator. As soon as we can act in the simulator with objects (in a cab for exemple), the needed tools and functions will be available. We can take the free camera and visit the route, letting our player train in place.
So, we can make now a new Route Editor with MSTS file as source of data. BUT, it's very important to go further, adding new concepts, using new technologies ... And this can't be done with the current MSTS format.

So, I could follow James proposal, but, at first, we need to make a list of things we need, things we wish. And this for every part of the simulation, not only terrain, objects, animations, etc... What about tracks, signals, etc. In some case, like section and path management, we need some blind datas. Like station limits, detection zones, and so on.. Same with engines, wagons, or animated objects. All specialists should give us their needs...
The current Activity Editor, on which I work, can read MSTS files. But its data are saved in Json files ( Json is not mandatory). These Json files are read by the simulator and can be used to add information, as with the new AuxAction configuration. Other datas are ready for use, it just needs time to finish and test. These new functionalities are not MSTS functionalities (except Waiting Point).

regards

Stef

[James Ross]

Genma Saotome, on 16 October 2014 - 05:27 PM, said:

James has added another thought there -- "we can keep the testbed version around after we've got the full OR version". The implication is there is a fork... it might not be a big code fork but it could be very significant for routes because on one side are whatever MSTS files migrate over to being edited by OR programs after this fork and on the other is everything that remains MSTS ONLY... which, if we're talking about the consequences of new editors, might be all MSTS created routes... or, if there is good fortune looking down on us all, only those routes that, for whatever reason a few folks, working on their own, have chosen to continue to edit as pure MSTS routes, running in OR as is.

I'm not sure I've really understood your use of the word "fork" in this thread; OR started off being able to read MSTS files and we're going to add reading and writing OR files. Support for MSTS files isn't going to change and isn't being separated in any way. If we did have (or do create) MSTS editors which we then change to be OR editors, then I could consider there being a fork - but this is exactly what I am trying to avoid here.

If people want to create tools for editing MSTS files, they should do so outside of and independent of OR.

I would expect the conversion process to be good enough to take basically any MSTS route/trainset which loads in OR without problems and turn that route in to an OR route/trainset, sufficiently accurately to be usable. That means models/scenery, terrain, track, roads at least. Things like hazards would be less important (but maybe still possible) and activities would likely be a real challenge.

Lindsayts, on 16 October 2014 - 10:05 PM, said:

Instead of new file formats what about any MSTS files the route editor uses is stored in a separate sub directory as is being done I believe already in OR. This would mean the files MSTS uses are not touched but the editor can still change a route. I understand the motavation to keep a route to be able to be run in MSTS but the more complex the path to the route editor is the less likley we are to see it and I do have the distinct impression quite a few OR people are afraid of the route editor.
This baffles me is there is clearly a good bit of programming talent working on OR.

Allowing the editor the save MSTS file formats, even in a subdirectory where MSTS itself won't see them, is still going down the route I would like to avoid - that of editors writing out MSTS file formats at all - and if you're suggesting we write out OR-specific files (with OR-specific features) in these subdirectories, we've gone and tied ourselves to the MSTS directory structure, which I also want to avoid.

gpz, on 16 October 2014 - 11:57 PM, said:

As part of the 3D format war I would like to draw attention to a new kid on the block: glTF

...

I am bringing this up because the JSON model format would fit perfectly to our future new JSON format OR files, and the binary data of the mass indices makes this format to a level of DDS in GPU-compatibility, more than anything else.

Interesting, we'll have to have a look at that and it sounds like a candidate.

[Genma Saotome]

James Ross, on 17 October 2014 - 12:47 AM, said:

I'm not sure I've really understood your use of the word "fork" in this thread; OR started off being able to read MSTS files and we're going to add reading and writing OR files. Support for MSTS files isn't going to change and isn't being separated in any way. If we did have (or do create) MSTS editors which we then change to be OR editors, then I could consider there being a fork - but this is exactly what I am trying to avoid here.

Good. It should be avoided if at all possible.

Quote

Allowing the editor the save MSTS file formats, even in a subdirectory where MSTS itself won't see them, is still going down the route I would like to avoid - that of editors writing out MSTS file formats at all - and if you're suggesting we write out OR-specific files (with OR-specific features) in these subdirectories, we've gone and tied ourselves to the MSTS directory structure, which I also want to avoid.

We've disagreed on those details before... no doubt will disagree on other details again.... What would be helpful to everyone else, maybe to us as well, is an open critique of the KUJU solution (probably best to do that in its own thread). I've got complaints about what they did... you've got complaints too... let's get them documented in one place so the broader community can review it and understand why certain changes would be good.



WRT the mention of glTF brings to mind the open issue of what to do about the foundational library... does OR continue with .XNA? If not, when is the appropriate period of time to introduce a replacement? Right after 1.0? Sometime before 2.0? Some other time?

[atsf37l]

I think my head's gonna 'splode!

But I sure like what's being done! :) :)

[eric from trainsim]

I don't see what all the fuss about the formats for the World files is... While the .W isn't quite as clean as XML, it's extremely easy to parse, and could easily be converted back & forth from an XML structure if someone really wanted to come up with a schema.

I've already done some playing around with that while developing WorldFileHacker -- I can currently take in an entire WORLD directory for a route, normalize the data and creating a single output file in either XML or CSV, or multiple output files...

How the editor chooses to write the output seems to be the easiest problem not in need of a solution. As I've said elsewhere, I'd be entirely OK with a 2D editor that let me move stuff around like it is to build things in TSM or GMax (e.g. a properties popup that allowed me to enter everything in manually).

[captain_bazza]

@Lindsay re post #39.

Not 'hostile', Lindsay, but most have had no experience of it, in any of its flavours. So it's like being spoken to in Esperanto. http://www.elvastower.com/forums/public/style_emoticons/default/unknw.gif!?

Cheers Bazza.

[James Ross]

eolesen, on 17 October 2014 - 02:39 PM, said:

I don't see what all the fuss about the formats for the World files is... While the .W isn't quite as clean as XML, it's extremely easy to parse, and could easily be converted back & forth from an XML structure if someone really wanted to come up with a schema.

World files are much easier because they are almost exclusively created by programs, not people. The same cannot be said about engine/wagon files. The file format is still not completely understood, or at least we do not have a complete implementation of it yet, which means it is a terrible idea to use it when we have alternatives that are fully specified and fully implemented.

[eric from trainsim]

James Ross, on 18 October 2014 - 02:32 PM, said:

World files are much easier because they are almost exclusively created by programs, not people. The same cannot be said about engine/wagon files. The file format is still not completely understood, or at least we do not have a complete implementation of it yet, which means it is a terrible idea to use it when we have alternatives that are fully specified and fully implemented.

Agree that the large majority of the updates are by programs, but it's not exclusive. There are a lot of manual updates done by some of us, be it to tweak forest density values, place berms, or make file substitutions on track & road sections.