Version: (using KDE Devel) Installed from: Compiled sources When you select Game->Save in the menu and then after playing a few moves more select Game->Load... then the game is reloaded from the config file. However, the program has lost track on who is black and who is white. This is easy to see if you look at the Savegame section in ~HOME/.kde/share/config/kreversirc. This is especially nasty if you don't play the default color, but has used Move->Switch Sides. Besides, the name Load... in the menu suggests that a dialog will open, but it doesn't. The ellipsis should be removed.
Created attachment 7607 [details] diff to save color human/computer file prefs_addons.h public: static void setHumanColor(int b) { if (!self()->isImmutable( QString::fromLatin1( "HumanColor" ) )) self()->mHumanColor = b; } static void setComputerColor(int b) { if (!self()->isImmutable( QString::fromLatin1( "ComputerColor" ) )) self()->mComputerColor= b; }
commit http://lists.kde.org/?l=kde-cvs&m=109577903904244&w=2 fixes the color problems and saves color. Please Inge do test and add any comment, thanks
Hi, Anne-Marie. The fix works, but I see some problems with it: 1. Only one of humanColor and computerColor should be saved since there is only one parameter inside the program (see board.h: m_humanColor). There is no computerColor anywhere inside the program. 2. It doesn't save the setting(s) in the [Savegame] section of the config file. Actually, the color for the human in the game is not a setting at all (I think), since it is a property of the game, and thus I question the way to handle it. 3. You added a comment at line 683 of board.cpp that it's always the turn of the human player at the point of saving. Is this really true? The original code had taken into account that a computer move had been interrupted before the save, and that would make it the computers turn to move. Actually I fixed the bug myself and only noticed the commit of your fix when I tried to commit my own. :-) I know that I should have assigned the bug to myself, but the reason that I didn't fix it immediately was that I was too tired at the time. Oh, well... How do we continue from here? Will you fix your fix, or do you revert it and I check in mine? You decide and if you want to fix it yourself, then I will test it and see if it works. Btw, I also looked at the "Load..." problem, but that was generated by the KAction for loading so there is no way to fix this. It assumes that there will always be a file chooser launched when "Load" is chosen. Well, since I intend to implement storing and loading to any file anyway, that won't be a problem for long.
Cool that you have a fix yourself! If you intend to work further on KReversi it's better if you take it from there. Do I need to revert as you will maybe need the prefs_addons.h file? If you think I must revert it all, I'll do it. If you need the file, maybe just amend the other files. It depends if you want to save the human color or not at all. As for this computer move in a load game I could not myself save a game while the computer is playing (busy cursor) so a save always happened in my tests after the computer played. Besides in the code it was assumed that it's always the black turn to play first which is also unfair in case of a load game as it can lead to the computer playing twice. But these comments can be wrong, I am not a great gamer! I noticed the computer color is not needed ;-) and I intended to fix it as well as the save/load but I'm happy if you do it! Could you close this report with your commit please? Nice working with you and nice to see KReversi being improved! Anne-Marie
Ok, I will take it from here then. You don't need to do anything. But it was awfully nice of you to be so quick with a fix. Regarding the prefs_addons.h file, I won't need it, but I can remove it myself. As a matter of fact, I have already done some work on KReversi. Take a look in the ChangeLog and also see the last two months of traffic in the kde-games mailing list. -Inge
Ok, I have now committed my own fix. See the ChangeLog for details. Closing, as per your suggestion.