Glenn Maynard
2e1705ac46
look at all the cases:
Generic ScreenSelect, eg. ScreenSelectStyle:
A non-joined player START press can join. On successful join, discard the
input; the start press that joins the player should not also make a selection
on the menu. Non-joined players can make no other inputs. (ALLOW_DISABLED_PLAYER_INPUT
is false.)
- on start press
- attempt to join the player; if successful:
- play start sound (normally done by the derived class, eg. ScreenSelectMaster::MenuStart,
but we're not going there)
- return, so this start press that just joined the player doesn't also make a selection
- any other button, return and ignore the press ("block input of disabled players")
- on any other button press, just ignore it
ScreenJoin:
Pressing start on a non-joined player joins the player, and unlike the generic case,
it also passes the start press on as input, selecting the default option and starting the
game. (ALLOW_DISABLED_PLAYER_INPUT is true.)
We don't have any visible menu selections, so other player inputs don't matter.
- This screen assumes that a player can join, and that the first successful join
will move on. Pressing start and having it not join has never been tested or
used, and in fact crashes: it'll be passed on as a selection, and
SM_BeginFadingOut dies, because m_MasterPlayerNumber is invalid.
ScreenTitleMenu:
Like SJoin, pressing start will select the current option and start the game. Unlike
SJoin, this screen has options; arrow key inputs on a non-joined player must be
passed on, so the cursor can be moved. (ALLOW_DISABLED_PLAYER_INPUT is true.)
This "always joins" assumption is bad, and was probably never intended. Fix by
never allowing start on a non-joined player (unless the start just joined the
player, in which case he'll be joined by the time of this check).