[R H Steele]

 James Ross, on 28 October 2014 - 01:49 AM, said:

My question any time someone asks something like this is: what are you changing and why are you changing it per-route? Without understanding the problem you have, we can't be sure we'll end up with the right solution. :)

Always a logical starting point, no disagreement from me.
However, I would hesitate to call this a problem, rather a way to provide users with the means to encode route performance data tailored to their specific needs (and also hardware configs) into OR. Once encoded, the data would load with the route, relieving the users with having to make option changes each time a route was loaded. OR easily supports multiple installations, having end user route options choices would also enhance the experience.

I could see ""route option" profiles being recommended for routes to provide higher frame rates (if so desired) or better graphic quality. It could be something as simple as turning on the overhead wires and not using signal glow. Once performed for that route and added to it's load options the user could forget about it. Or maybe at loading be presenting with a choice to "load route options" or default to the standard OR loading.

Perhaps, looking ahead, it could mean loading different car spawners, a specific weather scheme, or something else. There may be limitations because of coding obstacles, I really don't know.
Multi-Player could present a problem, although I know nothing about this area.

To be honest, this is likely post Ver1.0, nothing to do with MSTS compatibility at this point in development. Most routes run quite nicely without a route option tab. IIMO, it would provide users with a way fine tune their setup to specific routes, and as more people find and use OR this may make the experience easier.
Only the programmers can determine if any of this is achieveable.

[James Ross]

 Lindsayts, on 28 October 2014 - 08:01 AM, said:

I have tried the option that varies the viewing distance to keep the frame rate constant but this option (at this stage anyway) does not produce as good a result as manual tuning.

...

Basicly changing the options config between routes allows on a better train sim experience allowing one to tailor OR to suite the route concerned. Generally the longer the viewing distance the better, on high object count per tile routes though (most newer routes) such viewing distances produce an unacceptabely low frame rate.

Okay, so you're just changing the viewing distance to keep performance reasonable. Would you not prefer we improved the automatic option rather than having every user set up per-route settings?

I've definitely got a number of potential improvements lined up for the automatic tuner but welcome all comments. Do you have examples of what it gets wrong or doesn't do well?

 R H Steele, on 28 October 2014 - 08:46 AM, said:

Only the programmers can determine if any of this is achieveable.

One of the primary reasons for pushing back on this suggestion is that I don't believe it's easy to do, or to do well, especially the UI component (I have experience with trying to do a somewhat similar system for another app). It's certainly not a bad idea but, like you also said, probably not something we should attempt just yet.

[Genma Saotome]

 James Ross, on 28 October 2014 - 08:55 AM, said:

Okay, so you're just changing the viewing distance to keep performance reasonable. Would you not prefer we improved the automatic option rather than having every user set up per-route settings?

Not everyone is looking to optimize performance. In many cases there is going to be some balance between an acceptable performance and a desired appearance. And with that in mind, to answer your question, no, I would not prefer an automated feature. I think it highly unlikely the OR team could develop an automated process that knows more about what the end user wants to do -- and what his machine will allow him to do -- on a route by route basis. I have one route where, on certain activities, I push the DM viewing distance out to 100km and another route where it is zero. How on earth would you that's what I wanted?

So my vote, should there be a survey, would be (at a minimum) to append the choices to the routes .trk file. In the ideal I'd also want a wholly optional override attached to the activity.

 James Ross, on 28 October 2014 - 08:55 AM, said:

One of the primary reasons for pushing back on this suggestion is that I don't believe it's easy to do, or to do well, especially the UI component (I have experience with trying to do a somewhat similar system for another app). It's certainly not a bad idea but, like you also said, probably not something we should attempt just yet.

Might you explain why it would be hard to move a couple of items from the option tabs at startup to the route's .trk file? Or are you making reference to something completely different?

[Genma Saotome]

 James Ross, on 28 October 2014 - 06:03 AM, said:

That is something completely different - those "options" are for the route creator, not the user. They are already supported by Open Rails where it makes sense. The discussion here is (AFAICT) about letting users change game (not route) options per-route, such as viewing distance.

As a route creator I see nothing wrong at all with end users changing any of the specifications in a routes .trk file. People have been fiddling with routes since day one and I see no reason to prevent that.

[James Ross]

 Genma Saotome, on 28 October 2014 - 10:14 AM, said:

Might you explain why it would be hard to move a couple of items from the option tabs at startup to the route's .trk file? Or are you making reference to something completely different?

They couldn't be moved because then we'd be left with no global option and you'd be forced to define it per-route for every single route if you didn't like the default. So you'd have to support them as global and per-route settings, which means merging them - which would be easy except that lots of things load long before the route is even known. It's certainly not impossible, but it is in no way simple.

And I would be more concerned about the UI, as that is much more important to get right and I have first-hand experience of attempting such a thing.

 Genma Saotome, on 28 October 2014 - 10:18 AM, said:

As a route creator I see nothing wrong at all with end users changing any of the specifications in a routes .trk file. People have been fiddling with routes since day one and I see no reason to prevent that.

You're conflating users editing their content (which they are of course free to do, though most wouldn't touch it) and users just picking settings for the game. There's also no way we're going to be saving user preferences to the .trk file. :)

[Lindsayts]

 James Ross, on 28 October 2014 - 08:55 AM, said:

Okay, so you're just changing the viewing distance to keep performance reasonable. Would you not prefer we improved the automatic option rather than having every user set up per-route settings?

That would be ideal if it could be acheived, the problem at this stage is the auto option is not quite good enough.

Quote

I've definitely got a number of potential improvements lined up for the automatic tuner but welcome all comments. Do you have examples of what it gets wrong or doesn't do well?

If there is some improvements for the automatic tuner it would be worth putting them in before going any further. I find the auto tune is ALMOST good enough, but it consistantly to slow in reacting to tile object density changes. The main thing one notices though is when the object density increases the frame rate will drop below 30fps (target 60fps) for a significant length of time before it starts releasing items from its cache. I set the target frame rate to 60fps, but I find OR is quite smooth down to 30fps, the problem one encounters though is the autotuner consistently lets the frame rate get below half the target rate before it starts dropping the viewing distance.

To sum up I find the autotuner is almost good enough but manual tuning still produces a better experience, if there is code improvements it would be worth putting them in if there is a chance it will solve the problem. I still believe in the end though it would be a good idea to be able to set the options up on a per route basis.

Quote

One of the primary reasons for pushing back on this suggestion is that I don't believe it's easy to do, or to do well, especially the UI component (I have experience with trying to do a somewhat similar system for another app). It's certainly not a bad idea but, like you also said, probably not something we should attempt just yet.

I completely understand this, would there be any easy way to make different installs of OR use there own specific registry entries.

The bigger picture DOES need to be kept in mind though, I would cheerfull sacrifice this (and a lot of of other things) for the the development on an OR route editor to be started, some kind of OR route editor is now sorely missed.

Lindsay

[James Ross]

 Lindsayts, on 28 October 2014 - 12:05 PM, said:

If there is some improvements for the automatic tuner it would be worth putting them in before going any further. I find the auto tune is ALMOST good enough, but it consistantly to slow in reacting to tile object density changes. The main thing one notices though is when the object density increases the frame rate will drop below 30fps (target 60fps) for a significant length of time before it starts releasing items from its cache. I set the target frame rate to 60fps, but I find OR is quite smooth down to 30fps, the problem one encounters though is the autotuner consistently lets the frame rate get below half the target rate before it starts dropping the viewing distance.

My ideas are not fully formed yet, but hopefully some time I'll get the details sorted out.

Thanks for the feedback, I too have seen it quite slow to react to problematic areas (e.g. loading a new high-density tile). It does tune the viewing distance faster the further the FPS is from the target, but it seems like it needs some kind of "jump" in cases of bigger changes. I'll think on this and see if I can code something up.

There are also a couple of known issues with it, such as when it tunes the viewing distance it doesn't trigger a tile update, which means that it isn't affecting the number of tiles loaded (up or down) until you next cross a tile boundary. This can certainly be fixed though.

 Lindsayts, on 28 October 2014 - 12:05 PM, said:

I completely understand this, would there be any easy way to make different installs of OR use there own specific registry entries.

What you can do is create an "OpenRails.ini" in the executable's directory; at that point, those executables will save all settings in that INI file - including their list of installation profiles. You would have to separate the routes in to different MSTS "installs" based on the settings you wanted to use and remember which one to run, but it should technically work today.

[R H Steele]

Linsayts made the point better than I could have in his post concerning the automatic tuner. I also think "getting the UI right" is extremely important - that's the first impression item a new user encounters.
I also agree with Lindsayts that tunable options per route may have a place. Now I usually manually adjust options for different routes.

[Genma Saotome]

 James Ross, on 28 October 2014 - 10:47 AM, said:

They couldn't be moved because then we'd be left with no global option and you'd be forced to define it per-route for every single route if you didn't like the default. So you'd have to support them as global and per-route settings, which means merging them - which would be easy except that lots of things load long before the route is even known. It's certainly not impossible, but it is in no way simple.

It reads very much like you've picked the worst case to trot out as the defense of your position. There are other ways: You make whatever is added to the .trk file as optional over-rides. If they're present the over-ride is taken, if not, the global value is used. What is so awful about that?

 James Ross, on 28 October 2014 - 10:47 AM, said:

You're conflating users editing their content (which they are of course free to do, though most wouldn't touch it) and users just picking settings for the game. There's also no way we're going to be saving user preferences to the .trk file. :offtopic:

No, I am not conflating things. I've changed values in many route .trk files and I expect I am not the only one to do so. It's just data, not the 10 commandments.

[James Ross]

 Genma Saotome, on 28 October 2014 - 09:09 PM, said:

It reads very much like you've picked the worst case to trot out as the defense of your position. There are other ways: You make whatever is added to the .trk file as optional over-rides. If they're present the over-ride is taken, if not, the global value is used. What is so awful about that?

That is exactly what I'm talking about, if you read my post! My point is that that is actually not simple to do, for the reasons I explained in my post.

 Genma Saotome, on 28 October 2014 - 09:09 PM, said:

No, I am not conflating things. I've changed values in many route .trk files and I expect I am not the only one to do so. It's just data, not the 10 commandments.

Yup, it's data, route data. That's a separate thing to game settings.