# The New Method / Substep / Concept Idea Thread

#### IQubic

##### Member
hi. imagine we can always predict a 14 move solution (made of two steps first step is 5move and second is 9move) for 2x2 cube.
what will be our average in this way?
This is called one-looking. Many advanced 2x2 solves already do this. Chris Olsen has a tutorial on it: https://www.youtube.com/watch?v=pfPqeBWqQT8

#### wir3sandfir3s

##### Member
I have a few new ideas for methods. PM me if your interested, Cube Explorer sucks for generating Algs.
1. My original method that doesn't have a name. Here are the steps:
Spoiler: Make 2 2x2x2 blocks on completely opposite sides of the cube, while orienting edges. The best way to do this is make the first one in FUL, do a x2, solve a 1x2x2 part of the next block, line it up with the other block and orient edges like Petrus, then finish the block and do and x2 again. Next, per mute the corners using and algorithm, maybe 1-3 if there are too many. Then orient them using an alg. Lastly, per mute the edges. Done.

2. Something I call Reverse Keyhole, or MK (Mossey Keyhole). Steps are:
Spoiler: Solve EO and E-slice -1 edge. Next, solve the rest of the D layer -1 corner. Finally, use the new ZZ LL method posted by 4Chan to finish it off (I think it's called ZZ-HW). The Algs haven't been generated for it, though. You can also use WV then PLL, just pairing the last corner if the last E slice edge, even if they don't match.

Never used spoilers before, so if they don't work, whatever.

Last edited:

##### Member
I have a few new ideas for methods. PM me if your interested, Cube Explorer sucks for generating Algs.
1. My original method that doesn't have a name. Here are the steps:
Make 2 2x2x2 blocks on completely opposite sides of the cube, while orienting edges. The best way to do this is make the first one in FUL, do a x2, solve a 1x2x2 part of the next block, line it up with the other block and orient edges like Petrus, then finish the block and do and x2 again. Next, per mute the corners using and algorithm, maybe 1-3 if there are too many. Then orient them using an alg. Lastly, per mute the edges. Done.
For this method, cube explorer doesn't suck for the algs, the algs themselves suck. The pieces are all in the wrong places for the algs to be nice. Also, the alg count is pretty high considering you essentially have a 3LLL with no real lookahead for this part of the solve especially considering the recognition for some of these algs will be horrible as the pieces are not in nice places either. This will really not be nice for the edges especially.

Also, permutation first is almost never a good idea as it can be difficult to identify cases. I am also not a fan of introducing rotation as a necessary part of the solve (at least knowing you have to do a rotation- especially double rotations and half turns.)

2. Something I call Reverse Keyhole, or MK (Mossey Keyhole). Steps are:
Spoiler: Solve EO and E-slice -1 edge. Next, solve the rest of the D layer -1 corner. Finally, use the new ZZ LL method posted by 4Chan to finish it off (I think it's called ZZ-HW). The Algs haven't been generated for it, though. You can also use WV then PLL, just pairing the last corner if the last E slice edge, even if they don't match.
This is the belt method essentially but no double OLL/PLL. It is a slight improvement and could be ok in the same way triangular fransico is but really, it's never nice to solve pieces directly when you have other pieces in the way.

I will say it does have some spots where it has promise though i think it does need some work first. Perhaps you could develop a nice way to solve the first layer then it could be a viable method.

#### wir3sandfir3s

##### Member
For this method, cube explorer doesn't suck for the algs, the algs themselves suck. The pieces are all in the wrong places for the algs to be nice. Also, the alg count is pretty high considering you essentially have a 3LLL with no real lookahead for this part of the solve especially considering the recognition for some of these algs will be horrible as the pieces are not in nice places either. This will really not be nice for the edges especially.

Also, permutation first is almost never a good idea as it can be difficult to identify cases. I am also not a fan of introducing rotation as a necessary part of the solve (at least knowing you have to do a rotation- especially double rotations and half turns.)
I 100% agree with you on everything, was more of an experimental method for fun. Just wanted to see how a different approach on block building would turn out. As for the cube rotation, I am not a fan of them and never will be, it was just the easiest way I found.

This is the belt method essentially but no double OLL/PLL. It is a slight improvement and could be ok in the same way triangular fransico is but really, it's never nice to solve pieces directly when you have other pieces in the way.

I will say it does have some spots where it has promise though i think it does need some work first. Perhaps you could develop a nice way to solve the first layer then it could be a viable method.
Again, I also agree, but I literally just read the new ZZ variant by 4Chan and decided to make a quick method utilizing it in about 5 minutes. Also just an experimental idea, though I might try and work on this a little more. Seems it could be decent with a little work (and probably help).

#### 4Chan

the new ZZ LL method posted by 4Chan to finish it off (I think it's called ZZ-HW). The Algs haven't been generated for it, though.
ehehe, shucks, I got a mention wowow

Yeah, I stopped generating because of a few bad cases.

But like, 15% are just conjugated PLL algs.
Greater than 50%ishh are just conjugated ZBLL, so I didn't generate cases because there was no need most of the time LOL

#### wir3sandfir3s

##### Member
So, adding on to my MK method, I have found a slightly better way to the first layer.
After finishing the first step (EO+E slice -1 edge), place in 2 opposite edges in the first layer. Next, create a 3x1x1 block to add on to it. Insert with an F2 (another F2 in the next step will fix this). Your keyhole has now changed, so keep that in mind. Lastly, create a CE pair like in ZZ and insert this with F2. Now on to ZZ-HW.

Still working on a better way.

#### wir3sandfir3s

##### Member
But like, 15% are just conjugated PLL algs.
Greater than 50%ishh are just conjugated ZBLL, so I didn't generate cases because there was no need most of the time LOL
Sucks I never learned full PLL.
Good thing I'm learning ZBLL.
Now everyone is gonna tell me how stupid I am. Lol

#### sqAree

##### Member
Sucks I never learned full PLL.
Good thing I'm learning ZBLL.
Now everyone is gonna tell me how stupid I am. Lol
And what are you going to do in case of an OLL skip?

#### sqAree

##### Member
So why is it stupid then?

#### wir3sandfir3s

##### Member
I'm learning full ZBLL before full PLL...
PLL isn't included in the ZBLL Algs in the database, but it's technically part of it.
I'm learning probably the most complicated last layer solution instead of just a simple 21 alg solution (28 with OLL).
I know 2L PLL though, but it's not that efficient.
Back to new ideas and methods! I feel bad for taking this thread off topic.

#### Teoidus

##### Member
Here's my idea for a 4x4 method, which basically is just sort of a blown up version of Roux. I'm not sure if it's fast or not, but I've been using it recently and it's a lot of fun to solve with.

1) 2 centers
2) Blockbuild two opposing 1x3x4s to make a 4x4 equivalent of F2B. Doesn't have to be FB->SB, though you can definitely do that if you want.
3) CMLL
4a) Orient edges, ignoring centers. The idea here is to reduce EO to a 4flip, analogous to the arrow case in LSE, like this I've actually stopped doing this step, as I realized it was unnecessary.
4a) Pair up edges using <l, r, U> (there's one extra alg I use for special cases, but otherwise this is easy, since you don't worry about restoring centers)
4b) Solve centers. Currently I'm just using Niklas and it's mirrors/inverses to solve centers 1-2 pieces at a time. I'm sure more efficient algs could be found for this step, including Rachmaninovian's R4 algs for L4C.
4c) LSE (with potential PLL parity).

##### Member
Here's my idea for a 4x4 method, which basically is just sort of a blown up version of Roux. I'm not sure if it's fast or not, but I've been using it recently and it's a lot of fun to solve with.

1) 2 centers
2) Blockbuild two opposing 1x3x4s to make a 4x4 equivalent of F2B. Doesn't have to be FB->SB, though you can definitely do that if you want.
3) CMLL
4a) Orient edges, ignoring centers. The idea here is to reduce EO to a 4flip, analogous to the arrow case in LSE, like this I've actually stopped doing this step, as I realized it was unnecessary.
4a) Pair up edges using <l, r, U> (there's one extra alg I use for special cases, but otherwise this is easy, since you don't worry about restoring centers)
4b) Solve centers. Currently I'm just using Niklas and it's mirrors/inverses to solve centers 1-2 pieces at a time. I'm sure more efficient algs could be found for this step, including Rachmaninovian's R4 algs for L4C.
4c) LSE (with potential PLL parity).
This is like stadler and it can be passably fast if you get good at blockbuilding and learn the algs. It's fun so good luck if you decide to continue to use it

#### wir3sandfir3s

##### Member
I have a cool idea for an algorithm set. Instead of ZBLL, with 493 algorithms, we can use COALL, with 111 Algs. This can be viewed on the wiki. The difference between the two is efficiency. Many methods like FreeFOP, ZZ, and Petrus setup for ZBLL with no Algs, making ZBLL a good choice (for 1LLL). COALL, however, takes advantage of oriented corners, which then results in less Algs. The thing is, the only way to setup for this is to use CFOP and use WV. I feel like COALL could replace ZBLL altogether. So we need something besides WV.
My idea for the algorithm set I mentioned earlier is to use FreeFOP up to the point where you insert the last edge piece and orient the edges. Instead of orienting edges, we can use an alg set of 28 to orient the corners while inserting the edge.
This isn't the best solution, but it's an idea. There may be a way to set up for this intuitively, like orienting the edges.
I'm not sure how this would work out and even if it is a good idea. But I think it's worth experimenting with.
Let me know what you think.

#### Teoidus

##### Member
This is like stadler and it can be passably fast if you get good at blockbuilding and learn the algs. It's fun so good luck if you decide to continue to use it
Any good resources available for stadler? Sounds promising.

I have a cool idea for an algorithm set. Instead of ZBLL, with 493 algorithms, we can use COALL, with 111 Algs. This can be viewed on the wiki. The difference between the two is efficiency. Many methods like FreeFOP, ZZ, and Petrus setup for ZBLL with no Algs, making ZBLL a good choice (for 1LLL). COALL, however, takes advantage of oriented corners, which then results in less Algs. The thing is, the only way to setup for this is to use CFOP and use WV. I feel like COALL could replace ZBLL altogether. So we need something besides WV.
My idea for the algorithm set I mentioned earlier is to use FreeFOP up to the point where you insert the last edge piece and orient the edges. Instead of orienting edges, we can use an alg set of 28 to orient the corners while inserting the edge.
This isn't the best solution, but it's an idea. There may be a way to set up for this intuitively, like orienting the edges.
I'm not sure how this would work out and even if it is a good idea. But I think it's worth experimenting with.
Let me know what you think.
Maybe instead of orienting corners, you could permute them? Then you would end up with an OLLCP subset.

Last edited:

#### wir3sandfir3s

##### Member
Maybe instead of orienting corners, you could permute them? Then you would end up with an OLLCP subset.
COALL has less than a third of Algs than OLLCP, and recgonition for permuting first isn't good.

#### Teoidus

##### Member
You wouldn't use all of OLLCP, just the ones with CP already solved (i'm not sure how many that is, but it's definitely not 3 times more than COALL). The recognition isn't great, true, but it's worth looking at.

#### wir3sandfir3s

##### Member
You wouldn't use all of OLLCP, just the ones with CP already solved (i'm not sure how many that is, but it's definitely not 3 times more than COALL). The recognition isn't great, true, but it's worth looking at.
So basically OLL that doesn't affect CP. 57 algs or something like that wouldn't be bad, then force an EPLL? Not a bad idea, actually. I can try to generate them, or see if they already exist. As to permute them in the first place, this will add another look... 3LLL is not a good idea. Again, still with COALL.

#### Teoidus

##### Member
Well, you'll either have 1 look WV + 1 look COALL, or 1 look CPLS + 1 look OLLCP subset.
Another idea is to solve EP...? You'd probably have to generate an entirely new algset for that, but it coudl be something worth trying.

Edit: I was mistaken actually, you wouldn't have an OLLCP subset, since you'd have to handle EP as well. I don't know how many cases that'd be, but COALL is probably the way to go then.

#### 2180161

##### Member
I know this has been posted before, but I am curious. Is this method feasible?
EOline (DL and DR)
FB
SB
COLL
EOLSE

Example:
Scramble: L' F2 U' B2 F2 U B2 U' F2 R2 D U2 F R' B' F' D R2 D R2 B2
y2 M2 F B' R' B D r' M D2// EOline (I'm not efficient)

R U2 B2 R2 U R U R' U2 R U' R U' R2 L' U L U' R U R U2 R' U' R U' L U' R' U L'// F2B (again, I'm not efficient)

F R U R' U' R U' R' U' R U R' F'//COLL

U M U2 M U2 M2//EOLSE
59 STM

Someone more efficient could probably do much better.
alg.cubing.net here

Last edited: