Viewing Issue Advanced Details
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|06171||Core||Minor||Always||Mar 30, 2016, 19:31||May 28, 2016, 19:52|
|Tester||Zaghadka||View Status||Public||Platform||MAME (Official Binary)|
|Assigned To||Resolution||Reopened||OS||Windows Vista/7/8 (64-bit)|
|Version||0.171||Fixed in Version||Build||64-bit|
|Summary||06171: Specialized ini file settings get retained on a second game launch, instead of using raster.ini or mame.ini|
|Description||When you start a game from the GUI that has a specialized ini file, in my case "scramble," and then launch another game in the same display family (i.e.: raster), it does not use the generic raster.ini or mame.ini settings, it uses the previously selected specialized set settings.|
|Steps To Reproduce||
Start a game from the UI. I use scramble, because I have a special .ini file called scramble.ini. Other games fall back to raster.ini.
Press escape to return to the GUI.
Launch another game in the same family, eg rthunder, which doesn't have a rthunder.ini. Since this game does not have a specialized ini, it should use the settings in raster.ini.
Game uses the specialized ini settings previously loaded instead of the lower priority ini settings. The same happens with something like raster.ini to mame.ini. The higher priority specialized settings are loaded instead of mame.ini.
This occurs with both vector and raster games. The settings I have noticed that are being retained from the specialized set ini are, for vector, CORE VECTOR, beam_width_min in omegrace.ini, which did not use the setting in vector.ini for a game with no set-level ini, and for raster, DIRECT3D POST-PROCESSING, hum_bar_alpha in scramble.ini, not using the setting in raster.ini for a game with no set-level ini.
I have also noticed that raster.ini's settings will be retained over mame.ini's to a vector game in the absence of a vector.ini file to override it. mame.ini's settings should be used for a vector game if there is no vector.ini, not raster.ini's settings. Tested by launching a raster game, and then launching the vector game with the differing mame.ini beam_width_min settings. Also, a clone set's ini will be retained over the parent set's .ini, when launching the clone first, then another clone with no ini. It should use the parent ini, not the previously loaded clone ini.
When the game that is launched second has its own specialized ini as well, at the same level as the previous game, then the new specialized settings are used. However, if the specialized ini is missing an entry (in this case I had an old ini that didn't have hum_bar_alpha included at all), it will use the specialized entry of the first launched game, rather than getting the setting from raster.ini or mame.ini as it should. I tested this by having a hum_bar_alpha in mame.ini, but not rthunder.ini, launching scramble.ini with hum bar set up, and then launching rthunder.ini. rthunder.ini retained the missing setting from scramble.ini, instead of falling back to mame.ini's hum bar setting.
It seems that ini settings are being retained by the GUI when they shouldn't be. Once you launch a game with a specialized set-level ini file, there is no way to get back to launching under the lower-level raster.ini or mame.ini without shutting down the GUI and starting over.
When an old file does not have the correct software paths (I use "roms; software" as my rompath variable) that too is retained from the specialized ini, instead of getting the paths from mame.ini or raster.ini. This has caused the GUI to tell me that software sets I have do not exist, because it no longer checks mame.ini for the paths, but instead the older set-level ini that only has rompath=roms set.
Basically, I can't think of a simpler way to put it. The hierarchy of ini's is not working on a second launch in the GUI. Once you use the highest-priority ini, there is no way to launch again a game that doesn't have a set-level ini, and should instead use the lower-priority ini. I assume it is meant for all games launched from the GUI after the first to behave as if it is the first launch with regard to ini's.
|Affected Sets / Systems|
|There are no relationsihp linked to this issue.|
Mar 31, 2016, 01:24
Thanks for the report. I haven't noticed this behavior before you wrote this report, but I can confirm this behavior.
To easily confirm this I used a simple game like sf2. I copied the raster.ini and renamed it sf2.ini and changed the bloom_scale, curvature, and round_corner to outrageous values.
It's then carried over to a different game just as you wrote.
Mar 31, 2016, 21:25
|Interestingly, this bug affects MameUI as well. Any case where you leave MAME open and launch multiple games causes the high-level ini's to get stuck in place as the settings.|
Apr 1, 2016, 15:45
Fixed by dankan1890:
May 28, 2016, 09:15
|I checked this in 0.174 by creating a specialized ini for a game, changing filter to 0, seeing the change in said game and then launching another one. The filter was correctly back to default 1 again. Is this fixed? I saw the dev reopened it for a reason.|
May 28, 2016, 19:52
|From what I can tell the issue is fixed. The steps to reproduce fail when I try with 0.174|