[R H Steele]

 perpetualKid, on 08 July 2020 - 12:45 AM, said:

...Such "New OR" could explore new directions, but may break compatiblity or leave older decisions...behind.

I agree with most of what you wrote, exception being in the emphasized portion of the above quote. I also am of the opinion that MSTS compatiblity need not be as rigorously adhered to going forward, although I believe there still are issues that involve MSTS models used in the UK and Europe that do not fully function in OR.

Compatibility, once established should not be intentionally broken ( unintended consequences are always part of human activity ). So at some point there should be a stable version of OR that represents the endpoint of MSTS backward compatibility and development from that point maintains that compatibility but does not further enhance it.

Regarding the total thread, very interesting and informative discussion, too much to digest in one sitting. So many well thought out ideas and proposal leaves one wondering if it can all come together, indeed, within the discussion are gloomy predictions, however, being a glass-half-full type -- I'm hopeful of a satisfactory outcome.

I'd like to personally thank James Ross, whose tireless work sometimes goes unnoticed since so much of it occurs out of sight by the larger user community.Thank you, James. http://www.elvastower.com/forums/public/style_emoticons/default/hi.gif

[cjakeman]

 Genma Saotome, on 08 July 2020 - 10:45 AM, said:

Chris, is there a path to DirectX10 and beyond? If so, what is it?

Switching to MonoGame gives us the potential to move up from DirectX 9 to DirectX 11 (which I think is as far as MonoGame has got to date) (and would also make a Linux port simpler).

I've not seen any plan yet for what we do with that potential. What would you like to see?

[Genma Saotome]

 cjakeman, on 08 July 2020 - 01:02 PM, said:

Switching to MonoGame gives us the potential to move up from DirectX 9 to DirectX 11 (which I think is as far as MonoGame has got to date) (and would also make a Linux port simpler).

I've not seen any plan yet for what we do with that potential. What would you like to see?

Get better fps. Even better w/ DirectX12.



All of the old routes limited terrain to one or two tiles either side of the mainline. AFAIK, rendering terrain is done by patches. IF that is correct, than the minimalist approach would have to deal with 576 patches -- 9 tiles * 64 patches each. If near terrain is provided to it's fullest extent the number of patches increase from 576 to 7744, a not inconsequential increase. If, OTOH rendering is done for the whole tile at once then the change is from 9 to 121. Adding far terrain is, well, adding even more work.

FWIW the first major task I took on after the view distances were increased was to add near terrain to the routes I work on, out to 5 tiles, and where relevant added DM terrain out to 100km. It looks great, but comes at a fps cost.

[YoRyan]

 R H Steele, on 08 July 2020 - 10:56 AM, said:

I also am of the opinion that MSTS compatiblity need not be as rigorously adhered to going forward, although I believe there still are issues that involve MSTS models used in the UK and Europe that do not fully function in OR.

Compatibility, once established should not be intentionally broken ( unintended consequences are always part of human activity ). So at some point there should be a stable version of OR that represents the endpoint of MSTS backward compatibility and development from that point maintains that compatibility but does not further enhance it.

So I'm having a little trouble understanding your viewpoint - MSTS compatibility needn't be "as rigorously adhered to going forward," but to add new functionality to the simulator, we need to fork an entirely new version of Open Rails?

[Genma Saotome]

WRT compatibility... there is what compatibility means, which is clear enough, and then there is the scope to which that is applied. As one of many voices arguing for backwards compatibility I had an unspoken scope in mind -- as did everyone else. My unspoken scope was limited to route files and rolling stock. Other people had in mind those plus activity files. And others probably had in mind everything that had ever been done and seen.

Not discussing scope was, I think, what allowed the project goals to shift from a new simulator to a pure emulator on steroids.

Even if scope had been discussed and agreed upon the vote may well have been for what actually occurred.

My point is such decisions, by commission or omission, can always be revisited. AFAIK there will eventually be the last version of OR that will run on XP. Maybe it's already done but not advertised as such. It can be made available to those who cannot go further with their hardware an OS. IMO the same can be done with 100% MSTS backwards compatibility; there would be a bigger fuss of course but so long as there is an Official MSTS Compatible version for download, people who want to run stuff that way can. A tip of the hat in respect to all those who got the software there. And the handful of developers that remain active can take a look at creating a new simulator design, reusing as much of OR as is practical, but limiting the convertibility of old to new to routes and rolling stock and to do so in the new design definitions. IOW conversion programs. Perhaps that will bring more to tbe project.

As Marie Kondo might say, "Thank you OR for teaching me how to ...." and then moving on to something new that sparks joy.*



* For those who don't know the reference, Marie Kondo is a tiny Japanese woman (135cm) whose consulting business is to help people de-clutter their closets; If the object no longer sparks joy, thank it for its service, and give it away or throw it out. She is both respectful of the past and ruthless about how to go forward.

[R H Steele]

 YoRyan, on 08 July 2020 - 02:07 PM, said:

So I'm having a little trouble understanding your viewpoint - MSTS compatibility needn't be "as rigorously adhered to going forward," but to add new functionality to the simulator, we need to fork an entirely new version of Open Rails?

To clarify ( hopefully ) no need to fork ---- although to quote from James Ross post #6

Quote

Easier to contribute: esp. on GitHub but also on Launchpad it is easy to share your own "fork" (modified version) of the code and, importantly, for us to merge that back into the main version if desired

At some point in development the management team should announce that version such&such has completed legacy compatibility and no further additions will be contemplated...that version should be a stable version, monogame, and whatever else is deemed desirable by the team. The development goes forward using new file formats, and new ORTS additions and content---without breaking the legacy compatibility. Is no legacy breakage possible?...I would hope so, but beyond my skill set to have an informed opinion about.

The thorny question is when does that happen...I leave that to yourself and others of the team to decide...perhaps a poll, thread, or a culling ot the Trello cards to see what important legacy issues still need to be resolved before that point in development is reached. Now, make no mistake, whenever that announcement is made there will be great howls, gnashing of teeth, and hair tearing no matter what...but this situation of one foot in legacy compatibility and one foot in progressive advancement of OR will have to cease.

Hah, HAH... just read Dave's post with the quote from Marie Kondo --- exactly the attitude I take when cleaning out my library of books to make room...it's a hard method to apply but absolutely necessary....the joy component is surprisingly easy to apply and in my experience ---foolproof.

[YoRyan]

 R H Steele, on 08 July 2020 - 02:49 PM, said:

At some point in development the management team should announce that version such&such has completed legacy compatibility and no further additions will be contemplated...that version should be a stable version, monogame, and whatever else is deemed desirable by the team. The development goes forward using new file formats, and new ORTS additions and content---without breaking the legacy compatibility. Is no legacy breakage possible?...I would hope so, but beyond my skill set to have an informed opinion about.

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. :)

[R H Steele]

Your optimism is heartening...thanks...let's hope that the skill and ingenuity of the whole team (and users testing and guiding OR with constructive feedback ) can accomplish what you propose.
Regards, Gerry

[SYogurt]

I would love to see some content developers band together and provide 'base content' for a 'new' Open Rails. Even if it was still Open Rails as it is right now, today, 're-releasing' Open Rails with dedicated, OR specific content would be a great way to build interest in the project.

I'm currently working on Amtrak related content, with a full slate of P32AC-DM/P40/P42 units, along with Viewliners and Amfleet IIs. 3D cabs, the whole gambit. If I was searching for a new simulator, and didn't want to drop huge amounts of dollars, Open Rails is the ONLY way to go, but it's daunting without content included, for people who haven't been around this game since 2005 like I have.

I'm aware my input probably isn't super valuable - but I think the biggest improvements should be done in the way of performance, shaders, support of bump/normal mapping, and built in Route/Consist editors. I don't think the physics really need that much effort put into them right now - they are already really solid - I think OR just needs to look a little nicer and be a little easier to make content for without having to deep dive into forums to find legacy tools.

Kyle

[Genma Saotome]

Kyle, there are many, many ideas in the private forum that could be reviewed. Here's a couple of features I have suggested over the years that do not rely on replacing KUJU's data structures with something completely different:

• Camera sets: Up to 10 cameras per set, perhaps as many as 10 sets. Define a keystroke combo to switch between sets, something like <alt><Shift>1 o thru 9 and then 0 thru 9 to pick a camera.
  
• Use the .sd file as KUJU obviously intended -- a Shape Description file -- to put into the game all model data that is never going to be captured in any 3d modeling tool. Stuff like what hours of the night are night textures to be used. Initially this is accessed from the .sd file and not added to the world file until such time there is an editor that can do it.
  
• Displayable metadata for all rolling stock, stuff like passenger car name, road initials, car number, consignee, lading name, and so on. Does anyone really value seeing a run of integers above each piece of equipment? Would it not be easier when switching hthe Davis Lumber company to see "Davis Lumber Co" above one of the boxcars?

And so on.

There has always been a... oh, I'll use this phrase for lack of the best term, a fear to make a KUJU file incapable of being used in Train.exe. That made sense years ago when OR had not achieved such a high degree of solid MSTS emulation. But now is there any reason to continue that practice? IMO that is a question the OR team should discuss. I had advocated that for OR 1.0 but I did not carry the day. That was several years ago and emulation is stronger today than it was then. I really do think teh question needs to be discussed.