I was working on the creation of a method a while back, that reduced the LL solve to 3 steps or less, using only 25 algorithms for memorization. Though certain recognition steps might require more time to get used to, they should bring major benefits to cubers trying to get below 30sec.
After developing the method, and memorizing only the few parts of it that I found easiest and most important to apply, I had shaved my time down from 50-55 sec to 35-40sec. That's a good 15 seconds difference with only half of the method in use. (I used to use a 4 step LL that could in uncommon cases become 5, 6, or a frustrating 7 steps depending on the scramble. Not very effective, hence the desire for a new method with few algs to memorize)
The theory behind the method is that the edge orientation and permutation could be done in one step with very few algs required for memorization (15 in total). The corners are done in two steps, orientation (6 algs) and permutation (4 algs).
Putting together this method, I was looking at all the possible combinations of LL positions with respect to the edges, then corners, and finding one effective algorithm for each of them. The algorithms I chose for each situation were chosen because of the possible speed achievable with them, and not because of the number of moves (meaning that if an 11 move algorithm's time was able to be reduced effectively enough with the simplest/quickest finger-tricks as opposed to an 8 move algorithm that could not, then the 11 move algorithm was chosen). Any redundant position solves (mirrors, rotations, reversed order of effects, and even cube orientations) have been discarded, requiring that recognition be more specific no matter the LL rotation; also because of this, a quick rotation of the last layer may be required (or removed from the first step) before beginning an edge algorithm, and a cube reorientation might be required before a corner orientation. You can also perform a simple cube reorientation before any algorithm if you feel your finger-tricks will be more optimal with certain sides. I encourage the exploration of possible new finger-tricks (for example U R' L can be done with one swift movement holding the U side by it's edges).
I will put the algorithms here, but I do not yet have a clean way of presenting exactly what they do, which I am working on getting images for and will add in an edit soon. In the meantime, you can experiment to see what each one does.
A bracketed {U} move at the beginning of some algorithms is left for a more organized understanding of what the algorithm does. These can (and should) be excluded when the orientation of the U layer is appropriate.
(F = flip, S = switch(trade), SF = switch-flip) Opposite two-edge combos. (8 algs)
(front and right edges - back and left edges)
F-Ø
R' F R U2 F' U' F' U F2 U2 F'
S-Ø
{U} <apply the first half of the 5th case corner orientation algorithm: R U R' U R U2 R' as seen below>
SF-Ø
F2 R U R2 F R F’ U L F L’ U2 F2
SF-S
F R U R' U' F2 L' U' L U F
SF-SF (you can choose, I found both to be equally effective)
1 - R' F R F' U2 R' F R F2 U2 F
2 - F R' F' R U2 F R' F' R2 U2 R'
F-F
R U B' U' R' U R B2 U B' U' R' U
S-F
F U2 F' U2 F' L F L' U
SF-F
{U} L' B L B' U2 B' U R' U R B
S-S (Equal to opposite edges being switched, just rotate once)
R U R' U' R' F R2 U' R' U' R U R' F' U2
Opposite edge combos (2 algs)
(front and back edges)
F
F U F' U F U' R U' R' F'
SF
R U' R' F' U F R U R2 F R F'
S (see S-S in Opposite two-edge combos)
Merges (5 algs)
(front and right edges - right and back edges)
SF-S
{U'} R U B U' B' R' U
F-S
{U} F' U' L' U L F
S-SF
R' U' R U R B' R' B
F-SF
F' L' U' L U F U'
S-F
{U} B U B' U' B' R B R'
Based on the orientation of the LL color faces. x means it's correctly oriented. (6 algs)
Code:
_
|
| _
F U R' U' R2 U' R2 U2 R U2 R U R' F'
Code:
_ _
_ _
R B' R B R2 F R' F' R F' U2 F U2
Code:
_
x
_ |
R' U L U' R U L' U'
Code:
_
x
| _
L U' R' U L' U' R U (Simply a mirror of the above. Also, can be solved by using the above algorithm twice after U')
Code:
_
x
_ x
R U R' U R U2 R' (then mirror it) L' U' L U' L' U2 L
Code:
x |
x |
(The same as above, simply perform a Z' reorientation first. Or if you're talented with the down layer: D R D' R D R2 D' making 26 algs in total)
Code:
_
x
| x
L' U' L' U R U' L U R' L (These last two moves can be replaced with a slice move, or the last three with an odd finger-trick)
(4 algs)
Three-corner trade clock-wise (the three corners are the two back corners and the front right corner)
(X) R' U R' D2 R U' R' D2 R2 (X’) (or if you don't want to reorient and can do the Front and Back layers well enough: R' F R' B2 R F' R' B2 R2)
Three-corner trade counter-clockwise
(X) R2 D2 R U R' D2 R U' R (X') (literally just backwards of the first one. Without reorientation: R2 B2 R F R' B2 R F' R)
Left to right (and vice-versa)
R2' U R' d' R U R' U' R U R' U' R U R' F U' F2
Cross (front right trading to back left, and front left trading to back right. Equal to trading all edge pieces to opposite sides.)
L2 R2' U L2 R2' U2 L2 R2' U L2 R2' (I recommend that this be modified with slice moves to: M2 U M2 U2 M2 U M2)
This method isn't designed to be a professional/competition solving speed method, but is simply meant to be a method for beginner-intermediate cubers to be able to get almost 30 second times (if not faster) using only a small handful of algorithms. It also isn't designed to be a static orientation method, though it can be adapted to that if your fingers are talented enough, and that does shave many precious seconds off. This method is meant to be adapted to the needs and the skill of the cuber using it, so any use of reorientation, finger-tricks, and solve recognition methods are up to the cuber.
As opposed to other methods I looked at the cases and algorithms required in other combinations. Specifically the following cases: -Common method: CLL(avg moves 10)+ELL(avg moves 11) = 42+29 = 71 algorithms (avg moves 21). Out of the question for my goal of few algorithms. -Common 3step/3-Look method: 2-Look OLL(avg moves 9+10)+PLL(avg moves 12) = 9+10+21 = 31 algorithms (avg moves 31). Good, but still too many algorithms (21) requiring very difficult recognition techniques. The recognition skill required for the final step to be effective serves as an impediment to speed and simplicity of learning and executing the method. -This method: LLEF(avg moves 8)+OCLL-EPP(avg moves 10)+CPLL(avg moves 9) = 15+6+4 = 25 algorithms (avg moves 27) with only a 6 move difference from CLL+ELL, and there are only 5 algorithms requiring a somewhat tricky recognition stage (the edge "merges").
So at the sacrifice of 6 extra moves (let's say it takes about two seconds to do that, to be modest) and one extra (and simple) recognition pause (lets also say about two seconds), we're talking about a 4 second difference between CLL+ELL and this method. So in terms of simplicity and benefit, this is, theoretically, a very effective method to achieve fast times. So... yeah. Any input is appreciated.
If you want to come up with possible names for it, go ahead, I'm considering them ;P. I personally am thinking about naming it the Bauer-LL (because it used to be only 24 algs until I realized that one was missing.)
If you want a place to test things out, check out Sandbox.
I think Bauer-LL is a fine name, but I don't know what Bauer has to do with 24. Good luck!
* - I tried removing the hyperlink from this, but whenever I saved the change it put it back. If you add more to the end of this without removing the link first, it will keep the current link.
@elrog
I suspected there was something already for the first and last steps, and the middle step can also be found here: OCLL-EPP
But the efficacy of this method is in the speed achieved with the number of algorithms required for memorization, especially since one or more algorithms can apply in one or more cases with small modifications. I split the corner algorithms into two parts because doing it in just one step requires substantially more algorithms for memorization. And for me at least, the algorithms chosen are optimal for the finger-tricks I find to be the fastest.
This seems like a reversed 3-look version of CLL-ELL (LLEF-2-look COLL); with 24 algorithms, this could have a lot of potential for people who want to ease their way into CLL-ELL.
The Edge step (LLEF) could probably be improved (check out ELL algs, basically the corner preserving version of what you've made), though it's . If you allow for slice turns, the entire step can be made 2-gen. Not saying that you should replace all of the algorithms (or even that you should replace any of them), but you should definitely take a look.
Your CO algs are all non-permuting OCLLs, but when I tried them, your U, T and H case algs (6th, 5th, and 2nd, to any for whom that didn't make sense) didn't work. Someone let me know if I didn't execute them correctly, but I tried them multiple times each.
Your CP algs are pretty good (that E-perm is nice, and the slice move H-perm is the common alg, as far I know).
The proposed name is great.
Overall, seems like as soon as those CO algs are fixed, this could be a pretty good system! If I just messed up my execution, then my apologies, and it is already a good system.
So this method is very similar to CFOP- except for one big difference- the cross is done (or at least most of it) AFTER the F2L pairs are put into place. In short, this method fixes or lessens one of CFOP's biggest problems- the Cross-F2L transition.
In this method, there are 5 (technically 6, but one is regular CFOP) positions you can create a partial cross in. They are as follows:
No cross edges
One cross edge
Two adjacent cross edges
Two opposite cross edges
Three cross edges
Four cross edges (regular cross)
At the start of the solve, you can pick what variant or position you want to use based on the given situation, and you build that partial cross while building your F2L pairs. The real benefit of this method is that you do not have to worry about your cross that much, you can go straight into building your F2L pairs, and you can see much farther into your solve than normal because of this. There are also less restrictions, so you can blockbuild much more freely.
So here are the sub steps:
1. Partial Cross (one of the above positions)
2. Building/insertion of F2L pairs
3. Insertion of Cross Edges
4. Normal LL, just like CFOP
PART ONE: Partial Cross
So a partial cross is just a CFOP cross with a few less cross edges in place. It allows for several things that a full cross does not, such as:
Less moves to create
Better look ahead into F2L stage
More freedom to blockbuild
Partial crosses already formed happen much more often than full crosses, so you could have a "cross skip"
Since there are 5 types of partial crosses you can make, you have more choice in what you want to do. Perform this scramble with your cross color on D, and try to figure out what kind of cross you want to make, or what would be the most efficient. B2 L2 B2 L' F2 L U2 L D2 R2 U B' F2 U' F D F' U' L D2 U
Usually, a 2-edge partial cross is the best to make, and they can almost always be made with 3 moves or less. If you do L F D , you just created a partial cross. This is the Adjacent edges partial cross. So now follow this walk through to see how you would go about the F2L pair stage.
Part 2: F2L pairs
First Pair: y R U' (building) R d' R (insert)
This pair was able to be built much more efficiently than if we had cross edges there. The insertion is also only one move, compared to CFOP's 3 move insertions. The only bad part about this was that moving an edge in the D layer can be an adjustment from CFOP, and recognition is slightly harder, since not all edges are in the U and E layers.
Second pair: already built, to insert do U' R U2 R' notice that we also created the third pair, by using a different insert. This is a good example of how there is more freedom to multislot or blockbuild in this step.
Third pair: U' L' U L
Simple insert.
Last pair: This is made very similarly to a regular CFOP pair, except when the edge in in a spot where the cross edge should be, in this case you would simply insert the cross edge to get the other one out. U L U2 L' U2 L U L'
Part 3: cross edges insertion
Okay, now here is the most different step in the whole method from CFOP. Here you use the M slices to insert the cross edges. The edge in position UF needs to go into its proper cross slot down below. To do this, you would do: U M' U' M
2nd cross edge: In this case, the edge is flipped in its position. If we do a y and then a U, notice that both the edges in UF and DF are flipped, so you could use some sort of pure flipping alg to flip them both, and cause an all edges oriented OLL. But for our purposes, we will ignore that. This does open up a neat pathway towards new "last slot" algs. (ZBLCE?) So let's undo that U and we'll do a U'.
So next we will do the following: M' U' M U M' U2 M and that puts our last cross edge in place.
Part 4: OLL/PLL
This is the exact same as regular CFOP, so T-OLL- Sexy-sledge, then we have an H perm, so M2 U M2 U2 M2 U M2.
So to recap, in case you missed a few moves:
Partial Cross: L F D
F2L 1: y R U' R d' R
F2L 2: U' R U2 R'
F2L 3: U' L' U L
F2L 4: U L U2 L' U2 L U L'
So as you can see, our F2L was very move- efficient, at only 24 moves. If we add on the other steps (counting M slices as one move), it would total to be 42 moves. I'm not going to deny that this was a lucky scramble, because it was, but in the end, this is about as efficient as CFOP, but the cross insertion is really fast, and look ahead is much better.
Pros and Cons vs CFOP
Pros
Better look ahead from inspection
More freedom to blockbuild during F2L
Cross edge insertion becomes more like distinct cases, and last slot methods can come into play
Transition from CFOP is minimal, and easy to get good at
Several ways to go about making your cross
LL stays exactly the same
M slices are used (could be either)
Slightly more move efficient
Cons
The freedom in the F2L stage could be slightly harder to recognize if you're not good at blockbuild ing
Cross insertion may require rotations
M Slices are used (could be either)
I'm a little biased.
I know this is kind of incomplete, but I'll come back and work on it later. For now, ask questions if you don't understand something! Please don't criticize me, I can't really say I'm done yet!
Also, I haven't found any evidence of this being done before, but if it has, I have come up with everything I have written here on my own.
I tried your solution twice before I finally tried inputting it move by move into jarcs. Here's the cube I was left with (for obvious reasons, I performed neither the OLL nor the PLL):
Other than that, TDM ninja'd me with my main concerns about the method.
EDIT: Solve works fine, I messed up by hand, and jarcs doesn't accept d turns as d or Dw. My apologies for the confusion.
I tried your solution twice before I finally tried inputting it move by into jarcs. Here's the cube I was left with (for obvious reasons, I performed neither the OLL nor the PLL): View attachment 4147
So why don't you make the focus on blockbuilding- and instead of just blockbuilding pairs, blockbuild two pairs on the left and insert the edge while you're doing it?
Then you could blockbuild the two pairs on the right and their edge.
Then I reckon you could solve the corners, and the rest can be done with MU
...
Point is, if you're going to make variants, don't just make them less efficient versions of things that exist!
I have an idea why not do the F2l before the cross and then insert the edges with U M' U' M and M' U2 M the we can top it off with {OLL, PLL}, {CxLL,EPLL} or ZBLL
also i don't like the partial cross idea, it's like PCMS but with less freedom (my favourite thing about PCMS), and you eliminate a transition but replace it with a more difficult f2l, because you can now have f2l edges on the bottom (i mean you can untrap them as you insert pairs but you may as well be doing freeFOP at that point)
also i don't like the partial cross idea, it's like PCMS but with less freedom (my favourite thing about PCMS), and you eliminate a transition but replace it with a more difficult f2l, because you can now have f2l edges on the bottom (i mean you can untrap them as you insert pairs but you may as well be doing freeFOP at that point)
I think it can be a pain at first to untrap edges, but it actually can be useful if you have a corner that would be paired up when you bring the M slice that contains the edge up. And as far as the partial cross goes, I see it as an easy way to provide a little bit of structure to the solve and reduce the chances of a F2L edge winding up in its place.
And in regards to Hypocrism's post, I would argue that it has roughly the same efficiency, and that block building is slower than making pairs, and it would be like what ryanj92 said, you might as well do freefop.
Thanks for voicing your concerns.
EDIT: added YouTube video, you won't get nearly as much information, but it might be easier to visualize. Also, I didn't know that the camera was that shaky until way after I recorded it. Sorry.
Just click the link on the left for my YouTube channel.
I think it can be a pain at first to untrap edges, but it actually can be useful if you have a corner that would be paired up when you bring the M slice that contains the edge up. And as far as the partial cross goes, I see it as an easy way to provide a little bit of structure to the solve and reduce the chances of a F2L edge winding up in its place.
And in regards to Hypocrism's post, I would argue that it has roughly the same efficiency, and that block building is slower than making pairs, and it would be like what ryanj92 said, you might as well do freefop.
Thanks for voicing your concerns.
EDIT: added YouTube video, you won't get nearly as much information, but it might be easier to visualize. Also, I didn't know that the camera was that shaky until way after I recorded it. Sorry.
Just click the link on the left for my YouTube channel.
I don't see how solving two pairs and then an edge is more efficient than solving them all at the same time, in about 7 moves (isn't it 7ish? I'm not a roux-er). It's probably more fingertrick friendly and move efficient to solve the block rather than pairs, especially since you see all the first one in inspection but I doubt lookahead is realiable enough to solve a comparable number of pieces as pairs.
In addition, lookahead is ruined when edges can be where the cross is meant to be. Now if you suggested a partial cross where you complete 4 edges, but some of the edges can be yellow, that's something I can be interested in...
Oh, I see. You thought this was a variant of Roux. This is actually a variant of CFOP. I never intended for it to be more efficient than Roux. Also, what you're saying about finger tricks and look ahead- the fastest solvers in the world (and slower) can develop excellent fingertricks and look ahead with CFOP, that's the main reason why it is so dominant over blockbuilding methods. Feliks is rumored to be able to see ahead to his second pair during inspection. That through a four piece cross, which can take up to 7 moves, plus another pair. That right there is reliable lookahead. CFOP is known best for it's lookahead. If you tried doing SpeedBLD with Petrus, you would be tracing and tracing for much longer than with CFOP.
Also, how is lookahead ruined? You have a small chance that pieces will be there anyway, because you have 4 pairs and a few edges (at most 2) where they can be. So you could still theoretically look ahead to your second pair during inspection.
Also, your idea about the yellow edges, that's basically the exact same thing I'm suggesting except its likely to take more moves, so lookahead into F2L would be harder. It may be good as a crossover into a fuller form of my method, similar to keyhole vs full F2L.
Oh, I see. You thought this was a variant of Roux. This is actually a variant of CFOP. I never intended for it to be more efficient than Roux. Also, what you're saying about finger tricks and look ahead- the fastest solvers in the world (and slower) can develop excellent fingertricks and look ahead with CFOP, that's the main reason why it is so dominant over blockbuilding methods. Feliks is rumored to be able to see ahead to his second pair during inspection. That through a four piece cross, which can take up to 7 moves, plus another pair. That right there is reliable lookahead. CFOP is known best for it's lookahead. If you tried doing SpeedBLD with Petrus, you would be tracing and tracing for much longer than with CFOP.
Also, how is lookahead ruined? You have a small chance that pieces will be there anyway, because you have 4 pairs and a few edges (at most 2) where they can be. So you could still theoretically look ahead to your second pair during inspection.
Also, your idea about the yellow edges, that's basically the exact same thing I'm suggesting except its likely to take more moves, so lookahead into F2L would be harder. It may be good as a crossover into a fuller form of my method, similar to keyhole vs full F2L.
No, I know it's a version of CFOP, but it takes away all the good parts of CFOP and incorporates just a few of the less promising aspects of roux. It's clearly less efficient than Roux because you solve the pairs on their own and then insert extra edges. It requires rotations, and you don't have a consistent structure because the empty cross edges will be in different places. This means you have to think during the solve which is never good. It doesn't keep the M slice entirely free, and so makes solving the LL edges a lot slower than it would be if you just did Roux.
Now on lookahead, you missed the point. CFOP lookahead is simple because cross is simple, you get plenty of time TO lookahead, and once cross is done then it reduces pairs into known cases. A partial cross isn't simple because you first have to choose which edges to use in your cross and how many (an extra step), you don't have a full cross foundation to work on, and the basis of CFOP just falls apart. Add to that the fact that you don't get all the edges out of the bottom layer in the first step (the main strength of CFOP) and this just doesn't work. Then if you have a partial cross you need to use MUM' to get the edge there out, adding three moves and the time taken to find the edge, when you could have just inserted it with a single flick when you're doing an efficient full cross.
The yellow edge is an entirely different concept to a partial cross method, it is like non-matching Roux blocks would be to CFOP. You'd always have a complete cross, so the problems I've pointed out don't come into effect. If you don't complete a full cross, there's no point in doing CFOP.