Hi You are correct in your analysis of the bug. I checked in a fix for it which is slightly different than the simple commenting out you proposed. The main issue is we keep a set of statistics for the move as well as the game as a whole and we want the move to include the deadwood (but without double counting it in the game).
However in playing with Zev's gcg I do see another issue. Simulation always uses the static move generator which is not a good thing when simulating the endgame. The Championship player give a much better result than simulation as it does use the endgame player here. I will work on a fix for this too when I get some time. Matt --- In [email protected], "cesar" <delso...@...> wrote: > > in sim.cpp, in the simulator function, for every candidate and ply, > commitCandidate() is called which just commits the play in the sim. if > the game ends as a result of this play, sim.cpp also accounts for > taking twice the score of your opponent's rack and adding it to your > own, by calling Position::deadwood(). > > commitCandidate() in game.cpp calls addPosition() which calls > Position::incrementTurn(), which calls adjustScorestoFinishGame() if > the game ends, which, finally, calls the same deadwood() function that > sim.cpp also calls. this is effectively doubling the points you'd > normally get from an opponent's leftover tiles. so if we comment out > the call to deadwood in sim.cpp then this should fix the win% bug. > > this block looks like: > > if (m_simulatedGame.currentPosition().doesMoveEndGame(move)) > { > LetterString deadwood; > move.score += m_simulatedGame.currentPosition().deadwood(&deadwood); > } > > we just need to comment it out. > > i can't get cvs to produce a patch file, but this seems easy enough to > fix. to the developers -- i hope this doesn't break anything, if > anything looks weird please let me know. i think this would fix the > bug. i can try running test cases where a win percentage is clearly > 100% but quackle shows it as 0 (and vice versa), if anyone has any. >
