edward_9x
Veteran
I've been initially thinking about a new ZZ variant, but it evolved into an original and almost alg-less method for 3x3 (requires at most one alg to be learnt). It is very intuitive and has the following steps:
Possible examples of first block/square:
...and a possible final configuration:
Above is a graphical representation showing a possible insert.
Top layer edge permutation can be solved in one of two ways (intuitive or alg-based). Intuitive means phasing, but it is harder than normal phasing because you have to solve the "tripod" block while phasing all remaining edges.
Now, let me explain the "noob" method of solving EP: The optimal case, of course, is the SOLVED state. In case the two upper face edges are swapped (the PARITY case), you can choose one of the following algs generated with CubeExplorer to fix them (make sure to keep the unsolved D layer corner in the front right, and the two edges on UF and UR, respectively):
NOTE: If you've got an intuition for how the cube works, you can try to just phase the edges (break the square and restore it) like in ZZ-b (or ZZ-r). But, you may also just do an alg instead. Phasing is very hard because it's luck-based, and you sort of have to phase before/while making the U-Square, which is not easy to predict. The PARITY case can be solved with just an alg, which also affects corners (see the appendix). Future iterations/upgrades to this method will probably replace the slow parity step with phasing, but so far trying to phase edges while solving USquare in the middle of a speedsolve is this method's "missing link". I struggle for seconds trying to think of solutions when trying to phase instead of just doing an alg. It is possible, but you have to keep track of both LE, and the square pieces. I hope I can
provide a systemized approach for phasing in this method, but so far it's not really feasible ... It would be very cool to have 0 algs.
Scroll for a bit and you will see the new experimental phasing approach in one of my replies to this thread (not too far). It involves predicting the positions of 3 edges before solving U-square.
They may be situated almost anywhere on the cube, depending on how you've positioned RUSquare (2 possible positions for R-square and 4 for U-square, so 2*4=8 possible configurations, theoretically). This step could also be done algorithmically (in theory), but I think the comm approach is way more elegant than just memorizing a bunch of algs. If we were to use algs, however, we would have less cases than phased ZZLL (and, with a parity skip, we would have a one-look 'almost last layer' with not a lot of algs to learn).
If you get a parity case (and you use an alg that affects multiple corners), you can try doing some setup moves into the alg so that as many corners get swapped into their solved positions, doing the parity case, and undoing the setup moves. This gives you at most only one commutator at the end of the solve. If you get 2 corners flipped, either use a ZZLL or do the beginner corner solving method (which actually works well when everything is solved). You could also do this for other 'flip' cases.
If you can solve all corners using conjugates, then by all means do that (but it requires good memory for remembering how to undo that many setup moves).
So, the new `Skeleton` of our cube method looks now like this:
EO223
First, do EO223. (Solve EO and a 2x2x3, but the recommended way is EO+223 because planning full simultaneous EO and 2x2x3 is impossible). Even the basic EO+223 approach is more efficient than EOLine because you're not restricted to first solving a line, and you can do more advanced pairing-up tricks like making a square in the front layer and inserting with F2, pairing up pieces with M2, using the D layer to pair up, E slices, S slices etc., and it's all completely rotationless if you do "EO+223"!RUSquare
The next step is RUSquare (or LUSquare if you built the 2x2x3 on the right). RUSquare involves first attaching a square to the R layer (either front-facing or back facing), then another square to the top layer. Unlike in Tripod, the squares can really just be almost anywhere, and it doesn't matter if they form a "tripod"-like shape or not.Possible examples of first block/square:
...and a possible final configuration:
LE (basic method: parity alg)
This step involves inserting the last remaining non-U layer edge into its spot. Because of EO, you can just "tps-spam it in" while preserving the R-square and it's guaranteed to fit into the last slot. (Note: we don't care about the corner). Now, the 2 remaining edges (connected to U-square) may be in one of 2 possible states:- Parity (the 2 edges are swapped)
- Solved (the 2 edges are correctly permuted, so parity skip. This means the solve uses ZERO algorithms)...
Above is a graphical representation showing a possible insert.
Top layer edge permutation can be solved in one of two ways (intuitive or alg-based). Intuitive means phasing, but it is harder than normal phasing because you have to solve the "tripod" block while phasing all remaining edges.
Now, let me explain the "noob" method of solving EP: The optimal case, of course, is the SOLVED state. In case the two upper face edges are swapped (the PARITY case), you can choose one of the following algs generated with CubeExplorer to fix them (make sure to keep the unsolved D layer corner in the front right, and the two edges on UF and UR, respectively):
- OPTIMAL 10f* (L' U R2 U R2 U R2 U2 L R2) This algorithm is only 10 moves and doesn't restore as much progress
- 2GEN 11f* (U R2 U R' U R U2 R' U R' U') This algorithm has better ergonomics/fingertricks;
- JPERM 13f*, I suppose you already know this PLL case :]
LE (phasing: advanced method)
provide a systemized approach for phasing in this method, but so far it's not really feasible ... It would be very cool to have 0 algs.
Scroll for a bit and you will see the new experimental phasing approach in one of my replies to this thread (not too far). It involves predicting the positions of 3 edges before solving U-square.
4C
Now, you may solve the remaining corners intuitively using two commutators or only one if you're lucky and only have 3 corners unsolved (so, last edge is actually last pair).They may be situated almost anywhere on the cube, depending on how you've positioned RUSquare (2 possible positions for R-square and 4 for U-square, so 2*4=8 possible configurations, theoretically). This step could also be done algorithmically (in theory), but I think the comm approach is way more elegant than just memorizing a bunch of algs. If we were to use algs, however, we would have less cases than phased ZZLL (and, with a parity skip, we would have a one-look 'almost last layer' with not a lot of algs to learn).
Experimental idea: Conjugate+Parity
This idea is based on the fact that all 3 parity algs don't preserve corners.If you get a parity case (and you use an alg that affects multiple corners), you can try doing some setup moves into the alg so that as many corners get swapped into their solved positions, doing the parity case, and undoing the setup moves. This gives you at most only one commutator at the end of the solve. If you get 2 corners flipped, either use a ZZLL or do the beginner corner solving method (which actually works well when everything is solved). You could also do this for other 'flip' cases.
If you can solve all corners using conjugates, then by all means do that (but it requires good memory for remembering how to undo that many setup moves).
So, the new `Skeleton` of our cube method looks now like this:
................................./ (Conjugate+)Parity --- 3C, 2C or skip
EO223 --- RUSquare(+phasing) --- LE
.................................\ 4C, 3C, 2C or skipConclusion
If I could somehow get rid of the parity step, this method could be quite efficient (and also have zero memorization, being fully intuitive). My main concerns are very poor lookahead and planning (doing 2x2x3 after EO means having the entire D layer partially hidden), along with low tps (you have to think more during the solve, like Heise). What does SpeedSolving think? This is my first attempt making a speedsolving method (feels more like FMC), and it probably sucks, but it was fun trying!
Last edited:
but yeah, it's basically just "watered-down FMC" for use in speedsolving (and with an extra U layer block). In FMC you wouldn't really do the whole RSquare+USquare+parity thing because just doing normal FMC stuff is better than that.
