Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build new stuck check logic #409

Open
joeraz opened this issue Oct 25, 2024 · 2 comments
Open

Build new stuck check logic #409

joeraz opened this issue Oct 25, 2024 · 2 comments

Comments

@joeraz
Copy link
Collaborator

joeraz commented Oct 25, 2024

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
Copy link

hajo4 commented Oct 25, 2024

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
Copy link
Collaborator Author

joeraz commented Oct 25, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants