state changes within the OverlayMenu don't register to CommunicationMod as a game state change

[steven-peralta]

The OverlayMenu isn't officially a screen within the game, but instead a container for various elements that are shown/hidden depending on the game state. Most of the time interacting with these elements will register to CommunicationMod as a state change by virtue of changing the current screen or flipping the isScreenUp boolean in AbstractDungeon, but there are cases where this doesn't happen, particularly when having a GRID screen up. For example, when a user is selecting a card to purge in the shop, if they select a card and issue a cancel command this doesn't change the isScreenUp or screen fields in AbstractDungeon so hasDungeonStateChanged in GameStateListener will not return true. And whenever we issue a command, we flip waitingForCommand in GameStateListener to be false but it will never become true again until the user issues another command (since flipping that variable depends on the output of hasDungeonStateChanged. This is problematic for some automated clients who wait for waitingForCommand to become true again to issue another command.

[ForgottenArbiter]

I patched the instance where issuing a cancel command from a grid select screen confirmation prompt would not register a state change. Are there any other problematic versions of this behavior that you know of? Sorry, it's been quite a while since you filed this issue. I know hand select screens have no way to un-select the cards at the moment, but that is a bit of a different issue.