Disable movement when no queen on board (+ rework related syncing)

[bestrandomnameever]

Problem arises from the fact that each syncing action does not advance the opponents machine. It simply updates the context. The opponent is only blocked from doing anything in 'selecting' because it entered that state with a 'currentPlayer' switch. So the UI prevents him from making a move (playerToMove(Cell.tsx:30)). This changes when sync sends an update with an updates 'currentPlayer'. But the machine has of course never left the 'selecting' state so it doesnt reload with 'setCellsAllowedToMove' and its most current cells are the "cleaned" ones send by the opponents last move.

I would like it best if the current player would send every generated event through p2p to the opponent so that it's machine can follow the process (I think this would be the cleanest).

• To prevent a sync after each EVENT handler, use a wildCard 'on' to catch the events and send a sync
  • Unfortunately the current state's 'on' EVENT listener consumes the EVENT and transitions, never reaching the wildcard.
  • Solution could be wrap each EVENT send from the frontend so that it can be caught by parent, unpacked, synced, and raised so it still reaches children.
• Send to peer
  • The simple event so that when given to the callback, it immediatly raises it
  • Like currently, pack it in a SYNC event and allow that to unpack it an raise it (but honestly, see no value in this compared to the above one)

Other, MUCH SIMPLER solution is:

• rename to onlineGame machine
• Stay in alternating after turn (rename to opponents turn).
• Still get updates from current system of sync's
• Show board while in alternating to follow process (index.tsx:40).
• Add special seperate action in SYNC handler that raises a "ADVANCETURN" event when the send 'currentPlayer' differs from the one in context (so once again equals playerId). Do this before, once again of course, updating the the values send with the SYNC.

[bestrandomnameever]

Opted for second solution

[WardMaes]

@bestrandomnameever fixed?

[bestrandomnameever]

@WardMaes actual movement bug is fixed with second approach. Also want to further rework syncing but will move that to clearly seperate issue.