[steamer_ctn]

 YoRyan, on 08 July 2020 - 03:20 PM, said:

I am more optimistic. With some appropriate standards, I believe it's absolutely possible to move the simulator forward without breaking backwards compatibility. And we can do so without creating two distinct versions of Open Rails, which would be unfortunate, as improvements that one would expect to be common to both versions - multiplayer, timetable mode, graphical improvements, performance increases, etc. - would be present in the "new OR" but not the "legacy OR."

As proof of this, I again submit the DDS texture loader. :)

In Regards to this I think that we have a different interpretation of terminology.

As has been suggested we currently have a single program that can handle legacy (MSTS) content. New ORTS features have now been added to this, and as a consequence we have multiple "software" switches throughout the code to try to retain MSTS legacy operation. Personally I find this a pain in the neck from a development perspective, as whenever a new function is added it is possible to introduce a bug, and break MSTS compatibility. This can easily happen, as was demonstrated with the recent introduction of starting friction (not a criticism, but an example). Maintaining both MSTS and OR features in a single software "stream" seems to me to be adding a lot more complexity and higher risk of bug introductions.

Alternatively if we created a separate MSTS and OR "stream" we could start to separate this functionality. By stream, I am not suggesting two separate individual (distinct) programs, but a single program that selects at start (based upon the users selection) which mode to operate in, rather then the current approach of continually making this decision during run time via multiple "software switches". The program would then follow whichever of the two independent streams that the user had selected. Hopefully as all MSTS functionality is now mostly complete, very few changes should be required to the MSTS stream. The OR stream could, as it runs independently of the MSTS stream, then be developed independently without worrying about retaining any MSTS compatibility (which would already be covered in the MSTS stream), and hence make development work a lot easier.

As this approach would still be a single (integrated) program, common elements, such as scenery display, etc could be called by either stream as required from a common pool of resources.

Given the fact that some classes in the repository already have either a MSTS or OR label on them, it would seem that somebody was already contemplating a similar approach.

I appreciate that this approach would not be achieved overnight, and would need a transition plan to be developed. However, if we don't set an aiming point, then we will never get "there".

[perpetualKid]

 YoRyan, on 08 July 2020 - 03:20 PM, said:

I am more optimistic. With some appropriate standards, I believe it's absolutely possible to move the simulator forward without breaking backwards compatibility. And we can do so without creating two distinct versions of Open Rails, which would be unfortunate, as improvements that one would expect to be common to both versions - multiplayer, timetable mode, graphical improvements, performance increases, etc. - would be present in the "new OR" but not the "legacy OR."

As proof of this, I again submit the DDS texture loader. :)

if you don't want two distinct versions of OR, you'll than have to create different execution paths in the code, i.e for old-style and new-style content, and possible combinations of both. Unless both contain the same information, which by itself would make it obsolete to have two versions.... With the many interdependencies, this creates a lot of complexity, or eventually limits again to the least common subset. This may work for isolated features (such as DDS Loader), but i.e. if we'd want to take full advantage of DX 11, but also need to support DX9 - a number of fallback options will need to be implemented, tested etc. Sure most of this can be done, but balancing that against the capacity of active contributors doesn't sound realistic to me.
To be clear, I'm not advocating a whole new train simulator here, but suggest to be open for changes which also may break with conventions or decisions done a decade or more ago. And this impacts more than just the discussion on content formats.

[YoRyan]

 steamer_ctn, on 08 July 2020 - 10:12 PM, said:

New ORTS features have now been added to this, and as a consequence we have multiple "software" switches throughout the code to try to retain MSTS legacy operation. Personally I find this a pain in the neck from a development perspective, as whenever a new function is added it is possible to introduce a bug, and break MSTS compatibility. This can easily happen, as was demonstrated with the recent introduction of starting friction (not a criticism, but an example). Maintaining both MSTS and OR features in a single software "stream" seems to me to be adding a lot more complexity and higher risk of bug introductions.

Yes, I agree with your assessment, and the situation clearly sucks. However, in my view, the problem is one of code quality rather than project architecture. Currently (in my humble opinion), the codebase is littered with spaghetti code, global state, and public instance variables, none of which are conducive to code that is particularly clear or easy to understand. You can resolve this with refactoring, but it necessitates some short-term pain. Here, we can take another example from the starting friction bug, which I introduced in the process of splitting a single 300-line function into smaller and more manageable bits; I obviously regret having introduced an error, but I believe the code is much better positioned for future growth and modification.

With respect to physics, some nice goals to work toward would include refactoring more monster-functions, simplifying the haberdashery of experimental options (perhaps into an "MSTS mode" and an "MSTS+ mode," as you suggested), and implementing some form of automated testing, all of which would go a long way toward illuminating the black box that is OR's physics engine - and making the simulator measurably easier to maintain, irrespective of its high-level architecture. Conversely, even the most thoughtful architecture will get tripped up by unreadable code. You can't just lock a piece of code away and promise never to touch it again, because inevitably, you will - whether to fix a newly discovered bug, or to update it to accommodate new technologies.

 perpetualKid, on 08 July 2020 - 10:58 PM, said:

if you don't want two distinct versions of OR, you'll than have to create different execution paths in the code, i.e for old-style and new-style content, and possible combinations of both. Unless both contain the same information, which by itself would make it obsolete to have two versions.... With the many interdependencies, this creates a lot of complexity, or eventually limits again to the least common subset. This may work for isolated features (such as DDS Loader), but i.e. if we'd want to take full advantage of DX 11, but also need to support DX9 - a number of fallback options will need to be implemented, tested etc.

Well, DX9 versus DX11 is sort of an orthogonal discussion with respect to MSTS versus OR formats and physics. If I'm not mistaken, there is very little, if any, MSTS content that is tied specifically to the graphics engine, which means the onus is on us to maintain those loaders. And from what I've seen, the community is excited for the move to Monogame. I think we could drop DX9 support without much trouble. We could never drop .S support.

[Genma Saotome]

 YoRyan, on 08 July 2020 - 11:55 PM, said:

We could never drop .S support.

Yup.

This does beg the question of how does the model file gain enhancements when the 3dmodeling software does not export into .s?

I don't have an answer for that; One might create an .s file editor that might be able to record and place some of it. A second format type that can do more (e.g., .obj as one name). The .sd file too.

As for the main issue in the posts above, what's the problem w/ just forking the code, cleaning up the MSTS only version and putting "on the shelf" for anyone who wants it. New development takes the other road.

[cjakeman]

 Genma Saotome, on 09 July 2020 - 09:37 AM, said:

As for the main issue in the posts above, what's the problem w/ just forking the code, cleaning up the MSTS only version and putting "on the shelf" for anyone who wants it.

As I see it, as soon as James finishes the MonoGame merge, then the Testing version from just before the merge will become a new release Open Rails v1.3.2 which will be the last one to be compatible with Windows XP.

The version merged with MonoGame will become Open Rails v1.4 and both versions will be offered on the website with installers.

I still favour the use of translators from an MSTS-format file to an OR-format file, so OR only deals with one source of input and any workarounds to handle idiosyncratic MSTS behaviour are then confined within the translator itself.

[Genma Saotome]

 cjakeman, on 09 July 2020 - 09:58 AM, said:

As I see it, as soon as James finishes the MonoGame merge, then the Testing version from just before the merge will become a new release Open Rails v1.3.2 which will be the last one to be compatible with Windows XP.

The version merged with MonoGame will become Open Rails v1.4 and both versions will be offered on the website with installers.

I still favour the use of translators from an MSTS-format file to an OR-format file, so OR only deals with one source of input and any workarounds to handle idiosyncratic MSTS behaviour are then confined within the translator itself.

For clarity, when you say "I still favour the use of translators from an MSTS-format file to an OR-format file...." do you have in mind only a conversion from SIMIS to .json, a conversion of KUJU's specification of data to something new, or both?

[YoRyan]

 Genma Saotome, on 09 July 2020 - 09:37 AM, said:

This does beg the question of how does the model file gain enhancements when the 3dmodeling software does not export into .s?

I don't have an answer for that; One might create an .s file editor that might be able to record and place some of it. A second format type that can do more (e.g., .obj as one name). The .sd file too.

It's not worth mucking around with Kuju's obscure file formats. Let the .S exporters continue to produce MSTS-compatible models. Better to add support for an industry-standard format like .obj (Wavefront), and to offer JSON as an alternative to .sd if more metadata is needed.

 Genma Saotome, on 09 July 2020 - 09:37 AM, said:

As for the main issue in the posts above, what's the problem w/ just forking the code, cleaning up the MSTS only version and putting "on the shelf" for anyone who wants it. New development takes the other road.

Such a fork would preclude future improvements and fixes in the MSTS version, and would be, in my opinion, an unnecessarily drastic step.

[Genma Saotome]

 YoRyan, on 09 July 2020 - 10:56 AM, said:

It's not worth mucking around with Kuju's obscure file formats. Let the .S exporters continue to produce MSTS-compatible models. Better to add support for an industry-standard format like .obj (Wavefront), and to offer JSON as an alternative to .sd if more metadata is needed.

There have been posts in teh past arguing the .s format is easily extendable (tho nobody has tried). I always wondered what exactly was possible given the OR team does not have it's own 3dmodeling software.

 YoRyan, on 09 July 2020 - 10:56 AM, said:

Such a fork would preclude future improvements and fixes in the MSTS version, and would be, in my opinion, an unnecessarily drastic step.

I dunno... seems like it would get a monkey off the OR teams back. It's not like there is an unlimited about of volunteer time available to modify both old and new. IMO it's a perfect opportunity to do a Marie Kondo culling: "Thank you OR-MSTS for teaching us how to do a train simulator", bow humbly, give it a url and move on to newer and better accomplishments.

[steamer_ctn]

 YoRyan, on 08 July 2020 - 11:55 PM, said:

However, in my view, the problem is one of code quality rather than project architecture.

Whilst I agree that well formed code is potentially an architectural principle, on its own it won't solve our challenges, and fix the state that OR is currently in. Well formed code does not answer why, what or how questions about how the software should be architected (constructed).

An architecture (framework) such as the the open group architecture framework (TOGAF for short) which is used by a large number of professional software development companies will answer these questions, and provide a clear common direction for all to follow.

By studying the attached TOGAF Architecture Content Framework it can be seen that there are a number of elements or components to the framework.

In brief,

i) Architectural Principles, Vision and Requirements - set appropriate standards and high level direction, etc

ii) Business Architecture - describes the why. How does the business operate and what software functionality is required to support its operation?

iii) Information System Architecture - describes the data information schemas, and requirements as well as the software elements required to support the outcome.

iv) Technology Architecture - describes the supporting technology such as hardware, etc.

v) Architecture realization - describes how the work is to be broken up, governance standards, etc. (For example the changed commit process would be in this area).

Some people may have seen the swing cartoon (see other attachment), which demonstrates the potential issues (potential for failure) if a clearly defined architecture does not exist.

As has been suggested Open Rails is still mainly based upon the MSTS architecture, there has be no major move away from it since its inception as a "MSTS emulator".

Given the fact that most of the points raised in this thread in recent days are actually questions about architecture, perhaps it is timely to review and redefine the complete architecture used by OR. Any decisions and outcomes should be captured for reference then by all parties, as this ensures that we all have a common view (and approach) of what we are trying to achieve with OR.

The attached framework diagram (and other online reference material) can serve as a form of check list in capturing the bits that are important.

Attached thumbnail(s)

• 
• 

[ErickC]

 Genma Saotome, on 09 July 2020 - 04:54 PM, said:

There have been posts in teh past arguing the .s format is easily extendable (tho nobody has tried). I always wondered what exactly was possible given the OR team does not have it's own 3dmodeling software.

I dunno... seems like it would get a monkey off the OR teams back. It's not like there is an unlimited about of volunteer time available to modify both old and new. IMO it's a perfect opportunity to do a Marie Kondo culling: "Thank you OR-MSTS for teaching us how to do a train simulator", bow humbly, give it a url and move on to newer and better accomplishments.

The benefit to keeping the S format is that all of the available programs can export to it. Switch to obj and us GMax users need to:

A. Fork over $180 per month for 3DS
B. Export from two or three different programs, probably losing animations and smoothing along the way
C. Switch to Blender, which has a clunky interface, makes simple tasks unnecessarily tedious (like hard edges), and can't perform some basic UV mapping functions (for example, a simple planar map at a definite resolution of 1/4 inch per pixel). Blender is geared towards people making sci-fi and figure models, not people building scale replicas.

Got news for y'all - a third of the five or six people actually building models for OR are using GMax. If the S format is capable of supporting new features, there's no point in changing formats just to look cool and modern because we're using some perceived "standard."

 Genma Saotome, on 09 July 2020 - 09:37 AM, said:

Yup.

This does beg the question of how does the model file gain enhancements when the 3dmodeling software does not export into .s?

How do we add winter, night, and other maps to existing models? The only other major enhancement beyond materials that I can see is possibly attach points, but that's something that can be handled with dummies and part names. The thing is there isn't a huge difference between most model formats besides how data blocks are organized anyway. You could argue that other formats and new exporters could allow us to hard code in new animations, sort of like the XML code in MSFS, but it's actually kind of ridiculous that animations are hard-coded into models anyway. Why don't we script rolling stock animations the way route builders script signal animations? Even in the MSFS world, it was always more efficient to have gauges controlling the custom animations, which is why a lot of developers stopped hard-coding their parameters into the XML code for their parts, instead opting to have it scripted externally. For our purposes, there should be an animation script file, much like an SMS files, that defines part names, animation triggers, looping and playoneshot parameters, speeds, and so on, that controls animations. You name your parts whatever you want, use however many frames you want, then define the script file to use in the ENG file, and the script file parses the part names and commands the model accordingly.

It also strikes me as somewhat absurd that, passenger views notwithstanding, we're limited to two SMS files per piece of stock. It's absolutely insane that every SMS files I write has to have the same control sample streams in it instead of a single, dedicated SMS file for control samples, another one for the horn, and the ability to tag individual streams as internal or external in a single SMS file (which may be possible already, I've been meaning to experiment). Users wouldn't need to edit SMS files to change a horn out, I'd simply release horn packages with their own dedicated SMS files to be inserted into the ENG file at-will.

I'm digressing a bit. I'm afraid you've poisoned my thinking with your common.fleet idea, and I keep thinking about how we could, in the future, perform most functions with plug'n'play modules like I am presently doing with physics, instead of a single, large file with loads of data in it for each function (ENG, SMS, WAG, et c).

Anyway, given the fact that the S format can do what it might conceivably need to do if we gain more advanced materials, the pro/con list looks like this:

PROS:

-The format is already well-understood by content developers and the platform's developers
-The format can be adapted to whatever additional features are added in the future
-All available modelling programs can export to it

CONS:

-The techwarrior iCrowd™ Dudebros feel it makes the sim seem less "contemporary" and doesn't give it "cool feels brah"

From where I sit, that's not a difficult choice.

Anyway, I don't see why anybody would worry about alienating the die-hard MSTS crowd. They're all using MSTS and make sure to loudly point it out any time there's a new OR-only release... ad nauseam.