Excellent suggestions and thank you for your input!
Try to focus on keeping the computer to a human-like solving method. That is, use one or two algs per OLL/PLL/F2L case (and maybe allow the user to enter their own alg if they want), and try not to be *too* optimal.
Exactly my thoughts. I thought of having another file for settings for algorithms. Currently the program stores settings in 'Settings.xml', so I might have another settings file called 'Algorithms.xml' that will contain all the algorithms to use for solving. Now the useful thing about this is that you'll be able to have multiple files which you can just replace with the 'Algorithms.xml' when you want to use a different set of algorithms. You could have a 'SimpleAlgs.xml' that you designed with just one algorithms for every situation. Then you could have an 'AdvancedAlgs.xml' with maybe 5 solutions for every single case possible which would find an extremely optimal solution. This is one of the top things on my todo list for this application as it is very practical and should be easy to implement. I may get rid of the options in the solver tab for 'Beginner F2L', 'Beginner OLL', and 'Beginner PLL' so that the user can simply control which algorithms to use instead (eg. 'FridrichAlgs.xml' and 'BeginnerAlgs.xml'). Now don't worry, these .xml files will not require the user to manually input algorithms into the file. There will be a graphical interface for setting up all the algorithms. Perhaps I'll have the program open up a dialog which will show you the list of situations, then you can click on a situation and it will display the situation on the main cube, then you can perform an algorithm to solve the situation, which will be recorded by the application and stored in the algorithms file. As you can see, I love this whole concept of user-defined algorithms..
For instance the idea of solving the cross to try to preserve edge pairs is a good idea for FMC, but not so good for speedcubing since most people won't have time to do that in inspection until they get way more advanced.
I think it'll be a simple matter to be able to turn this setting on and off. So I'd say if the cross does solve one F2L pair, subtract say.. 5 moves from the overall solution, given that the average F2L pair can be solved in around 5 moves. If someone has a more accurate F2L pair solution pair average then please let me know. I will make a setting for that number which can be user-defined (but it will have a default of 5 moves).
Similarly, if your computer is trying to find really nice solutions for the entire F2L at once, try not to do anything that a human wouldn't be able to think of in a solve (like solving three pairs at once with blockbuilding).
Something like blockbuilding is very difficult to implement programmatically as it is all based on reasoning. So I don't think people will have trouble with the computer solving 3 pairs at once.. Maybe one in every 10,000 solves will this happen
Or you could try not to cancel between steps. I'm assuming here that someone who's just learning to use Fridrich won't be doing movecanceling or multislotting on the fly.
This will be a simple matter to implement as well. I can make a simple setting for not reducing redundant moves in between steps. Good suggestion.
I like the "greyed out" idea, but it might be better to use an only partial grey - what I mean is, instead of just making the pieces completely grey, maybe just make them much darker or greyer but still colored. It's definitely true that people should concentrate on the step they're doing, but it should still be possible to see the other colors to remind them that on a real cube they will be able to (or to allow them to do basic lookahead). I guess a sliding bar thing would be most appropriate here.
I fear that you have not looked through the settings enough. In the settings there is a tab for the solver, then there is a grouping with a caption called 'Phase focus'. This lets you set what color to gray the cubies with, what opacity to use for the actual color of the tile when grayed, and what opacity to use for the graying. Very customizable. Very simple to use.
For a full-cube solution, if this is reasonable, each step (cross, each F2L pair, OLL, PLL) should be on a new line - keeping the whole thing in one textbox looks kind of cluttered and is hard to read.
Excellent idea. I think I got carried away with my neat idea of a scrolling text box like I implemented. I can get rid of the scrolling and just have a nice text box with highlighting, new lines for each phase of the solution, and text wrapping can be turned on and off. Good suggestion. And if the coloring of the solution text is annoying, it is all customizable in the settings under the solver tab in the grouping labeled 'Phase text highlighting'.
I don't know how your program behaves at the end of the solve, but how about showing the solution and showing you what you did in each part? The program could offer suggestions on how to do the cross and F2Ls more efficiently, so that you could easily see if something needed work (and what to do instead).
I'm not quite sure what you mean by this. The program executes OLL then PLL at the end. It usually gets a skip on one or the other though.
when you go through the solution using arrows, could the moves be animated? Its hard to see what goes on when it snaps into places, especially with the rotations
By the default settings, the moves are actually being performed at 90 degrees per timer cycle. So if you'd like to see the moves performed more slowly I would suggest simply changing the settings for the fast forward speed. In the settings under the solver tab and in the grouping labeled 'General', there is a setting for 'Turn speed (fast forward)'. Simply turn the speed down a few notches and you'll be able to see the rotations more clearly. There is a similar setting under the scrambler tab.
could there be a way to force the cross color?
Absolutely. I hadn't thought of this but it would be excellent if a user preferred a certain color for the cross. Easy to implement. I'll work on this too.
it doesnt look like its doing OLL/PLL, but it doesnt matter too much.
The program actually encounters a lot of OLL skips and PLL skips. I will get around to making a nice dialog for choosing a solve to execute instead of the best solution. There will be a nice summary of each solve so that you can choose whether to use a solve with OLL and PLL skips involved.
I would really like to use this to find better ways of doing the F2L. It would be great if it spewed out F2L solutions, and you could go through all of them and see how they play out or something. but that seems like a lot of work (especially interface ***** work, the one noone ever wants to do)
Like I said, there will be a nice dialog for picking out many different solutions for the same solve. This isn't too much work as the solver already calculates all the solutions. It may take me a while to find a user-friendly interface that displays each solution for the user to pick from.
qqwref brings up good points.
also for example moves like B should be disallowed? You can't feasibly, in an actual solve, perform those moves efficiently... stuff like that
This should be avoidable when I implement user-definable algorithms. The user can decide whether to allow the solver to use B moves.
Overall, excellent suggestions. I have some renewed vigor for this application now from these good ideas and I'll start working on some of these ideas. Please continue to find bugs and give suggestions.
