Viewing Issue Advanced Details
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
 
Relationships
There are no relationship linked to this issue.
Notes
16
User avatar
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.
User avatar
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.
User avatar
No.12505
M.A.S.H.
Senior Tester
Apr 1, 2016, 15:45
Fixed by dankan1890:
http://git.redump.net/mame/commit/?id=1fb4b520e13e1e87f60c6e00d0413eebbcb8b6c6
User avatar
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.
User avatar
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
User avatar
No.15293
Zaghadka
Tester
Jul 25, 2018, 21:36
Probably should mark this one resolved as of 0.174. It's definitely fixed.
User avatar
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.
User avatar
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.
User avatar
No.15388
bedrock
Tester
Sep 4, 2018, 17:41
Please reopen ? <3
User avatar
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 ...
User avatar
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.
User avatar
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)
User avatar
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
User avatar
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)
User avatar
No.15504
Tafoid
Administrator
Oct 4, 2018, 23:51
Fix has been applied: https://github.com/mamedev/mame/commit/f522870d8acf3e12ab0845272844561d9195fe4d
User avatar
No.15507
bedrock
Tester
Oct 5, 2018, 04:50
Awesome! Thanks. ;)