- the editor sets "system_menu" to trick StepMania.cpp into not
allowing the operator menu button, to prevent losing data;
- the editor also sets "gameplay" in "playback" mode to influence
ScreenSyncOverlay and ScreenDebugOverlay; this breaks the above,
allowing scroll lock in play mode.
A similar problem happens when we push screens: scroll lock works
in the MiniMenus in the editor.
It's semantically unintuitive to call the editor a "system_menu", anyway.
Split out AllowOperatorMenuButton, and use it directly. Check all
screens, and don't allow it if any screen on the stack disallows it.
Scripts can already use GetTopScreen to get this. However, that function
also returns data that may not be what's wanted. For example, commands
can be run on screens that aren't on top (eg. via broadcasts). So, using
GetTopScreen as a fallback for LoadingScreen may cause latent bugs;
screens should behave properly even when they're not on top, even if
they're using queued broadcasts to kick off animations, etc.
in Screen, by calling SetFOV to make ActorFrame do LoadMenuPerspective.
That broke screen backgrounds, which are rendered outside of any
screen, so they always used 640x480 (the default).
top screen. This allows a screen to push a helper screen, which can then
enter an entirely separate set of helper screens before one pops back.
(For example, a screen could push ScreenServiceOptions to enter the options
menu, which then replaces itself with the various options menus, and finally
pops back to the original screen when the player backs out entirely.) (Some
support is still missing to allow non-special-case use of this; coming soon ...)
However, in rare cases we want to kill all screens on the stack, regardless
of how many there are (operator menu). Fix that case.
Glenn Maynard