 No.12149
Tafoid Administrator
Nov 10, 2015, 18:35
|
It doesn't matter how many places a config item is stored - there is a certain order of application which is used where the last setting accepted from your config files is used, In the DOCS, in the CONFIG.txt file under the command for "readconfig", there is an list of .config file types outlined which shows you the order which they are loaded. If an item lower on the list matches another options, the previous one is superseded.-[no]readconfig / -[no]rc .cfig files, while similar, run under a separate system completely and if you have a .cfg file contradicting anything in any .ini file, the .cfg file will be used for the driver/setname/default settings, depending on filename. |
|---|---|
 No.12150
Mamesick Senior Tester
Nov 10, 2015, 21:03
edited on: Nov 10, 2015, 21:04
|
Looking at source code in EMUOPTS.CPP <driver.ini> is parsed before <parent.ini> not before vertical/horizontal (which are equally ranked) // next parse "source/<sourcefile>.ini"; if that doesn't exist, try <sourcefile>.ini
std::string sourcename;
core_filename_extract_base(sourcename, cursystem->source_file, true).insert(0, "source" PATH_SEPARATOR);
if (!parse_one_ini(sourcename.c_str(), OPTION_PRIORITY_SOURCE_INI, &error_string))
{
core_filename_extract_base(sourcename, cursystem->source_file, true);
parse_one_ini(sourcename.c_str(), OPTION_PRIORITY_SOURCE_INI, &error_string);
}
// then parse the grandparent, parent, and system-specific INIs
int parent = driver_list::clone(*cursystem);
int gparent = (parent != -1) ? driver_list::clone(parent) : -1;
if (gparent != -1)
parse_one_ini(driver_list::driver(gparent).name, OPTION_PRIORITY_GPARENT_INI, &error_string);
if (parent != -1)
parse_one_ini(driver_list::driver(parent).name, OPTION_PRIORITY_PARENT_INI, &error_string);
parse_one_ini(cursystem->name, OPTION_PRIORITY_DRIVER_INI, &error_string);
|
|
No.12151
Tafoid Administrator
Nov 10, 2015, 23:19
edited on: Nov 10, 2015, 23:20
|
It is possible when I when through and fixed up the documents a while ago I misread this below to mean <driver.ini> and placed it higher on the list because of it// if we have a valid system driver, parse system-specific INI files Other than that, there shouldn't be much of an issue with order. |
 No.12153
u-man Tester
Nov 11, 2015, 02:23
edited on: Nov 11, 2015, 02:39
|
".cfg files, while similar, run under a separate system completely and if you have a .cfg file contradicting anything in any .ini file, the .cfg file will be used for the driver/setname/default settings, depending on filename. " And this is exactly, what IMHO is inconsistence behaviour. I dont mind the other stuff that .cfg is storing, like for example horizontal/vertical stretch, position etc. , because you can not find this stuff in a .ini . Brightness, Contrast, Gamma on the other hand, can be found in both places. And just for information, the .cfg file doesnt store only the last setting, thats why i wrote a brief decription of the problem "Change the Brightness, Contrast, Gamma settings via the sliders."... which means it stores all three sliders and make the problem even worse. To be honest, there is no logic behind this (or at least i dont see it), for having such relevant parameters in two places. Either store any slider action and not just a few in the .cfg and that would be, what i described the best solution, or dont create conflicts by having important parameters in two places. To follow your statement regarding the layering of .ini´s, a .cfg file would be the last and not a game.ini. Or to make it short: .cfg settings should not influence any .ini settings at any cost. |
|
No.12157
Tafoid Administrator
Nov 11, 2015, 16:19
|
Short of taking those video options out of the slider menus, under the current system, I'm not sure what else that someone can do to avoid it other than making sure not to conflict your own settings. Setting up any special exceptions and checking for previous adjustments from default of any of those settings you describe only complicate the code and potentially allows for more stuff to go wrong, in my opinion. I cannot say that it is perfect, but it is as flexible as it is for a reason that end users over time have pretty much demanded it and there is a clear path on how things tend to work. This is in my view considered more of a feature request rather than a straight up bug. |
|
No.12160
u-man Tester
Nov 11, 2015, 20:17
|
Sorry... but in no way, i can imagine, that this behaviour was demanded by any user. This inconsistence is so user unfriendly, that i can not find the right words for it, other than WTF. It is quite the opposite, i only know people that are upset by this behaviour. If you really think, this is a feature request... go for it. I will create a macro for myself that deletes any .cfg file upon exit from MAME. The .cfg is not a essential file and not needed at all by MAME, it causes just troubles, like the one i described already (but maybe i write chinese). The only usage i have from a .cfg file is, that it remembers the artwork settings (like use upright, cocktail etc. artworks). I will gladly yield up on the .cfg file, in favor of a absolutly correct working .ini file. |
|
No.12169
Tafoid Administrator
Nov 12, 2015, 00:55
|
I've set status to Direction Needed in hopes some actual developers join into this discussion. Like I said, it is not perfect and I know it. Rewriting it would be time consuming effort and, it would seem, no capable developers are currently jumping to do anything about it. |
 No.14098
anikom15 Tester
Aug 16, 2017, 14:47
|
I actually agree with u-man here. While this behavior may have made sense at one time, it is at odds with how shaders options work. I think consistency needs to be applied. |