[vince]

shadowmane, on 27 December 2018 - 06:33 AM, said:

There are quite a few routes I currently have that I can't use. Zigzag, the OR Demo Route, LIRR, just to name a few. Even Somerset and Dorset Joint Railway gives me problems. I love these routes when I can use them, but if I start in certain places on those routes, the computer grinds to a halt.

I'm interested to know why your having difficulty with the LIRR.
How do your system specifications compare to the specs on my machine that I included with the LIRR route ReadMe documentation?


regards,vince

[shadowmane]

I don't know the exact specifications, but I know the computer is roughly 8 to 10 years old. I don't think it has a graphics card but uses onboard graphics. I know it's 32 bit. I think I've shared the specs here before, but that was a year or two ago. It's pretty much a dinosaur, but it runs MSTS pretty well. A lot of the newer routes it struggles with.

[vince]

shadowmane, on 27 December 2018 - 04:06 PM, said:

I don't know the exact specifications, but I know the computer is roughly 8 to 10 years old. I don't think it has a graphics card but uses onboard graphics. I know it's 32 bit. I think I've shared the specs here before, but that was a year or two ago. It's pretty much a dinosaur, but it runs MSTS pretty well. A lot of the newer routes it struggles with.

Yes, running with MSTS and you get a crash it's pretty much a mystery.
Nice thing about Open Rails is if you check the Logging box on the OR opening screen you'll get an OpenRailsLog.txt file on your desktop and fafter a crash you can look at the log and possibly find a reason for the crash. Running OR I'd guess it needs at least a dual core cpu. Log shows all your CPU and graphics too. Onboard graphics are iffy at best.
I 'know' it wont work well on a single core Hyper Thread system as that was what I had 4 years ago and OR would not run.My four year 'old' I5-Quad core runs everything fine. Nvidia GTX-650 is 'old' too but runs OR well.

Regards,
vince

[Genma Saotome]

in response to a comment about route specific performance...

R H Steele, on 26 December 2018 - 10:18 PM, said:

That is precisely why I have always wanted route specific settings for OR...cached somewhere, so that whenever a specific route is used, a specific set of game options are called up.

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

The other wrinkle is how much view distance affects performance. For one activity you may be fine using the old MSTS 2km and crushed when extending the view to 10km and for another for the same route the long view gives perfectly acceptable performance.

A long, long time ago James and I disagreed about where the various options are set. :aggressive: He wanted global settings specified before the activity was launched, I wanted activity specific settings for almost all items. Guess who won the debate? :vava: Like most disagreements both people had perfectly valid points. His prime concern was that by doing what I wanted to have done the complexity of figuring out each bug report would be vastly increased. IIRC at the time there wasn't the in-depth logging there is today. I wanted flexibility of features for end users.

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.

[EricF]

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.

Few games I know of offer this, though. Most have a default or auto-detect baseline, and then user settings are individual changes on top of that. Probably because no one wants to spend resources and time with programming a profile storage/recall system when mainstream gaming users just want to crank everything up to the max that their system will handle. True sims are a little different, with more variability based on the simulation environment that's running...

[Genma Saotome]

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

Probably because no one wants to spend resources and time with programming a profile storage/recall system when mainstream gaming users just want to crank everything up to the max that their system will handle. True sims are a little different, with more variability based on the simulation environment that's running...

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.

[EricF]

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.

On the other hand, putting graphics settings (at least suggested ones that could be user-overridden) at the activity level is fine -- for classic MSTS-style activities. Timetable mode would need to be considered though, since it's a very useful way to operate in OR. It might be more of a component of the route itself. The default or recommended graphics settings could be expressed in the GUI, and modified by the end-user, prior to launching the activity or timetable session on that route.

[Genma Saotome]

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.

The alternative we got is somebody wrote a program that puts a UI between you and your data and in some cases that's a great idea (think path creation) and in others it is just an impediment to doing anything new (some of the obsolete checks in route riter). Finding the right balance can be hard... obviously it's essential for a graphical or 3d imaging situation... but run of the mill data vales? Not IMO.

===================

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?

[perpetualKid]

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.

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

[conductorchris]

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