[EricF]

Linux would be much happier with some system of .conf files. There's no direct analogue of the Windows registry. Avoiding reliance on the registry may make porting to Linux more straightforward.

I've lived in Windows, Mac OS and Linux... Windows has its Registry, with ways to use .ini files and other text-based config files Mac OS has its unique preference files on top of Unix .conf files, and Linux makes a lot of use of text-based .conf files. The common denominator to work with is some soft of text-based configuration file system. As long as the format is consistent, the extension doesn't matter so much as long as OR knows what to look for. I'd just want to stick to something that's cross platform. If JSON files are going to be used in content, then perhaps the format would be useful for configuration/settings storage and retrieval as well.

[James Ross]

 Eldorado.Railroad, on 22 December 2018 - 11:07 PM, said:

Ok then, so from what I read, any new work will not run under 32 bit, regardless of whatever version of Windows you are using (Win7 32bit included)?

32 bit will continue to be supported - but only with Windows 7 and later.

 Eldorado.Railroad, on 22 December 2018 - 11:07 PM, said:

With Win7 being EOL in 2020, you will abandon support for it as well shortly thereafter?

We're not working to the OS support lifecycle. Windows XP ended all public support from Microsoft in April 2014 - nearly 5 years ago - so I wouldn't call this "shortly thereafter". What is more important is its original age is showing - 2001 vs 2009 (for Windows 7). Using either of these numbers from Windows XP and applying them to Windows 7 suggests we will keep supporting Windows 7 until 2025 or 2027. :)

 Eldorado.Railroad, on 25 December 2018 - 12:35 PM, said:

Exactly!
NETerror.gif

I will image my Win7 system BEFORE trying this out.... too bad.

From Microsoft:

Supported Operating System Windows 10 , Windows 7 Service Pack 1, Windows 8.1, Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016

Supported Operating Systems:

• Windows 7 SP1 (x86 and x64)
• Windows 8.1 (x86 and x64)
• Windows 10 Anniversary Update (x86 and x64)
• Windows 10 Creators Update (x86 and x64)
• Windows Server 2008 R2 SP1 (x64)
• Windows Server 2012 (x64)
• Windows Server 2012 R2 (x64)
• Windows Server 2016 (x64)

Yes, moving to supporting Windows 7 and up will allow us to use newer .NET Framework versions which come with their own advantages - there's a few bits we've retrofitted into OR but most of the benefits I see are in the JIT/GC which we obviously can't.

[James Ross]

 shadowmane, on 26 December 2018 - 01:44 PM, said:

I've been reading through a lot of stuff around here the last couple of days. It seems to me that there is a real need to split this game into Open Rails 1 and Open Rails 2, with Open Rails 2 moving on from MSTS, while Open Rails 1 is completed with the idea that once it is completed, it will be abandoned at a certain point once specific features are available. The future is the Monogame version, which should be "Open Rails 2". It doesn't mean you have to stop development, it just means you are shifting gears and moving towards the future while leaving a version of the game for MSTS users to tool around with. All of the legacy file extension will be kept and used in Open Rails 1, while the new file extension and folder setup would be used in Open Rails 2.

I don't see any particular reason to tie MonoGame into any split in what is supported; this is a runtime library change, really.

If you look at the Open Rails roadmap filtered by content and editor labels you will see that the main goal of 2.x is to have new OR formats and (mostly) editors in place. We don't have infinite resources of course, so I am being pragmatic that it will take years to get some of them done, but we're starting work on them right now with the consist editor for 1.4 (and file format).

 shadowmane, on 26 December 2018 - 01:44 PM, said:

My one issue with Open Rails and it is an issue my youngest son also has, is that there is not really a good solution to route and activity editing. Most of that could be solved by buying a new computer (which takes money we don't currently have). He is currently building a route using the old editors and tools (because TSRE5 simply won't run on any of the systems we have without hiccuping really bad). He was upset today when I told him that when Open Rails moves to version 1.4, I'll be ditching XP and putting Ubuntu on my other XP computer. He simply hates stepping through the hoops it requires to run this game in Ubuntu. That may change with some of the new tools arriving on the scene for gaming on Linux. The DirectX to Vulkan extension for Wine will go a long way towards giving us a way to make this game playable even with our old technology computers.

Unfortunately for him, the Open Rails project is not planning on creating any MSTS-format editors at all. TSRE does run on Linux, however, so maybe things wouldn't be that bad for you with that switch.

It's not on the roadmap, but the switch to MonoGame intentionally opens up the possibility of Open Rails running natively on Linux, though.

 shadowmane, on 26 December 2018 - 01:44 PM, said:

As far as an activity editor, I think it's legacy and should be dropped. You can already do most of what is necessary with the Timetable Editor. If Timetable Editor was extended or forked to create a Freight Timetable Mode, where you pull from pools of locomotives and deliver blocks of cars to their destinations (even if those destinations are off-screen), complete with work orders to complete, you have your activities right there without the need for an activity editor.

You might be right; I've seeded the roadmap with a rough one-to-one replacement of MSTS and contributed tools, but we may not need them in exactly the way they are now. We will certainly need something that can produce passenger station stop "activities" and something that can produce freight shunting "activities" and that might be the same program, or not.

Do note that the timetable editor is still a contributed app, so we will be building an integrated replacement somewhere anyway.

 shadowmane, on 26 December 2018 - 01:44 PM, said:

I'm glad Open Rails is moving on and not looking back. MSTS people aren't really paying attention to Open Rails anyway. Complete your file system and come up with your new file extensions ASAP. Then get to work on your Consist Editor, Route Editor and work on a freight timetable mode instead of wasting time on an activity editor. You've done a great job getting this program to where it is. A few more tweaks and it's in such a stage of completion that you can move on from the legacy MSTS stuff and develop only for your program.

Thanks, hopefully we'll get a clearer idea of what we need to build as we work through things on the consist editor.

[James Ross]

 Genma Saotome, on 27 December 2018 - 06:31 PM, said:

IMO it actually varies by activity. If you are not running through the congested areas why have settings specific to that constraint?

That also speaks to the problem that performance can vary throughout an activity; arriving into a detailed station area can really hurt compared to the open countryside moments before.

 Genma Saotome, on 27 December 2018 - 06:31 PM, said:

It's probably much less a concern today... so many bugs having been squashed... much better logging, so perhaps it might go that way eventually. I certainly hope so.

If we can fix some of the known issues with the "Automatically tune settings to keep performance level" option, I'd be happier that the case is covered. As it stands, I am aware that it is a problem that routes and activities have varying performance that we don't cater to brilliantly.

 EricF, on 28 December 2018 - 08:04 AM, said:

Some sort of user-configurable "profiles" for graphics settings might be a nice quality-of-life feature, along with a set of low-medium-high presets which can be specified as the only valid graphics settings used when troubleshooting or reporting bugs. That would allow end-user flexibility and still preserve baselines for debugging.

We should absolutely have presets for graphical quality (like nearly every other 3D game), so I've placed them on the roadmap.

User-configurable profiles are certainly a more niche feature, which I would prefer to avoid (instead, add presets and make the auto-tuner work better).

 Genma Saotome, on 28 December 2018 - 10:39 AM, said:

In my professional capacity I had the opportunity to design and built several data driven applications, meaning very few "facts" were hardcoded. A practical example would be moving most of the option tabs parameters and values into an activity level file. What you get over the long term is a very easy way to vary what the program can do -- one set of option values for this activity, a different set for another, all determined by the end user and working w/o his intervention at game time. Do it right and you can even have the current global settings retained as defaults so what's in the activity options file are only those things you tweeked.

That would be possible (since the menu can pass settings overrides to the game) but as ever with these types of suggestion I worry about:

• The complexity and quantity of code needed
  
• The number of users who could use and benefit from it

 EricF, on 28 December 2018 - 05:43 PM, said:

That really would be an ideal way to do it... it's just unfortunate that the games development industry hasn't caught on to the idea. To me, flexible but convenient ways to swap out settings values make a huge difference in usability. For Open Rails, taking at least some of the graphics settings to the activity level makes good sense since different routes will likely have different levels of graphical complexity.

If we were to add graphical presets, it may be reasonable to associate them with individual activities and routes. I'm not sure if we'd want that in the menu or in-game though. (This wouldn't be as reasonable without presets due to the number of potential options.)

 Genma Saotome, on 28 December 2018 - 07:14 PM, said:

As James pointed out so long ago moving the values from a controlled situation -- the options tabs -- into a flat file subject to what your fingers are doing can be a recipe for big trouble. OTOH we have .wags and .engs that we edit, sometimes .act, .con, and .w files too that are all edited and the world hasn't burnt to a crisp yet.

It's also an accessibility thing: how do people know they can change more things in the file than the GUI, and how do they learn how to do that? (And is it acceptable that we make them learn all that?)

Content creators are certainly more used to editing text files and delving into the details of things, but the average user isn't.

 Genma Saotome, on 28 December 2018 - 07:14 PM, said:

Returning this tangent back to the basenote, I'm pretty excited about the potential for this change. I think it will help the software keep pace with the always evolving hardware and its OS, it should open the door to routine use of things like ReShade, and gosh, it it helps attract a few more people to code, what more can you ask for?

Indeed, I hope so too!

 perpetualKid, on 31 December 2018 - 11:02 PM, said:

sounds like an Import/Export of all User Settings would step in that direction? Which may lead to an debate whether settings should be stored in registry (as they are today), or rather file based so they can be more easily exchanged, and multiple profiles would be an easy catch.

Open Rails has supported settings in a text file ("OpenRails.ini") since 1.0. Not sure it's documented in the manual, though.

 perpetualKid, on 31 December 2018 - 11:02 PM, said:

Major advantage of the registry approach, one can have multiple versions of the program all finding and using same settings. This could be emulated though with files as well, i.e. having a single registry key pointing to a common storage folder (ie. I do have a single content root outside of the program folder, and different versions of the program in parallel). But that discussion whole discussion is independent from XP or not ;)

The file-based approach to this on Windows is putting the files in the AppData directory in the user's profile, and on Linux in dot-files/dot-directories in the user's profile. We could support this as well.

 EricF, on 06 January 2019 - 04:46 PM, said:

I've lived in Windows, Mac OS and Linux... Windows has its Registry, with ways to use .ini files and other text-based config files Mac OS has its unique preference files on top of Unix .conf files, and Linux makes a lot of use of text-based .conf files. The common denominator to work with is some soft of text-based configuration file system. As long as the format is consistent, the extension doesn't matter so much as long as OR knows what to look for. I'd just want to stick to something that's cross platform. If JSON files are going to be used in content, then perhaps the format would be useful for configuration/settings storage and retrieval as well.

Yeah, for cross-platform some sort of text file format is needed; the existing "OpenRails.ini" should work (although the locations mentioned above would probably want to be used by default). JSON is actually pretty hard to hand-edit, so I'd prefer this to be kept in INI or TOML (similar but much better defined syntax).

[shadowmane]

I've hooked my youngest son up with a programming teacher. He's determined to learn C# so he can help with Open Rails. You guys have inspired the next generation. Just wanted to throw this in here to show that your small project is making a difference in at least one young boy's life.

[Lindsayts]

 conductorchris, on 06 January 2019 - 03:48 PM, said:

Which approach would be more compatible with using open rails in Linex?

The traditional Unix/Linux programming approach is to have all user configurable items in text files. The executable containing no such data only the mechanism to read the text files. As a consequnce of this one of Linux's primary libraries libc has some really excellent text file parsing routines in it. Not all Linux software uses this approach, but a good percentage does. Even the Linux kernel uses a text file to control its startup (/etc/inittab)

Lindsay

[cjakeman]

 shadowmane, on 13 January 2019 - 08:20 AM, said:

I've hooked my youngest son up with a programming teacher. He's determined to learn C# so he can help with Open Rails. You guys have inspired the next generation. Just wanted to throw this in here to show that your small project is making a difference in at least one young boy's life.

That's great to hear.

However, even with a teacher experienced in C#, Open Rails is still a big beast so I would be happy to answer any questions they have. Just send me a PM.