06171: Specialized ini file settings get retained on a second game launch, instead of using raster.ini or mame.ini

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
06171	Core	Minor	Always	Mar 30, 2016, 19:31	Oct 5, 2018, 04:50

Tester	Zaghadka	View Status	Public	Platform	MAME (Official Binary)
Assigned To	Ryan Holtz	Resolution	Fixed	OS	Windows Vista/7/8 (64-bit)
Status [?]	Resolved			Driver
Version	0.171	Fixed in Version	0.203	Build	64-bit
		Fixed in Git Commit		Github Pull Request #

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.
Additional Information	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. Note: Fixed once in 0.174 - regressed again some time later and reopened.
Github Commit

Flags
Regression Version
Affected Sets / Systems

Attached Files

No.12500 B2K24 Senior Tester 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.
No.12502 Zaghadka Tester 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.
No.12505 M.A.S.H. Senior Tester Apr 1, 2016, 15:45	Fixed by dankan1890: http://git.redump.net/mame/commit/?id=1fb4b520e13e1e87f60c6e00d0413eebbcb8b6c6
No.12725 Iaspis Tester 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.
No.12727 B2K24 Senior Tester 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
No.15293 Zaghadka Tester Jul 25, 2018, 21:36	Probably should mark this one resolved as of 0.174. It's definitely fixed.
No.15294 Robbbert Senior Tester Jul 25, 2018, 23:11	Seeing that the original reporter is happy to have it closed, let's make it so.
No.15355 bedrock Tester Aug 27, 2018, 14:02 edited on: Aug 27, 2018, 14:40	Please note this is still a thing so I don't know why it was tagged as resolved. Using 0.200 but it's been there in all builds since then anyway. For instance I have cps1.ini in which I wrote to use intoverscan and a custom .png effect, say after playing sf2hf I want to play rtype, I go back to the list (whether by pressing esc or selecting a new title via tab menu while ingame); my cps1 settings are still there. Next if I create an rtype.ini at the game level in which I put only filter and prescale settings, start MAME and play sf2hf, then rtype, this time the two ini's settings blend: intoverscan, the png effect, and filter+prescale all applied. Only restarting MAME unloads the previous specific ini's settings, in short the issue described in this entry still applies.
No.15388 bedrock Tester Sep 4, 2018, 17:41	Please reopen ? <3
No.15448 bedrock Tester Sep 12, 2018, 08:53	Sorry for posting once more but I have a question; where should I look to find out the history of changes affecting this particular issue? if possible I would like to find out the latest build version in which the ini system worked correctly and stick to it until this is fixed. Of course I can try all builds backwards from 0.201 until I find one that's fine, but that's a lot of them down to 0.174 ...
No.15460 Haze Senior Tester Sep 15, 2018, 16:05	So is this a bug or is this not a bug? the original bug submitter says it was fixed, you're saying it isn't.
No.15461 bedrock Tester Sep 15, 2018, 17:36	Sorry I don't know what qualifies as a genuine bug or not, I'm just reporting the issue. I haven't yet found since which build it began to happen again (around 0.186~189 maybe, have yet to try to isolate the culprit)
No.15462 Haze Senior Tester Sep 15, 2018, 17:48	ah right, so it's a bug that was fixed and has been reintroduced? ok, guess it can be reopened then
No.15463 bedrock Tester Sep 15, 2018, 17:58	Thanks. If that helps I've had a long MAME pause between 0.183 and 0.196, which is when whith the latter that I've noticed the issue was back, so it happened somewhere in-between and is still there @0.201 (nope I never reuse my old configuration files no worries, I always set everything up from scratch with a fresh install of a new build)
No.15504 Tafoid Administrator Oct 4, 2018, 23:51	Fix has been applied: https://github.com/mamedev/mame/commit/f522870d8acf3e12ab0845272844561d9195fe4d
No.15507 bedrock Tester Oct 5, 2018, 04:50	Awesome! Thanks. ;)