by lower level things (eg. InputMapper). However, concepts like
"joined players" and "human players" is a high-level, GAMESTATE
concept, and engine stuff shouldn't depend on that. Move the
GameState-depending stuff into GameState. Move
IsAnyPlayerUsingMemoryCard as well (and rename to HumanPlayer),
to fix MemoryCardManager dep.
LoadingScreen is a variable that should be available to all loading
definitions. Param does this currently, but I'm redesigning that, and this
particular case doesn't fit. Conceptually, it really is a global (though
perhaps should be tucked away with an environment or something).
to Lua when the singleton is constructed, and not in the
binding class. The binding just adds the class bindings
(the same as for a non-singleton class). This way, the
binding is available to Lua as soon as the class is constructed.
- 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.
Glenn Maynard