# The New Method / Substep / Concept Idea Thread

#### PapaSmurf

##### Member
I really like the idea of mixing in L5C with Roux. The method I use for L7E in the latest LMCF still isn't optimal, and so I was thinking about L7E skips and I think there is an option to force L7E skips without 3,000 algorithms.
Carry on... (although I think we should look at L7E in general)
Consider this modification to Z-cell:
It isn't a modification to Z-CELL, it's a modification to Roux with L5C, but anyway.
1. When generating the 614 L5C algorithms, choose variants where the FR edge is dislocated/disrupted; this should not add any moves to the average since in almost every case the FR edge will be disrupted
2. For each of the 614 L5C algorithms, memorize the effect that it has on the FR edge; more specifically, memorize the starting location of the edge which ends up in the FR slot after the L5C algorithm (location + orientation)
3. Now solve first block, and back right corner.
4. We are now at the L5C step. Having looked ahead during solving of the back right 2x2 block, you know where the FR-destined edge is (in one of 7 possible locations); now use M/U moves to place that edge in the correct location such that it gets automatically solved by the L5C algorithm. According to my calculations the average number of moves this will take is about 4, with no case taking more than 5; however there is a 1 in 7 chance the FR edge is already in the FR slot which is a case we cannot easily resolve without learning another 614 algorithms
5. Do the L5C algorithm; now in 6 of 7 cases, you skip the FR edge
6. Finish with Roux L6E-EOLR

Using this method, 6/7 (85%) of the time we skip the FR edge and go directly to L6E. 1 in 6 (14%) we need to solve the FR edge after L5C. It is of course possible to learn 3 sets of L5C algorithms to deal with that 1 in 6 chance, but probably not worth it for most people.

So using this method, almost every solve you skip the last roux slot (7.5 moves average according to PapaSmurf), and that step is 'replaced' with pre-location the FR edge into the correct location such that it is automatically solved by the L5C algorithm, and that step takes around 4 moves average, so we dropped the move count by 3.5.

For the extremist who is willing to learn 1800 algorithms, you learn 3 variants of each L5C algorithm, the two additional variants deal with the case where the FR edge is already in the FR slot and oriented, the other case is where the FR edge is already in the FR slot and disoriented. While few people would learn all 1800 algorithms, those cases are crazy awesome, because if you knew the 1800 algorithms, then if the FR edge is in the FR slot (oriented or disoriented), you now get a full last-slot skip, since you do not need to pre-locate the FR edge and it is solved by the L5C algorithm variant. So in that case, you save a full 7.5 moves over Roux (plus, possibly an extra move and a half based on L5C taking slightly less than CMLL).
With current movecounts that gives 7+7+10.75 (ish)+4+12(ish)=40.75 which is very very good. If you go the other route and get a movecount of 15 or less for L7E then you have 7+7+10.75 (ish)+15=39.75 which is revelutionary tbh.

Last edited:

#### CubeBlazer

##### Member
Instead of just making the final steps DFDB L5C L5E, you could have a variant like Zipper-b with a EODFB, then finish with Zipper-b LSLL. Not sure if it's any more optimal though.

#### efattah

##### Member
For the record I will name the variant I suggested Roux-LSS (=Roux, Last Slot Skip). Just to re-iterate:
- FB
- Back right 2x2
- Pre-locate FR edge for L5C algorithm
- Execute L5C algorithm which auto-solves last slot because FR edge was pre-located
- L6E

According to the 2x2 L5C thread there are 486 cases for L5C including CLL, TCLL+, TCLL-. I'm not sure where the number 614 came from, or which is correct.

CubeBlazer's Zibber-b LSLL variant sounds promising but I'm not that familiar with Zipper-b.

#### PapaSmurf

##### Member
Zipper is where you solve F2L minus an edge, then you either do CFRLL (CLL ignoring the FR edge) then L5E, or you do OLLCP then L5EP.
EO solved L5C will be less efficient than without EO solved then L5EP is equal to L5E in terms of movecount.
For 614: there are 2 sets of L5C: corner in slot and corner out of slot. Alg count for corner in slot is (43*3=)129. For corner out of slot, there are 27 orientations for every orientation of the D corner, so that's (27*3=)81. For each of those cases there are 6 CPs, so (81*6=)486. Then add 129 and 486 together to get 615. One of those is the solved case, so 614.

#### CubeBlazer

##### Member
For Roux-LSS, it's not just TCLL. It literally would be my other method which I'm genning algs for (haven't got a name yet;
The steps are:
Cross
F2L-1
COLS(LS+CO
CPELL(COALL
I'm genning COLS, Manchot already has a site with CPELL
COLS alone has around 1100 algs, while with Roux-LSS, that adds another 2 cases to deal with, which brings it up to around 1150 algs, which is not very good with a Roux start and end.

#### CubeBlazer

##### Member
Even though I'm genning algs for "my" method, my method is still more viable because almost all algs are genned for the Partial set (just need to gen the flipped FR cases, I'm pretty sure the ZZ-C LS algs are optimal already; it's called the Partial set because you can rotate and use lefty qlgs), but for the full set, another 567 algs need to be genned. For Roux-LSS, it would be another 675 cases (without M setups to other cases in M slice) and that ignores CP. Unless you would do CP afterwards, the alg total would be raised once again. Because COLS didn't include CP(it's only CO), it gets to the point where there are 10,000+ algs.

Edit 1: My math is wrong, I did 27*21 additional algs for "my" method when it really is ((27*15)+(8*6)), but my math is also wrong between the difference of Roux-LSS and COLS. It's actually another 372 algs.
Edit 2: Just figured out my method is 959 algs. 802 for COLS, 157 for CPELL(COALL - Genned and published by Cubeur-Manchot). Also, it's not even my method, it was Blah's idea back in 2009, but work didn't start until earlier this year

Last edited:

#### efattah

##### Member
I'm getting confused. For Roux-LSS, L5C has 614 cases and the pre-located edge does not add any algorithms. So the number of algorithms is the usual number of Roux algorithms +614 (L5C) minus 42 (CMLL) = Usual Roux +572.
This is for the case where you cannot skip the last slot if the FR edge is already in place without the FR corner also in place.

#### CubeBlazer

##### Member
You said prelocate and solve both at the same time and it got me confused lol. If you're setting the case up, why not just use comms to solve the whole thing? You could do L5C into a 3style comm to prevent getting 6flips

#### PapaSmurf

##### Member
You said prelocate and solve both at the same time and it got me confused lol. If you're setting the case up, why not just use comms to solve the whole thing? You could do L5C into a 3style comm to prevent getting 6flips
That's slow and less efficient.

#### Skewbed

##### Member
How about doing FB, SB minus the FR edge, set up the FR edge with <MU>, CMLL that solves FR, then L6E.

It's the same alg count as CMLL, with more efficient algs than CMLL because of more unsolved pieces and possible positions for FR.

Although it might be slower because of the FR edge setup.

L5C is probably better, but worse recognition and more algs.

#### Sue Doenim

##### Member
Here's an interesting idea that I don't think I've heard before: CLS, but you also permute the corners at the same time. If you attach the corner to the edge before inserting, disregarding the edge's orientation, you have about 3 times the alg count of any other CLL-type method. It would only save a few moves though. I don't know if it would be worth it.

#### CubeBlazer

##### Member
That's called CPLS, but if you attach the corner, it would be 5000+ algs probs

#### KAINOS

##### Member
Not an actual new method or anything, but I found out that doing <R, U> scambles on a cube then <L, U> scrambles doesn't affect CP state - in other words you could solve LB first with <L, U> (not using reverse scramble) and the rest of the cube would be still in <RU> 2-gen solvable state. Maybe this could open up to a possibility for new CP-first method...or not

Edit: I guess it might work on leor, if you do CP then <L, Lw, U> FB and the rest within <R, Rw, U> moveset. I'm not sure if it would be actually worth it though?

Last edited:

#### KAINOS

##### Member
Yay for double post

Possibly the most impractical subset/concept ever proposed in this thread, but anyway my idea is: 2-gen 1-look LSLL. Alg count is ~1600 (84 2GLLs, <100 each for two T2GLL sets, and 1296 for the rest) which is quite a lot for sure. Still it's cool to see that 1LLSLL can be done with algs less than half of 1LLL for normal CFOP. (3915 algs)
One of the possible ways to make this actually viable would be to have some corner control before finishing the F2L-1, for instance making sure at least 2 of the corners are oriented. I think it would be possible to cut down the alg count to ZBLL level with that kind of case restriction, which is already proven to be humanly possible to learn and use (still very difficult though.)
Maybe you could use it together with CP-Leor I mentioned in the previous post?

Edit: Never mind, looks like my calculations were way off

Last edited:

#### ImmolatedMarmoset

##### Member
I was thinking we should probably concoct a wiki page for LEOR so that all of the info about it can be in one place. That would be really useful for people who are thinking about switching, like myself. (There’s a very good chance I won’t, but there’s a chance I will if I try it out and like it.) Also, does anyone know optimal human movecount for each step?

#### PapaSmurf

##### Member
I was thinking we should probably concoct a wiki page for LEOR so that all of the info about it can be in one place. That would be really useful for people who are thinking about switching, like myself. (There’s a very good chance I won’t, but there’s a chance I will if I try it out and like it.) Also, does anyone know optimal human movecount for each step?
It probably wouldn't be too hard. Also, 7, ?????, 12, 16 ish depending on algs.

#### KAINOS

##### Member
I was thinking we should probably concoct a wiki page for LEOR so that all of the info about it can be in one place. That would be really useful for people who are thinking about switching, like myself. (There’s a very good chance I won’t, but there’s a chance I will if I try it out and like it.) Also, does anyone know optimal human movecount for each step?
It probably wouldn't be too hard. Also, 7, ?????, 12, 16 ish depending on algs.
I ran some solves on HARCS and the average movecount for EO+DFDB (stepwise optimal) was ~10.6, while optimal for the whole step was ~8.0. (Both in <RrUM> moveset and STM metric)
I think finding optimal solution for both EO and DFDB shouldn't be too difficult. Plus you can influence DFDB pieces during EO and also cancel some moves, so I'm guessing the number will be somewhere in 9.5-10 range.
(I only did 30 solves, though, so the numbers could be off by a good bit.)

#### ImmolatedMarmoset

##### Member
I ran some solves on HARCS and the average movecount for EO+DFDB (stepwise optimal) was ~10.6, while optimal for the whole step was ~8.0. (Both in <RrUM> moveset and STM metric)
I think finding optimal solution for both EO and DFDB shouldn't be too difficult. Plus you can influence DFDB pieces during EO and also cancel some moves, so I'm guessing the number will be somewhere in 9.5-10 range.
(I only did 30 solves, though, so the numbers could be off by a good bit.)
So then we have like 7+10+12+16 which is ~44 movecount but the last step is algorithmic so it would be quite fast (not to say that LSE isn’t fast)

#### Cubinwitdapizza

##### Member
I want to know if anyone has thought of this and also can someone tell me how to use an alg generator?

So basically this is very similar to vandenbergh for squan. Steps:

1. EO and placing E layer edges into correct place (or one bar a R2 away from being solved).
2 CT: this is where you basically see what corners have colors other than yellow on top and twist them. I need to generate algs for this because I have not found an efficient way to do this.
3 CO. This doesn’t have to be explained
4 EO (but like squans EO). You basically just do M2’s and M’ U2 M to put the yellow/white edges in the correct place.
5 CP. you basically do it the same as squan but again need to generate algs for it because some don’t work on 3x3.
6 EP. You permute edges simultaneously on each side. Need to generate algs.

You could also combine CP and EP by doing a PLL on each side or making an alg that solves both sides.

Also in the middle of that somewhere after CO EO you need to do R2 U2 R2 to flip the bar. This also swaps the FU piece and the BU piece. So ya just please at least send me a link to a video on how to generate algs. Now this might not be very speedsolving efficient but it’s basically just something I wanted to share.

#### PapaSmurf

##### Member
I want to know if anyone has thought of this and also can someone tell me how to use an alg generator?

So basically this is very similar to vandenbergh for squan. Steps:

1. EO and placing E layer edges into correct place (or one bar a R2 away from being solved).
2 CT: this is where you basically see what corners have colors other than yellow on top and twist them. I need to generate algs for this because I have not found an efficient way to do this.
3 CO. This doesn’t have to be explained
4 EO (but like squans EO). You basically just do M2’s and M’ U2 M to put the yellow/white edges in the correct place.
5 CP. you basically do it the same as squan but again need to generate algs for it because some don’t work on 3x3.
6 EP. You permute edges simultaneously on each side. Need to generate algs.

You could also combine CP and EP by doing a PLL on each side or making an alg that solves both sides.

Also in the middle of that somewhere after CO EO you need to do R2 U2 R2 to flip the bar. This also swaps the FU piece and the BU piece. So ya just please at least send me a link to a video on how to generate algs. Now this might not be very speedsolving efficient but it’s basically just something I wanted to share.
SSC but worse.