|システムコア||低||解決済み||修正済み||2016-03-31 04:31||2018-10-05 13:50|
|詳 細||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.|
|再現手順||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.
Note: Fixed once in 0.174 - regressed again some time later and reopened.