[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.

[roeter]

Does it all really have to be so complicated?

What about this :

• Route-related options are stored in a route-based file, located in the route directory or the OpenRails directory within the route directory.
  The name and extention of the file don't not matter as long as the full name is unique.
  
• On selecting a route in the menu, or, on start-up, for the default route, the program checks the existence of said file.
  If it exists, values are loaded and set as active values in the options menu.
  
• A button is added to the menu : "Store settings as route default".
  If activated, the actual settings are stored in said file, either creating that file as new or overwriting the existing file.
  
• Perhaps an additional button could be provided "Remove route default settings". This would remove said file.

It seems to me this does what most people want - without the need to make any extensive changes to the UI.
Options which are saved / restored as route related options could perhaps be marked in some way.

Regards,
Rob Roeterdink

[James Ross]

roeter, on 29 October 2014 - 01:18 AM, said:

It seems to me this does what most people want - without the need to make any extensive changes to the UI.
Options which are saved / restored as route related options could perhaps be marked in some way.

I can see a few problems:

• If you've got a route selected that has its own options, you can't change the global options without changing route or deleting that route's custom options.
  
• Either it doesn't in any way support having some settings vary by route and not others.
  
• Or you have a fixed set of options that can be set per-route, in which case you'll need to make that very clear on the options dialog and would be pretty non-intuitive behaviour.

Anyway, it would be nice not to have people trying to propose how we build features before we're sure what we even need or when we need it.

[roeter]

James Ross, on 29 October 2014 - 01:52 AM, said:

I can see a few problems:

• If you've got a route selected that has its own options, you can't change the global options without changing route or deleting that route's custom options.

Why should one want to change the global value of an option if that value is not what is wanted for that particular route anyway?
And, ofcourse, just as there could be a button to store as route-related values, there could be a button to store the present values as global values.

Quote

• Either it doesn't in any way support having some settings vary by route and not others.

I never said we should store all options.
Anyway, even if you did store all options, only those which are changed would actually vary.

Quote

• Or you have a fixed set of options that can be set per-route, in which case you'll need to make that very clear on the options dialog and would be pretty non-intuitive behaviour.

As I said, options which are stored per route could be marked in some way.
A simple "*" in front of the value, with a note at the bottom : "* : Route related option" would be quite clear to most people.

Quote

Anyway, it would be nice not to have people trying to propose how we build features before we're sure what we even need or when we need it.

It wasn't me who brought up UI arguments - which does not look like an argument on what or why we need it.
Further, any method used will have to be very variable when it comes to which options are stored or not, or all, or whatever. Nobody knows which options might be added tomorrow, next week or next year. So any method must be independent of the options itself.
Also, ofcourse, there is nothing mysterious about options. In all, it's just a line of text in a file.

Finally, it would clarify this discussion no end if you just stated "I don't want it" - rather than to come up with none-arguments in reply to anyone who tries to suggest or propose something in favour of it.

Regards,
Rob Roeterdink

[Genma Saotome]

Thank you Rob, you said it all better than I would, especially the red stuff.

FWIW, I change several of the so-called global settings almost every time I change routes.

If it makes good sense to separate route settings set by the route builder (the .trk file) from route settings set by the end user, that's ok by me, tho for what I understand of the issue it seems an arbitrary division... consider overhead wire height and voltage: If somebody wanted to run different equipment they might want to change that. What's the problem with that? But like I said, if there are good reasons why some of that data should always remain fixed for all time by the route builder, then yeah, then it would be smart to put the editable stuff elsewhere.

Something else, if perchance part of the objection is purely technical -- settings that come off the options screen are not easily changed moments later due to the structure of objects and their data in the code, well, I would acknowledge then that the proposal of route specific settings could be more difficult to implement... but that is a different issue that the reasonableness of need that the request reflects.

[R H Steele]

I'm hesitant to insert myself in this battle of the titans. (note the small "t" gentlemen :victory: ) (I don't even remotely look like Zeus and don't own a ZeusSuit [ouch] ) but perhaps this should be tabled. It is obvious it was premature to bring it up now. I seem to be having a spate of farkakte notions lately.

I think all can agree on these points
1. Currently OR runs most routes without this option. (gotta be way up in the 95%++)
2. We can all agree that routes vary greatly in complexity and construction
3. In the future, to handle these inherent route differences with more finese - aka "fine tuning" it might be necessary to look at saving OR operating options on a per route basis.
4. The details of that discussion can be set aside until that time arrives. More immediate issues need solutions.
4. We should leave actual modification of route data files to the tastes and talents of individual users.

I have acquired too much respect for all participants in this discussion to demand anything, but honestly, it's starting to sound like bickering. So let's put this thread :Neeeedsleeep: