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.

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.

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

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

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.

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?

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

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?

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?

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?

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.)

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.)

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.

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.

An idea for a 2x2x2 method popped into my head today. It's just a rough concept at the moment, and I'm not completely sure it would actually work or would be feasible. My idea was to create a method that has a fairly low alg count but is still possible to 1-look.

Step 0: Start with 3/4 of a face of opposite colors, similar to Guimond, but 2 of the pieces need to form a bar. This is usually solved already or can be solved with 1 move.

Step 1: The bar goes on the left side of the bottom. Then use 2-gen algs to orient. A caveat is that you can NOT use guimond-optimized algs for this step because pieces should not move between the bottom and top layers. I believe that with using 2-gen algs it should be possible to preserve the permutation of the pieces (or do a simple swap that is easy to track). I believe the alg count here should be 32 (8 cases + mirrors and inverses)

Step 2: Separation and PBL together. There are fewer separation cases than Guimond because you always have a bar on the bottom left. I think this might be 50-60 algs. More than I originally thought.

Potential cons of this method would be high move count, and AUF between steps might make the recognition more difficult. Plus, recognition of the cases for step 2 is apparently fairly tough as well.

I have a 3x3 method idea, that to me, just sounds really nice.

1. Left 1x2x3
2. EO + DFDB
3. Right 1x2x3
4. ZBLL (or 2lll)

Spoiler: Example Solve

Scramble: D B R L' U' L2 B F2 D R2 B2 U2 F2 L2 U' L2 D' B2 L U2
(x2 y)
U D B L' U' B // Left 1x2x3 (6)
r U' r' U' r U2 r U2 r2 // EO + DFDB (9)
U2 R U2 R' U2 R2 U' R' U' R2 U' R // Right 1x2x3 (12)
U2 R' U' R U' R' U2 R U' // ZBLL (9)
36 HTM ! (and 92% R and U moves!!)

Maybe I’ll name it LEOR or something. Thoughts on this method?

I have a 3x3 method idea, that to me, just sounds really nice.

1. Left 1x2x3
2. EO + DFDB
3. Right 1x2x3
4. ZBLL (or 2lll)

Spoiler: Example Solve

Scramble: D B R L' U' L2 B F2 D R2 B2 U2 F2 L2 U' L2 D' B2 L U2
(x2 y)
U D B L' U' B // Left 1x2x3 (6)
r U' r' U' r U2 r U2 r2 // EO + DFDB (9)
U2 R U2 R' U2 R2 U' R' U' R2 U' R // Right 1x2x3 (12)
U2 R' U' R U' R' U2 R U' // ZBLL (9)
36 HTM !! (and 92% R and U moves!!)

Maybe I’ll name it LEOR or something. Thoughts on this method?

Yes, I have definitely made a method like that and I'm sure others have as well. My method starts with EO on two axis. Here's my post about it. It averages in the 40s for movecount, and I have actually gotten a sub-30 FMC using it too, but it's pretty bad for speedsolving