Fixes for KPat Forty & Eight patience game

[Albert Astals Cid]

El divendres, 10 de juliol de 2020, a les 7:38:40 CEST, Ian Wadham va escriure:
> Hi guys,
> 
> Good news. In brief, I have found two or three causes of the 10 bugs listed in
> https://bugs.kde.org/buglist.cgi?quicksearch=kpat%20forty%20eight.
> 
> However, I am going to need help from an expert with a knowledge of the KPat code to work out the most appropriate patches.
> 
> I will also need help to get patches committed, when they are ready, because I do not have access to or knowledge of the newer KDE Community repositories and procedures.
> 
> The bug list above relates to false positives and negatives from the 48 solver and touches on problems with the Autodrop feature. The false reports from the solver were easy enough to fix in patsolve/fortyeightsolver.cpp. However, when I tested my fixes, I found that the false positive had been fixed but the false negative was still there.
> 
> The false positive is due to the 48 solver generating an invalid move and using it to reach a win, then saying that the game is winnable when it is not. The human player cannot win because he/she is not able to make that move, except by using Demo to bypass it ;-). Actually the 48 solver generates invalid moves quite often (as shown by Hint), but they are not always used or needed in a winning solution.
> 
> Forty & Eight is a 2-pack game. False negatives can occur when there are two cards of the same suit and rank that can “go out” onto a foundation pile. The 48 solver always chooses the card on the left and ignores the other one. Sometimes playing the card on the right leads to a win, and the left hand card is a loser or not a good choice.
> 
> For example, stack 0 (on the left) may have a 2 of hearts on top and other suits beneath, whereas stack 4 may have the 2-3-4 of hearts in sequence and nothing else beneath, and then an ace of hearts comes out of the talon (or heap). The solver will consider only the 2 on the left to "go out" onto the ace, but the other 2 would almost always be the better option because three cards can go out, rather than one, and they will leave an empty stack 4 as well. Empty stacks are an advantage in later play.
> 
> When I had fixed the 48 solver to deliver both cards that can go out, Autodrop kicked in (specifically bool DealerScene::drop() in file dealer.cpp) and undid my good work. It uses DealerScene::getHints() to get a list of playable moves and selects out those that go out to foundation (or target) piles. Trouble is that if there are two cards of the same suit and rank in the list, Autodrop always plays the first (leftmost) one. It then returns, letting the animation of the move proceed, but when it is called back the second card is no longer playable (nor hinted) because the first card has taken its spot. In this kind of situation neither card should be autodropped. The human player should be left with a choice as to which card to play, unless it does not matter (e.g. if each card is the only one in its pile and either can go out first).
> 
> I have developed a patch to fix DealerScene::drop(). It takes effect only if the current game is Forty & Eight, because I am worried about adversely affecting other KPat games. I have looked at other multiple-pack games, but Mod3 and Gipsy do not seem to use Autodrop. I am not so sure about Spider, but perhaps it also is affected by Autodrop grabbing cards too soon.
> 
> Unfortunately my patch is rather kludgey. It is also a pity that it cannot get at some information known to the 48 solver and passed back to the main KPat solver, patsolve/patsolve.cpp, i.e. which possible moves are automatable. If there are two cards of the same suit and rank that can go out, the 48 solver flags neither one as automatable.
> 
> I really need help from a KPat expert to work out what is the best thing to do here.

Unfortunately I don't think we have many KPat experts around anymore, Shlomi and Fabian are the two that did changes to somewhat core parts lately.

My suggestion would be for you to put the patch as a Merge Request in invent.kde.org and that way we all can have a look at it and maybe try to understand it together.

Cheers,
  Albert



> 
> Cheers,
> Ian Wadham.
>