# L5C, SL5C, and more: New techniques and an often dismissed 3x3 method now fully developed

#### Athefre

##### Member

I have developed full L5C and an alternate L5C that I’m calling SL5C (Shortened L5C). The algorithms are developed to fit the following method:
• First block on the left.
• 1x2x2 on the right.
• L5C
• L7E
This is a method that has been proposed a few times over the years. However, it had yet to be fully developed. This is because each time it had been proposed, the community suggested to the proposer that it isn’t good due to the final two steps. Well I think it is time to show that this method could be good. The advantages and disadvantages are obvious and can be debated. Over the past year I have spent a lot of time developing algorithm sets, recognition methods, sub-methods, and techniques for both L5C and L7E. It started with development for 42 and Waterman then I extended it further with development of full L5C, SL5C, and additional ideas. I have developed full L5C (two versions) and an L7E method. So this 3x3 method is now complete and fully useable.

L5C: This is the complete set of 614 algorithms to solve all five corners in a single step.

SL5C: The other I’m calling SL5C (Shortened L5C). In SL5C the algorithms are reduced by 1-2 moves by leaving out the last U* and R’ move for many cases. This takes advantage of one of the strengths of L7E which is that the two remaining R layer edge positions can be either FR + UR or UR + BR and the corners don’t need to be perfectly solved at the start of L7E. So the corners can be in any of five states (solved in any AUF, R U* offset, U R U* offset, U' R U* offset, or U2 R U* offset) and L7E still works as normal. This leaves the cube in the same pseudo L7E state that is in the 42 method but accomplished in fewer moves. The opposite of this could be developed as well, where the square is at dfR and the SL5C algs will often end with the two unsolved edge positions at FR and UR.

I’m calling the algorithm cutting technique truncation. This concept likely best applies to algorithm use. But it should work for some intuitive steps as well. In truncation, a certain number of moves are cut off of the end of a sequence of turns. Depending on the step on which this is used, it can reduce the movecount of the solve and allow the user to have better, more ergonomic solutions versus performing the full length of the step. At first it is being applied to L5C and corner methods in general. However we may be able to find other applications besides just corners. With Zipper, it would be F2L-1 > SL5C > L5E or L5EP if used with ZZ. Though the L5E and L5EP angles need to be accounted for. With Waterman and other corners first related methods, it would be used during CLL, EG, L5C, or any other corner method.

L5C and SL5C movecount and MCC:

SL5C cases that benefited from the L5C truncation:

CLL: 27/42 (64%).

TCLL+: 34/43 (79%).

TCLL-: 34/43 (79%).

UO: 121/162 (75%).

U+: 128/162 (79%).

U-: 134/162 (83%).

Total 478/614 (78%)

I spent a lot of time testing every algorithm so that great ones would be provided in the document. I am just one person though. There are likely better algorithms for a lot of cases and the kinds of algorithms that people use change over time due to new ones being found, new fingertricks, and new hardware. I'm already looking back at the sets that I started with and wanting to regenerate. So through a community effort, we will be able to find even better algorithms.

Recognition:

I have also developed a recognition method which follows the below steps.
• If the D layer corner is on the D layer, use CLL or TCLL recognition. If the D layer corner is on the U layer, determine the orientation of that corner.
• Find the orientation of three of the U layer corners that belong on the U layer. You can choose to always check the three that are on the U layer or any two on the U layer and the one that is currently on the D layer. Choose the positions that you want to check every solve.
• Recognize the pattern in those three corners from step 2.
I think this recognition method is similar to a recognition method that is in one of the Zipper documents. Though I don’t see a description of how it works. The difference here is that there is a full description of the recognition, the idea of the user having free choice of any three U layer corners, and the cases are completely organized by the sub-orientations.

L5C: This is the full 614 algorithms. It requires learning 614 recognition patterns and the full length algorithms.

SL5C: This is the same as L5C but with shortened algorithms.

CCMLL: This is used in the 42 method. A U layer corner is positioned above the right side 1x2x2 and an R turn is performed to make a pseudo CLL. The U layer corners are then solved using CLL or TCLL algorithms. This reduces the number of cases to 42 if an oriented corner is used or 168 if the corner is in any orientation.

My overall opinion: If you want the lowest movecount and the easiest recognition, SL5C is the best. If you want to learn as few algorithms as possible, CCMLL and the 42 method is the way to go.

• SSL5C: There is something about SL5C that I noticed. It seems to be that each case has a shorter or longer compliment version which is the same algorithm but with fewer or additional moves at the end. Example: The SL5C version of (U2) F U R U' R2 F' R U' R U2 R', (U2) F U R U' R2 F' R U' R done in reverse leads to a different looking L5C case. That case, after recognizing using NML5C, can be solved using (U') F U R U' R2 F' R, which is already a full L5C algorithm. This algorithm is the same as the original SL5C algorithm minus the last two moves. This might could be used as a memory aid to learn the two related algs in tandem. So the user would learn it as something like (U2) (U’) F U R U' R2 F' R U' R. This could cut down on the memorization effort. But it may also make recall difficult. This needs more research.
• Union L5C (UL5C): This is an L5C reduction method that I might finish development on sometime. The corners are reduced to the fully solved position, R’ away, U R’ away, U’ R’ away, or U2 R’ away from solved. It works by finding groups of four cases which can all be solved to those pseudo states using the exact same algorithm. The number of algorithms required to learn compared to full L5C is reduced (divided by 4) since the same algorithm will be used for four different cases. This reduction method is pretty much the inverse of CCMLL.
• I went down a long thought path of combining the truncation technique of SL5C with UL5C and CCMLL. These various combinations lead to interesting variants on the number of algorithms required to be learned, the number of recognition patterns, movecount, and recognition style. All of these combinations don't go to any extreme outside of SL5C or 42. None of them have a lower movecount than SL5C and none have fewer required algorithms or patterns than 42.
• A long term plan is to incorporate pseudo L5C recognition into ACRM. This means the use of the L/R stickers for recognition when any right side 1x2x2 is allowed to be built.

First block: 7 moves.

Square: 8 moves.

L5C: 10.47 moves + .75 AUF for standard L5C. 9.00 moves + .75 AUF for SL5C.

L7E: 17-18 moves. More advanced L7E methods or extensions to current L7E methods may be able to reach ~15 moves.

Total:
• ~43-44 moves with standard L5C and a standard L7E method.
• ~41-42 moves with SL5C and a standard L7E method.
• ~39-40 moves with SL5C and a more advanced L7E method.
• ~37-38 moves with SL5C, a more advanced L7E method, and pseudo blockbuilding (any right side 1x2x2).
This is based on full speedsolve reconstructions and the existing algorithm sets. The advanced L7E method number of 15 moves is an estimate right now. The estimate for pseudo blockbuilding is a reduction of 2 moves which is typical based on my experience over the years developing and using pseudo in various methods.

#### GodCubing

##### Member
Excellent work. L7E still needs some work; It is both very promising and very difficult. I think adapting ATCRM to TCMLL would make advanced 42 more manageable. A final note is that the CCMLL algs used in 42 are not optimized for the 7th unsolved edge or the R U* symmetry. Anyone who wants to help develop this method should consider joining the discord (https://discord.gg/MQzYg4Ptff).