between StyleI.player and MenuI.player is that StyleI is set even
if there's no attached MenuButton, and MenuI.player is set even
if there's no attached column. That's an odd distinction, anyway.
Move input.MenuI.player to input.pn. This also puts it in the
same place as input.mp.
This only deals with buttons being held, so won't cause
performance issues.
This deals with a general problem of the input layer:
you can query the current state of the inputs, but inputs
are received in a queue, causing inconsistencies.
This is why pressing enter during a load, then holding Alt
after pressing it, causes the game to switch fullscreen
after the load finishes; checking for "alt-enter" should
be checking if Alt was pressed when Enter was pressed,
not whether it's pressed right now.
Similarly, CodeDetector has difficulty handling a "Right-Left"
and a "Left-Right" code simultaneously. If both buttons
are pressed quickly, it needs to check whether Right was
pressed at the time Left was reported, not at the time
EnteredCode was called.
if the setting was "don't care".
This wasn't possible previously, since code expected PREFSMAN
settings to line up with the actual settings; now, use
DISPLAY->GetActualVideoModeParams.
- 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.
Glenn Maynard