The core options menu doesn't populate until the core is fully loaded/initialized, though it's accessible as soon as the core is semi-loaded via the quick menu. This leads to users frequently loading a core and then going straight to core options to change things and then thinking the core has no options (or is broken) because it only says "No options available". It would be much more helpful if, when the core isn't fully initialized (i.e., until content is loaded or the core is running in the case of content-less cores), it included a message explaining this, rather than the cryptic and often-inaccurate "no options available" message.
Core options menu tells users that it doesn't populate until the core is up and running.
Core options menu misleadingly tells users that there are no options for the currently-loaded core.
has always happened on all OSes and platforms.
Is there any reason to make the quick menu accessible before content is loaded? A lot if not all of the options aren't very useful until there is content loaded.
It would be more useful to populate the options menu when loading a core. Requiring the user to load a game in order to turn the hardware rendered off, then requiring them to immediately close the game for the option to take effect, is a bad experience.
Why would a user load a core at all instead of just loading the content directly? The most likely reasons seem to me to be
is there any other reason? You probably want to optimize those use cases. Maybe by having better error detection for the first case (and displaying a pop-up like "This game requires scph5502.bin in the system directory") and detecting the second case and asking the user if they want to restart the core, you can eliminate the need for loading cores directly entirely.
The problem of not being able to see core options would remain regardless, I think this is inherent in the current design and changing it might not be easy? Regardless I agree that it should be fixed if possible.
Also checking information is already possible without the quick menu.
My suggestion is to remove the quick menu unless content is loaded and if it ever becomes possible to change core options before content is loaded then add them to a second location outside of the quick menu when a core is loaded without content. This could be maybe somewhere under Settings or even Information?
@BPaden Some cores won't know the available options until they know what game is loaded (such as in the case of cores that emulate multiple systems), so it's not always possible to populate it beforehand.
is there any other reason
content-less cores?
If the options you saved are causing a crash or some other form of breakage (like setting a resolution not supported by your screen) and you have no way to change it without loading some content then it would be problematic.
I guess it should be up to the core what options to offer. If it's a multi-system core and there's no common options that make sense to offer then the "no options available" message wouldn't be that inaccurate.
Perhaps it'd be best to just clarify it a bit by changing the message to something like "no options available for current content". This implies that if no content is loaded and you get this message, you might have to load it.
Then, in the future maybe offer a way for cores to expose content-independent options.
This is no longer an issue because the quick menu is not accessible until content is loaded. Closing.
Most helpful comment
It would be more useful to populate the options menu when loading a core. Requiring the user to load a game in order to turn the hardware rendered off, then requiring them to immediately close the game for the option to take effect, is a bad experience.
Why would a user load a core at all instead of just loading the content directly? The most likely reasons seem to me to be
is there any other reason? You probably want to optimize those use cases. Maybe by having better error detection for the first case (and displaying a pop-up like "This game requires scph5502.bin in the system directory") and detecting the second case and asking the user if they want to restart the core, you can eliminate the need for loading cores directly entirely.