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

[Lindsayts]

Hmmmmmmmmmmmmmmmmmmm, A point of order mr Chairman.................

One must be _____VERY______ carefull when accusing volunteeers. Anyone that has some kind of power over his fellows can order who or what he/she likes. With Volunteers it's an entirely DIFFERENT kettle of fish. its not unkown (I can give details of reallife examples here) For a senior member of a volunteer project to make an ill thought out remark that will lose 30 percent of the workers. I would class a good leader of volunteers to be some of the most gifted humanitarians on the planet.

Each of us and I am talking about all active people working on OR the main developers and others are working on a section of the sim they think to be important. I can see VERY LITTLE eveidence of crossover, ie some one transferring his energy into another part of the project he is not interested in.
My impression of James's remarks is that he feels he is being pushed down a path he is not really interested in, In this respect almost anyone else in OR under the same circumstanes would be doing the same thing.

While per route options would be nice and I think they are also deserved THEY ARE SIMPLY NOT WORTH any chance of comming to blows. THey are just one more thing to put on the to do list. One day someone with time to spare will see it and think "thats a good idea" and start working on it.

We are all working on OR because we think we can contribute a little somthing we think is important to the sim, PLEASE respect others work even when they are working on something that does not interest you.

Note: this is independant of RH Steele's post I started wrting this before his post appeared and like all important post I put a lot of time into this one.

Lindsay

[R H Steele]

Lindsayts, on 29 October 2014 - 11:28 AM, said:

While per route options would be nice and I think they are also deserved THEY ARE SIMPLY NOT WORTH any chance of comming to blows. THey are just one more thing to put on the to do list. One day someone with time to spare will see it and think "thats a good idea" and start working on it.
Lindsay

I concur, most wholeheartedly, with exception noted ... I'm not sure they are "deserved" but perhaps consideration is a better word (just a personal preference)