MappingWindow is modal, yet the user can use hotkeys while the window is active. I believe hotkeys should not be recognized while this window is active.
This string is extremely likely to be mistranslated without the
proper context. Actually, it's probably impossible to translate
this string in a good way to some languages, but I'm not sure how
to solve that. Let's at least add an i18 comment for now.
PR #10066 added functionality to call std::abort when a panic alert occurs; however, that PR only implemented it for MsgAlert and not MsgAlertFmtImpl, meaning that the functionality was not used with PanicAlertFmt (only PanicAlert, which is not used frequently).
Yes, that's right! It's time to add even more NKit warnings,
because users still don't understand what NKit is or how it works!
More specifically, some users seem to be under the impression that
converting an NKit file to for instance RVZ using Dolphin's convert
feature will result in a normal RVZ file, when it in fact results in
an NKit RVZ file (since NKit is not a container format in the sense
that GCZ/WIA/RVZ/WBFS/CISO is, but rather a kind of trimmed ISO).
I can hardly blame users for not knowing this, because it's not
intuitive unless you know the technical details of how NKit works.
Previously, s_temp_input was being used for BOTH the savestate's and the movie's input printout in the panic alert.
This commit simply performs memcpy from the correct vector for the movInput printout.
Previously, the file dialog window was ambiguous between saving or loading a .dtm. This commit simply gives a bit more context to differentiate the two windows.
Previously, when playing back a movie, you could not see the total frame count of a movie, only the total number of input polls.
This change simply shows the total frame count on movie playback.
Note that this change also results in the framecount and framecount total ALWAYS being displayed if show_movie_window is true, regardless of whether or not m_ShowFrameCount is true. I believe this is fine, as TASers are much more likely to reference the framecount than the input poll count.
Previously, only the number of total input polls would be shown in the window title when playing back a movie. This simply adds the VI / frame count total as well, which is a much more relevant number to look at while TASing.
If this commit is not applied, then the previous commit will cause hotkeys to be saved if there is a syntax error when hitting "OK" and the user presses the X to close the window.
This commit only applies changes to hotkey config if no syntax error occurs.
Previously you could type whatever gibberish you wanted into the formula bar, press OK, and receive a modal syntax error window. Closing the syntax error window would cause the hotkey config window to close as well, and your gibberish would be applied to the hotkey assignment.
This commit requires that a syntax error does not occur before accept() is called.
Previously, using TAS Input to activate the digital L and R buttons would not show these inputs in the Input Display. This commit adds the digital L and R presses to the Input Display, and also displays just "L" or "R" if the analog is set to 255.
There are certain hotkeys that we absolutely want to be able to use
without being in-game. Presently, no hotkeys are recognized unless we
are in-game.
I've identified and moved the following hotkeys to be checked before the
HotkeyScheduler checks to see if the Core is running:
- Open
- Exit
- Start Recording
- Refresh Game List
Note that Play Recording should also be implemented here, however it
looks like there is no signal for a PlayRecording() function, so this
will have to be handled in a later PR once that signal is created and
implemented.
Now that we have enum helpers for inserting values into packets and have
migrated all other enumerations over, there's no need to keep this alias
around any longer.
The purpose of this class was to keep track of state which the
emulation core was already keeping track of. This is rather risky -
if we update the state of one of the two without updating the other,
the two become out of sync, leading to some rather confusing problems.
This duplicated state was removed from EmulationState in the
previous commits, so now there isn't much left in the class.
Might as well move its members directly into EmulationFragment.
Léo Lam