• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 35,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

Cube Explorer glitches & warnings


Feb 14, 2016
For those of you who use Cube Explorer to find algorithms, I have noticed some serious errors in the program that prevent it from finding the optimal algorithms for certain cases. In some cases it doesn't even come close to finding the optimal algorithm. I have attached an image using version 5.13, showing two Waterman/LMCF cases where it fails to find the optimal algorithm, in one of the cases it isn't even close. I have noticed this effect over the last 2 years and I thought the events were just occasional bugs, but after generating hundreds of algorithms I have now found that as much as 1 in 5 cases I can find algorithms by hand that are faster and never found by the program. Please note that sometimes algorithms are obscured by preceding U/U' or M/M' or R/R' L/L' and you need to look further down the list to see these 'hidden' variants with setup moves, but I assure you I have already taken that into account and if you play with the two examples in the image, you'll see what I mean.

If for some reason you can't view the image, try this scramble:

M' D' M' U M D M' U' M2

This is a scramble for Waterman Set 2 where you solve UR+DR while orienting the midges.

The shortest algorithm and fastest was found by hand:
M2 U M D' M' U' M D [8]

If you insist on correcting the centers like cube explorer does, then the solution adds M:
M2 U M D' M' U' M D M [9]

However if you plug this case into cube explorer the shortest algorithms it finds are 10 moves, and at no point will it find the above algorithm. This is one of dozens of such cases. I have been working on the latest revision to the LMCF method and now as many as 20% of the algorithms have been found by hand, since they can't be found by cube explorer. As I understand it this is the utility that most people use to generate algorithms, and it makes me wonder if ZBLL, OLLCP, VLS or any of the big sets are actually optimal, there could be hundreds of amazing algorithms never found. If you know of any utility that can actually find the correct algorithm in the two cases provided, please let me know.

See attached image.



May 27, 2018
United States
TL;DR uncheck BDL boxes

This glitch only happens when using slice moves mode
So big alg sets like ZBLL are not hindered in any way
To fix glitch, allow all faces, meaning leave your B, D, and L boxes unchecked, even if you don’t want them. In your screenshot you had them checked, I’m not sure why Cube Explorer acts this way but it just does
If you’re still having issues, it might be caused by the centers so try every center combination (4) and see which yields the best alg
If nothing works, you might have to try other things like downloading it again or something
Hopefully I helped
(this post was edited)
Last edited:


Dec 24, 2015
You have B, D and L moves restricted. I haven't checked the source code (which was actually publicly released somewhat recently!), but my guess is that the internal representation of move sequences consists of just the six single-layer moves, and the "slice" moves are just stored as L2 R2 or whatever, and only converted to M2 x2 for display. The restriction of B, D and L moves applies to the internal representation, not to whatever the alg looks like after the slice moves are written as slice moves. The checkboxes are greyed out when in slice moves mode, so you'll have to go back to the usual mode first, uncheck those boxes, then go back into slice mode.

Also, use ksolve++ or HARCS or something along those lines if you want to generate MUD algs and the like. Cube Explorer is entirely the wrong tool for this task.

Thom S.

Sep 26, 2017
In addition on what WoowyBaby and xyzzy have said, I have two things
First, your best Algorithm always moves the centers. CE doesn't like that as it assumes you want your centers to be like this.
Second, CE won't care if the found algorithms are good, it just gives it to you


Dec 24, 2015
CE is close to optimal but not actually optimal right? idk
It searches only for optimal algs when there are any "wildcards" (greyed pieces, pieces with only orientation specified, pieces with only the colours specified).

If you specify the whole cube state (which is not the case here), it'll search with the non-optimal two-phase algorithm by default, and you can check the "optimal" checkbox to make it find optimal solutions.
Nov 29, 2008
I am not out of the world and if there are some bugs in CE I will try to fix them. I will not add any additional features to the program any more - just fix bugs or eventually improve the user interface if you can convince me that something is seriously confusing or impractical.

Before I upload a fixed version I would like to know if there are other annoying things which could probably be fixed easily.

Edit: In the fixed version you now can also use the exclude feature when using slice moves. If you exclude B moves for example and you solve a cube with the B face turned you get:

F' E2 S2 E2 S z (5s*)
F' M2 S2 M2 S z (5s*)
S M2 S2 M2 F' z (5s*)
S E2 S2 E2 F' z (5s*)

So you can replace a B move by 5 slice moves.

If you exclude B and F you get for example

L' E' M' E R U' S E S' x' z (9s*)

The above is wrong. It's always dangerous to change code which you did not see for years.
S' F' z (2s*)

should be the right answer. I will have to revisit the code.
Last edited: