fix: require hat select before ready up

[nelson137]

Fixes #963

Changes

• 6781542 PlayerSlot is now (sort of) a state machine, starting out Empty then progressing through SelectingPlayer and SelectingHat until becoming Ready
  • Slot for a network player only uses the SelectingHat and Ready states for simplicity
  • Angled brackets < and > show around the thing being selected (player/hat), brackets now don't show when ready
• a2393c4 fix bug where label has incorrect text for 1 frame when pressing Menu Back to remove player from slot
• f636d33 Upgrade bones to latest
• Set gitattributes for *.ftl files so that they are treated as text for diffs and not binary files
• Ignore advisory RUSTSEC-2024-0370 proc-macro-error is unmaintained (see related bones issue and the advisory)

This also fixes a bug I was seeing on main where another player in a LAN lobby pressing A/D would behave as if everyone pressed A/D, e.g. pressing D to select the next skin would change to the next skin in both slots.

Rationale for the rough state machine:

Previously there were 3 states for a player slot: Empty, SelectingPlayer, and Ready + SelectingHat. This state was maintained by two booleans, active and confirmed, which tell you whether the slot is not empty and whether the player has readied-up respectively. Together they represent the 3 states as: (active/confirmed) false/false, true/false and true/true; with false/true being an invalid state.

Now that there are four states to the ready-up process, one way of implementing this is to add a third boolean, but this introduces 3 more invalid states. Let's say the boolean is called selectedPlayer, these are the possible boolean combinations and the states they represent (active/selectedPlayer/confirmed):

false/false/false Empty
false/false/true <invalid>
false/true/false <invalid>
false/true/true <invalid>
true/false/false SelectingPlayer
true/false/true <invalid>
true/true/false SelectingHat
true/true/true Ready

The implementation I opted for is a simple state machine. While it added a lot more code to some areas of this module I found it made reasoning about some sections much easier. It also made explicit certain edge cases in the handle_match_setup_messages system where e.g the client could theoretically receive a confirmation message from a peer when it had not yet received any player selection messages. A warning log is now generated in the unlikely case this occurs.

[MaxCWhitehead]

Looks good to me, thanks! I agree that using enum seems more clear than stacking more bools 👍

[MaxCWhitehead]

This also fixes a bug I was seeing on main where another player in a LAN lobby pressing A/D would behave as if everyone pressed A/D, e.g. pressing D to select the next skin would change to the next skin in both slots.

Nice catch on that!