#29 Server-side movement checking improvement

[Ulf Lorenz]

Currently, on the server side, the army movement is processed in three steps. First the single movements are checked for sanity (e.g., tiles within map bounds, continuous paths), then they are sorted and processed.

If a movement item fails the check, the server currently silently drops all movements for the offending army. This should be improved by an additional check on the client side as follows:

• Split the current MovementChecker into two classes: One does the checking, one acts on failed checks.
• The checking should be outsourced to a separate class that is also available on the client side. It returns the ArmyMovementItems that fail the check.
• Improve the checking: Check for continuous paths (i.e., one tile next to the other)
• The client should have some system in place where it checks its movements for sanity before sending them to the server, ideally when they are created.
• The server should do something better on errors. At least log them (which may mean sending error updates back to the client)

[Ulf Lorenz]

Chat summary:

Splitting off the checking part of the MovementChecker as a first step.

• scenario.operations.ArmyMovementValidator has a function getInvalidItems(), which takes a list of ArmyMovementItems and returns a list of items that fail the checks.

• MovementChecker uses the validator for the filtering

• Minor ticket modification: We will need a mechanism to report errors to the client while rejecting ArmyMovementItems on the server side.

[Ulf Lorenz]

Chat summary:

• adding another check to the validator: continuous paths. Nothing special except for the fact that the movement items belonging to an army may be scattered over the list. Movement is only allowed in four directions.
• On the server side, the turn result sent to the client should also contain the failed movement items. In particular:
  • add a class InvalidMovementItem that contains an (error) string and a list of (failed) movement items
  • add a list of InvalidMovementItems to the MovementPhaseResult
  • MovementChecker should return the InvalidMovementItems
  • add an additional filter class that takes the InvalidMovementItems and removes them from the list of ArmyMovements sent to the server
  • MovementPhase orchestrates everything properly, and also uses the InvalidMovementItems when assembling the MovementPhaseResult

[Ulf Lorenz]

Chat summary:

Error handling on the client side. First the high-level discussion:

• When the user somehow manages to set an invalid path, we react immediately after the offending click, not at the end of the turn.
• The path is highlighted to show it contains invalid elements
• An error message is logged (ultimately visible to the user, for now just somewhere)

Implementation details:

• ArmyMovement gets an error flag (default: unset)
• The DestinationSelectionState gets an additional ArmyMovementValidator injected. After calculating a path on a user click, it validates the path. If validation fails, it sets the error flags for the ArmyMovements and adds them to the client game's list of army movements.
• In such an error case, the DestinationSelectionState also logs an error (for now: write to stdout)
• The PathPainter draws all ArmyMovements with error flag specially (e.g., red)
• When sending the ArmyMovements to the server, movements with error flags are not sent.