Extracted games contain a boot.bin file that contains the disc header.
These boot.bin files are considered valid volumes by Dolphin, since
Dolphin only checks the disc header to determine if something is a valid
GC/Wii disc. Running them doesn't make any sense, though.
boot.bin files used to not be scanned by Dolphin due to their file
extension, but .bin was added to the list of file extensions to scan for
in 494e2c0. To stop them from showing up in the game list, let's update
the ShouldHideFromGameList mechanism.
Different threads are adding and calling callbacks, so this should have
some locking. This is both to ensure thread safety when accessing
`s_callbacks` and to ensure that there won't be situations where a
callback gets called after it's removed.
`s_callback_guards` is also accessed from multiple threads and has
therefore been made atomic.
a1691a4 made it so analytics start events can only be generated when
starting the main activity. However, some users launch Dolphin's
emulation activity from a separate frontend application, bypassing
Dolphin's main activity. This change adjusts the logic so that start
events can be generated if any activity is started after 6 hours of
inactivity. This more closely matches the behavior we had before
a1691a4, while still ensuring duplicate start events aren't generated.
I've also fixed the inconsistent indentation in ActivityTracker.kt.
Require callers of Config::AddConfigChangedCallback and
CPUThreadConfigCallback::AddConfigChangedCallback to handle the returned
ConfigChangedCallbackIDs to hopefully prevent future issues with
callbacks getting called after their associated objects have been
destroyed.
Use a single lambda as a callback which calls InitCustomPaths and
RefreshConfig instead of having separate callbacks for each of them.
This fixes the callback for InitCustomPaths not being removed on
shutdown; the callback for the lambda (previously for RefreshConfig) is
already removed in Shutdown().
Prevent SetHardcoreMode from being called after m_client is set to
nullptr. rc_client_set_hardcore_enabled() checks for nullptr so this
didn't cause any problems, but better not to rely on that.
Also prevents multiple SetHardcoreMode callbacks from piling up when
repeatedly toggling Config::RA_ENABLED.
Remove ConfigChangedCallback in MainWindow's destructor to prevent the
callback from accessing the destroyed MainWindow afterward.
After MainWindow is destroyed UICommon::Shutdown calls
LogManager::Shutdown which ultimately triggers any remaining callbacks.
This resulted in calling MainWindow::OnHardcoreChanged, which crashed in
debug builds and didn't have any obvious effect in release builds.
Fixing an oversight: this was causing the debugger to be disabled if achievements were disabled but hardcore mode was still enabled in the .ini. This fix properly checks for hardcore state via AchievementManager which takes both settings into account.
I've been playing Rock Band 3 recently and have experienced a bug where
sometimes if you disconnect and reconnect a USB microphone, the game
won't pick up on it connecting, not even it you disconnect and reconnect
it again. An investigation into what's going on inside Dolphin shows
that when the game triggers a call to OH0::DeviceOpen after the device
has been reinserted, Dolphin doesn't open the device because it's
already present in m_opened_devices.
Removing the device from m_opened_devices after calling OH0::TriggerHook
in OH0::OnDeviceChange resolves this specific issue in my testing. Doing
this matches us removing the device from m_opened_devices after calling
OH0::TriggerHook in OH0::DeviceClose, but I haven't looked at exactly
what real IOS does.
I have been able to reproduce a much rarer issue that has the same
symptoms on the surface but where OH0::DeviceOpen gets past its
m_opened_devices check. I'm currently not sure what the cause of this
remaining issue is.
If the build folder is created from an older commit and this flag is not set, the last value set for this flag will be used instead.
This is currently happening on our macOS build machine, causing macOS 10.15 to still be used as the deployment target.
