[Csantucci]

I'd add maybe a minor point: if you e.g. have an OR-only trainset in your Trainset folder, and that trainset has its OR-only .eng file in the root folder of the trainset, it might occur that due to that only trainset the MSTS AE would fail loading, even if there is no intention to use such trainset in the activity which is being built. This only to say that before any compatibility break is decided one must be conscious about the possible consequences.

[James Ross]

Csantucci, on 29 April 2021 - 10:35 PM, said:

There is another point about authorising code changes: in your words only the authorised developers are defined and active; up to now, however, also the ORMT has a role: new features are requiring also the OK by a member of the ORMT to be included in the testing (and later stable) version.

I believe the policy page is more of an overview than detailed specifications of what's been decided, so we should link to the contributing documentation, if we're adding links for the other things.

Csantucci, on 01 May 2021 - 02:22 AM, said:

So I think that we are concentrating on case 2. Are we proposing that we would generate OR-specific features that, if applied to a MSTS-compatible route or a trainset, surely break such compatibility?
I think that, when there is an advantage in breaking such compatibility, such step could be now accepted. When instead compatibility can be kept with little effort (like in the case of include files), it is worth keeping it.

I do not foresee much we could add at this point where we have to choose between supporting MSTS or not. If there is such a thing, we'll discuss it when it comes up.

Many files support the "OpenRails" subfolder, including world files (merging rather than overriding). New files like turntables or animated clocks pose no compatibility risk. It is up to the content creator whether they wish to keep MSTS compatibility or not.

The new OR file formats and directory structure will not be compatible with MSTS in any way.

[Genma Saotome]

James Ross, on 01 May 2021 - 05:10 AM, said:

The new OR file formats and directory structure will not be compatible with MSTS in any way.

Sounds like a policy statement.

The exceptions -- the barnacles -- have occurred because they've attached to existing files. As soon as one of those moves over to a new file format the whole backwards connection fails. In the meanwhile it seems that adding more barnacles IS the policy. I regret that fact but absent some understanding of what will cause it to end, what else can you do but continue with it? Alternatively you could say we're just not going to do that anymore.

[cjakeman]

James Ross, on 01 May 2021 - 05:10 AM, said:

I believe the policy page is more of an overview than detailed specifications of what's been decided, so we should link to the contributing documentation, if we're adding links for the other things.

Yes, I'll do that.

[cjakeman]

Genma Saotome, on 30 April 2021 - 05:02 PM, said:

You can chose to do things such that all files used by OR can also be used w/o modification by Train.exe or you can cut the tie and move forward w/o reference to whether things will work in train.exe.

I think the time has passed for ensuring that train.exe can run Open Rails content.

However, until we have replacement editors, then it makes sense to ensure that the content files can be loaded and saved by existing MSTS-compatible editors.

[jonas]

cjakeman, on 02 May 2021 - 11:35 AM, said:

I think the time has passed for ensuring that train.exe can run Open Rails content. ...

...and maybe I don't have a clear enough idea of ​​what is meant by:

James Ross, on 01 May 2021 - 05:10 AM, said:

...The new OR file formats and directory structure will not be compatible with MSTS in any way.

In any case, I would consider it very important that OR does not create any files in an MSTS installation (for example an OR proprietary eng file from Carlos' example here), which MSTS then tries to read and then fails and even crashes because it is misleaded by a MSTS file suffix.
OR would then have kept the promise not to change any MSTS files on the one hand, but would still cause a serious incompatibility with MSTS or even make the entire MSTS installation unusable for MSTS, for example by using the same suffixes such as *.eng im MSTS TRAINSET directory on the other hand.
But I'm sure you all got that on screen.

In short: OR files should always have their own OR suffix or be stored in separate OR folders - hm...as it is at the moment...which is how I answered myselfe many of my questions from the first post here http://www.elvastower.com/forums/public/style_emoticons/default/smile.gif

Kind regards
Jonas

[jonInMaine]

With regard to editors, it might be useful to know how many route and activity creators out there are still using the MSTS tools vs. TSRE and Track Viewer which are now the de facto editors for OR. Personally as an activity and occasional route builder I use TSRE / Track Viewer exclusively since I am at least 2 machines away from having a working MSTS installation, but I know from reading posts on trainsim.com and here that there are people still using MSTS RE / AE either because they are comfortable with the tools, find TSRE daunting, or a combination of both, or some other reason.

I only bring this up because it might have some bearing on the compatibility discussion, if most route/activity creators are on the newer tools then you have more flexibility to change formats (assuming that the tool developers go along of course which is a big if).

Jon

[YoRyan]

https://www.elvastower.com/forums/public/style_images/et_dark/snapback.png' alt='View Post' />jonas, on 02 May 2021 - 02:17 PM, said:

In short: OR files should always have their own OR suffix or be stored in separate OR folders - hm...as it is at the moment...which is how I answered myselfe many of my questions from the first post here

This is the plan for the virtual filesystem project. The new OR file structure will comprise an entirely different directory from your MSTS data. For future types of OR-exclusive data, this will keep things nice and neat.

[jonas]

Sounds good.
Ryan, can you give an example where such file system could exist on the HHD, so about the same level with ...\Routes\... or a bit higher in the directory "Train Simulator" itself or somewhere else entirely? Or does virtual mean that there is no concrete folder on the HHD at all and the whole future OR file system is sort of compressed into a single file?
I don't want to commit you to answers, just get a vague understanding of it. (Maybe I just don't know the related threads?)

Kind regards
Jonas

EDIT: I found a thread and I'm going to read through it.

[cjakeman]

Csantucci, on 29 April 2021 - 10:35 PM, said:

A link could be added towards a document defining the OR coding guidelines.
A link where the GNU license terms can be found could be added.

Links added to the webpage.