Build new stuck check logic

[joeraz]

Since the current stuck check logic has some issues, I think we'll need some new, better logic.

Note that the stuck check logic is also used by the demo. The logic needs to avoid creating a situation where the demo's actions will lead to an infinite loop that never triggers the stuck check or wins the game.

I believe it should be based on this general algorithm:

• First, check for available hints. If there is ever a hint (unless drawing or dealing from the talon becomes possible as a hint), the game is not stuck, and the check should not trigger.
• If there are no available hints, the next step is the talon. If there are no hints and dealing from the talon is not allowed (either there is no talon, or the game rules forbid it at this point), the game is stuck.
• Games should be split into two groups - those where dealing from the talon can loop, and those where it cannot. The talon loops if it creates a situation where you can continue redealing from the talon, even if doing so won't do any good (i.e. Klondike or Cruel). This should be identified as part of the talon stack class, as it will shape the last bit of the logic. If the talon cannot loop, the first two rules should be sufficient.
• If the talon can loop, we'll need to identify that the talon is looping, and use this logic to trigger a stuck check, but only when actually dealing from the talon. Currently, one of the issues is that this check is being run at the wrong times, causing a false positive.

But logic like this would need extensive testing. Anyone want to help out?

[hajo4]

But logic like this would need extensive testing. Anyone want to help out?

How exactly ? On the current v3.0, or the next v3.1 ? Or go back a few versions to find out if this bug was introduced lately ?

[joeraz]

It would be testing with the latest dev code for 3.2 (released 3.1 last week), once the new logic is in place.

[joeraz]

So I've checked the new logic - it looks like splitting up the games is not necessary. The current stuck check logic works better than I thought it did. The problems we have with it revolve around issues with the hint classes.

It seems a lot of the stuck check issues revolve around one limitation of the hint logic. There is a failsafe in the hint logic that may cause it not to recognize a move if the same card or sequence of cards can be legally moved back to the original stack. This is not something I can simply remove, as doing so would cause the hints/demos to get caught in an endless loop in certain cases. Most of the stuck check failure scenarios I've run across involve this situation.

I currently do not know how the hint logic can be altered to handle this situation correctly. Will have to review, unless anyone has any ideas?

[joeraz]

I have a potential, albeit risky, fix for this issue. Is anyone available to assist with testing of the stuck checker?