Not only was the extra call to the update callback in the AchievementEventHandler method unnecessary, it was getting called on events that don't even need to be tracked here, causing a lot of lag when it turned out one achievement was repeatedly spamming Achievement Reset Events as a shortcut.
Failing to do this was causing challenge icons to carry over into the next game if a game was closed while the icons were active, even if the next game to run was a completely different game entirely with completely different badges.
RetroAchievements plans to use the user_agent in unlock requests to determine which software version was used to play the game, and can filter older software versions out. As such, I have been given the go-ahead to remove the hardcoded line that forces hardcore to always be false.
Two minor updates to improve the Achievement Manager's handling of a player's completion rate.
One, UnlockStatus and the unlock map now track achievement category, such that TallyScore does not count unofficial achievements in counts/points.
Two, the determinations for mastery/completion are now improved to check (1) that the achievement triggering this is CORE (not UNOFFICIAL) and (2) that it has not already been unlocked at this level on the site, which should be sufficient to determine that the unlocking of this particular achievement completes/masters the game.
Most obviously, there is no longer a warning message to the player in the achievement window that achievements are disabled if a game is not currently running.
This fixes an issue introduced by 3b0444be6bf38ca5c20f5b9b8916c54fd8f6fa36
where the m_accelerator would not be initialized when loading a savestate if
the current UCode mismatched the UCode in the savestate, leading to a crash.
Adds a setting field under the hood to retain which folder the player last saved/loaded a state to/from, so that the dialog box to select a state to save/load reopens at that folder.
Because the last commit made us use separate folders for GCPad and
GCKey profiles, we should also use separate game INI keys for them.
Otherwise setting e.g. PadProfile1 in a game INI will make both GCPad
and GCKey try to load it, typically with one of them succeeding and the
other one showing a panic alert due to the profile not existing in its
folder.
Better do this breaking change for GCKeys in the same PR as the other
breaking change rather than later.
By having getters for this information, other code that needs access to
the same information can call the getters instead of duplicating the
information.
