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 proposed an unrefined version of this on the HK discord a a week or two ago, but I should post this here: HKY:
during HKF2L, the DF edge is put in the right spot, though not necessarily oriented. Then there is one logical path: COLL. OCLL leaves you with two many cases, but COLL will leave you with a small subset of L5E. If I am right, it should be ~58 algs+COLL

I will call the subset L5EDF unless anyone has a better name

I've recently thought of a possible new big cube method that uses Roux but doesn't quite follow the standard redux layout like Meyer (if this has been proposed before, I apologize):

1. First 2 centers
2. Build Roux blocks on F2C
3. CMLL
4. Pair up and solve the ULUR edges (a little unsure about this step)
5. Solve the rest of the cube using slice moves and U2 (I'll definitely end up breaking this into substeps, but I'm not quite sure how yet)

With modern hardware, I think this could definitely be fast for 4x4/5x5 if the recognition for the substeps in step 5 is good and the step 5 substeps can be solved (mostly) intuitively. I also found some info for a "Stadler Method" for 4x4 that's pretty close to my method but follows redux more closely (english is on the right column): https://www.speedcubing.ch/lösungsanleitungen/4x4-stadler-methode/.

Edit: After some more thought, I've realized step 4 + solving the rest of the cube is probably slower than solving L4C using slice moves, doing a bunch of edge cycles to finish edge pairing, and then doing 3x3 LSE. I've already made MlrU algs that cycle edges while preserving ULUR, so the only thing I really need now are algs that cycle edges in the M-slice which don't necessarily preserve the UL/UR edges (since preserving ULUR makes the edge cycles really move-inefficient).

I've recently thought of a possible new big cube method that uses Roux but doesn't quite follow the standard redux layout like Meyer (if this has been proposed before, I apologize):

1. First 2 centers
2. Build Roux blocks on F2C
3. CMLL
4. Pair up and solve the ULUR edges (a little unsure about this step)
5. Solve the rest of the cube using slice moves and U2 (I'll definitely end up breaking this into substeps, but I'm not quite sure how yet)

With modern hardware, I think this could definitely be fast for 4x4/5x5 if the recognition for the substeps in step 5 is good and the step 5 substeps can be solved (mostly) intuitively. I also found some info for a "Stadler Method" for 4x4 that's pretty close to my method but follows redux more closely (english is on the right column): https://www.speedcubing.ch/lösungsanleitungen/4x4-stadler-methode/.

Edit: After some more thought, I've realized step 4 + solving the rest of the cube is probably slower than solving L4C using slice moves, doing a bunch of edge cycles to finish edge pairing, and then doing 3x3 LSE. I've already made MlrU algs that cycle edges while preserving ULUR, so the only thing I really need now are algs that cycle edges in the M-slice which don't necessarily preserve the UL/UR edges (since preserving ULUR makes the edge cycles really move-inefficient).

I think there's definitely improvements that could be made to the Lewis L5E algs, but I don't have any way to generate new algs. Does anyone know if there's something like cube explorer for 4x4 or 5x5?

This might have been proposed before but here it is anyway.

Build 2 1x2x2 blocks in DBL and DBR, and solve the DF edge
Solve the FL and FR slots using the M slice to orient the edges
Solve L9P (Last 9 Pieces) any way you want. I use CLL the L5E.

This might have been proposed before but here it is anyway.

Build 2 1x2x2 blocks in DBL and DBR, and solve the DF edge
Solve the FL and FR slots using the M slice to orient the edges
Solve L9P (Last 9 Pieces) any way you want. I use CLL the L5E.

I think there's definitely improvements that could be made to the Lewis L5E algs, but I don't have any way to generate new algs. Does anyone know if there's something like cube explorer for 4x4 or 5x5?

CPLine - Like Briggs and YruRU. This usually takes around 3-4 moves on 3x3, so it should be the same on 2x2
CO - Orient the Corners using <R, U>. Can usually be solved in 5ish moves
Solved - Solve a layer using <R2, U>. Most cases are 4-movers, with one being 6 and the worst being 9. This step can be executed really fast

Should average around 12 HTM, and almost all of it is either R U or R2 U

This could also be adapted for 2x2x3 by doing CPLine, Layer(also solving top layer), E-layer. CPLine is similar to Faces, Layer is <R2, U> and faster than PBL, and E-Layer is the same(although it could be influenced during the layer, where you can't easily influence the E-layer normally). Should be around 15 HTM, same as WoowyBaby's method

CPLine - Like Briggs and YruRU. This usually takes around 3-4 moves on 3x3, so it should be the same on 2x2
CO - Orient the Corners using <R, U>. Can usually be solved in 5ish moves
Solved - Solve a layer using <R2, U>. Most cases are 4-movers, with one being 6 and the worst being 9. This step can be executed really fast

Should average around 12 HTM, and almost all of it is either R U or R2 U

This could also be adapted for 2x2x3 by doing CPLine, Layer(also solving top layer), E-layer. CPLine is similar to Faces, Layer is <R2, U> and faster than PBL, and E-Layer is the same(although it could be influenced during the layer, where you can't easily influence the E-layer normally). Should be around 15 HTM, same as WoowyBaby's method

Sounds kinda sketchy, God's number for the 2x2 is 11. I think the actual movecount would be around 14. Could you do some example solves?

A 3-look method for LSLL+EO that can be 2-look with no more algs that I came up with:
1. Using WV, solve an edge and orient corners. 8 moves.
2. Solve the remaining corner using a commutator while influencing pll. 8 moves.
3. PLL. 12 moves.
Total: 28 moves.
Movecount when using ZBLL: 23
With some practice, you can do Steps 2 and 3 in one look. Recognition is also easier than ZBLL (imo). That makes this a 2-look LSLL+EO method that only uses 5 more moves than ZBLL and has better recognition. Are there any disadvantages to this method that I'm not seeing? If not, I will probably be switching to this for Petrus.

A 3-look method for LSLL+EO that can be 2-look with no more algs that I came up with:
1. Using WV, solve an edge and orient corners. 8 moves.
2. Solve the remaining corner using a commutator while influencing pll. 8 moves.
3. PLL. 12 moves.

Do you mean orienting all 8 corners, or just 3 of the top layer corners? If it's orienting all 8 corners, this step is TSLE (104 algs), which is good, but it has already been invented. After TSLE, the whole cube can be solved with TTLL (72 algs + PLL). Two-look TTLL with a comm+PLL is not a good idea, since the oriented corner comms all require a rotation, and R2 U2 R2 U' R2 U' R2 also inserts the last corner while giving a PLL.
If it's just 3 of the top layer corners, this is usually good, since the commutator can be used to orient the last two corners while inserting the final corner. However, if the white corner is twisted in place, this cannot be solved with one commutator, so you'll need to use one of 2 algs for those cases, then do PLL, which is inefficient. I'm not sure how many algs would be needed for this step, but you would need to know all 104 recognition cases, where one algorithm could be used for multiple cases.

Do you mean orienting all 8 corners, or just 3 of the top layer corners? If it's orienting all 8 corners, this step is TSLE (104 algs), which is good, but it has already been invented. After TSLE, the whole cube can be solved with TTLL (72 algs + PLL). Two-look TTLL with a comm+PLL is not a good idea, since the oriented corner comms all require a rotation, and R2 U2 R2 U' R2 U' R2 also inserts the last corner while giving a PLL.
If it's just 3 of the top layer corners, this is usually good, since the commutator can be used to orient the last two corners while inserting the final corner. However, if the white corner is twisted in place, this cannot be solved with one commutator, so you'll need to use one of 2 algs for those cases, then do PLL, which is inefficient. I'm not sure how many algs would be needed for this step, but you would need to know all 104 recognition cases, where one algorithm could be used for multiple cases.

Yeah, I mean just 3 of the top layer corners. If all corners happen to be oriented, you can do [R'DRU'RD'R'U, U], but since it has more moves it might be useful to do TTLL or the variation of TTLL that solves CP. To avoid white corner twisted in place cases, you could use summer variation instead of winter variation, or just do normal LSLL. Though there are 108 cases, there are only 54 algorithms you need to know as mirrors can be used. Due to the nature of winter and summer variation, you know which corner is going to be inserted with the edge, meaning you can predict which corner will be in the DFR position as well as what orientation it will be in, which allows for a very smooth transition into the commutator. You can also predict PLL before doing the commutator, which means that with practice, this can be a virtually pauseless LSLL+EO method. Is there anywhere I can find good summer variation algorithms?

Sounds kinda sketchy, God's number for the 2x2 is 11. I think the actual movecount would be around 14. Could you do some example solves?

A 3-look method for LSLL+EO that can be 2-look with no more algs that I came up with:
1. Using WV, solve an edge and orient corners. 8 moves.
2. Solve the remaining corner using a commutator while influencing pll. 8 moves.
3. PLL. 12 moves.
Total: 28 moves.
Movecount when using ZBLL: 23
With some practice, you can do Steps 2 and 3 in one look. Recognition is also easier than ZBLL (imo). That makes this a 2-look LSLL+EO method that only uses 5 more moves than ZBLL and has better recognition. Are there any disadvantages to this method that I'm not seeing? If not, I will probably be switching to this for Petrus.

This is just worse ZZ-CT. ZZ-CT does have more algs (197), but it is 2 look and does not require a corner to be paired with the E-slice edge when orienting.

ZZ-CT LSLL with EO Steps:
1. TSLE - Solve the E-slice edge while solving corners (Different than winter variation because it doesn't need a corner to be paired with an edge)
2. TTLL - Solve the rest of the Cube

If you are interested in learning this method, there are a few good resources out there.

This is just worse ZZ-CT. ZZ-CT does have more algs (197), but it is 2 look and does not require a corner to be paired with the E-slice edge when orienting.