[cjakeman]

The Project Team has accumulated a number of policies over the years, mostly as a result of discussion in these forums.

However they have not been collected and published for easy reference - until now. You can find them in a new webpage on the website.

If James and I have forgotten something, please send me a PM.

If you think we should add or change anything, now is your chance to air it here.

[Csantucci]

A link could be added towards a document definining the OR coding guidelines.
I don't know if it can be considered a policy, but I would add that units of measure must be metric (or it can be part of the coding guidelines).
A link where the GNU license terms can be found could be added.

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.

[cjakeman]

Thanks for looking at this, Carlo.

The units of measure are already covered in the coding guidelines as "Measurements must be in SI units unless you have an exception granted by the Open Rails Management Team."

I'll see what I can do about your other points.

[Genma Saotome]

Dunno if you want to include this but what about train.exe? I've long argued the wisdom of cutting that tie and over the years there have been more and more workarounds that keep the chain between the two programs in place.

[cjakeman]

 Genma Saotome, on 30 April 2021 - 08:03 AM, said:

Dunno if you want to include this but what about train.exe? I've long argued the wisdom of cutting that tie and over the years there have been more and more workarounds that keep the chain between the two programs in place.

I'm not sure what you have in mind here.

I wonder whether this is connected to the options that Open Rails has been accreting like barnacles to provide backward compatibility with quirks of MSTS.

[Genma Saotome]

 cjakeman, on 30 April 2021 - 10:58 AM, said:

I'm not sure what you have in mind here.

I wonder whether this is connected to the options that Open Rails has been accreting like barnacles to provide backward compatibility with quirks of MSTS.

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.

IMO the later option is long overdue.

Reworded, OR today is almost entirely compatible w/ MSTS and MSTS is almost entirely compatible w/ OR. IMO we only need the later condition as what it means is it is ok to extend any extant file type. Either one is a policy decision.

[cjakeman]

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

Reworded, OR today is almost entirely compatible w/ MSTS and MSTS is almost entirely compatible w/ OR. IMO we only need the later condition as what it means is it is ok to extend any extant file type. Either one is a policy decision.

That's much clearer - thank you, and quite distinct from the concern I mentioned.

Perhaps you are right and it's time that the 2-way compatibility was dropped. Just because we've managed to organise content that runs on both systems, doesn't mean that we should be bound by that. I'll return to this point later.

[Csantucci]

I think there is more than a case.
Case 1: There are routes, trainset and other content that have been explicitly built from the beginning as running only under OR, so such content already isn't compatible with MSTS and there's no problem in that.
Case 2: Consider a content, like a route, that has been developed for MSTS and runs with it. If we add to that route an OR-specific feature, like an animated turntable or a timetable, that won't cause problems if you run the route with MSTS, which simply won't "see" these added features. Practically up to now any feature added to OR can be inserted in a MSTS-compatible route without breaking such compatibility. This was in fact an explicit policy: I remember that when adding new .cvf features or new sound events I was requested to check whether they would cause problems to MSTS. Later the trick with the include files was put in place, and the .cvf (and .wag and .eng and .w etc.) problem was no more on the table.

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.

We must also always remember that behind new features (especially route features) there should be a supporting editor, which is not a straightforward thing.

[jonas]

 cjakeman, on 01 May 2021 - 12:37 AM, said:

... and it's time that the 2-way compatibility was dropped. ...

As a route builder, I would like to ask for caution here.
It may be that I would do without one or the other "smaller" OR innovation in a route because it would be more important to me to remain compatible with MSTS.
But if I think of things like the turntables and imagine that they would not be downward compatible with MSTS, then I could either not use them at all or the route would only be playable in OR yet.

EDIT: Carlo made it above much clearer with Case 2 than I. Our posts have crossed.

[roeter]

There's a lot of talk about editors but let's be realistic on this. I have now been around ET/OR for about ten years and in that period, exactly one (1) 'in-house' editor has been created (trackviewer).
All other editors which we, as community and as developpers, are using, and are indeed dependent on, are created as 'external' tools. With all respect to those who spend time and effort in creating these editors, it still means that we (i.e. community and ORMT) have no control over functionality or data formats. We can ask, plea etc., but we cannot enforce anything. And looking at the very limited development capacity that there is for OR at present, it is not likely this is going to change any time soon.
So all this talk about editors and any related changes to data structures etc. may sound great and may make an excellent policy and roadmap for the future - the question is : how realistic is this? I think it is simply not going to happen. There may be piecemeal additions to the data, some new and larger (e.g. timetables), some just additional and smaller (e.g. include files), but that's it. Any large-scale development of 'in-house' editors (e.g. for routebuilding) just isn't going to happen.
And that means that we're also stuck with the present data formats, whether we like it or not.

Regards,
Rob Roeterdink