# The New Method / Substep / Concept Idea Thread

#### Aeron

##### Member
I literally just thought of this method for 3x3. No names, most probably thought of. Heavily uses M-slice.

So, this is a sort of M-slice relying method like Roux, but its easier I could say?

Steps :
First 4 Columns
F2L using U moves and M-slices
OLL
PLL

This is super indetailed, so just read through.
Basically, you build 4 big 1x1x3 columns on 4 sides of the cube intuitively. The next step uses a lot of center orienting
(cuz the centers aren't always in the correct place) and M-slices to solve F2L while preserving Corner Permutation. and for LL, since the 4 Corners are oriented and permuted, you just need to solve edges with the 3-4 OLL cases for solving edges only. The next step will mostly be M-slice PLL algs, namely U,U',Z and H-perms. there may be other non-M-slice algs but it is still a PLL alg which you most probably have already learnt. That is all for this crappy and probably very inefficient method. Please tell me whether this method was created before(probably), and comment your views on this method.

##### Member
I literally just thought of this method for 3x3. No names, most probably thought of. Heavily uses M-slice.

So, this is a sort of M-slice relying method like Roux, but its easier I could say?

Steps :
First 4 Columns
F2L using U moves and M-slices
OLL
PLL

This is super indetailed, so just read through.
Basically, you build 4 big 1x1x3 columns on 4 sides of the cube intuitively. The next step uses a lot of center orienting
(cuz the centers aren't always in the correct place) and M-slices to solve F2L while preserving Corner Permutation. and for LL, since the 4 Corners are oriented and permuted, you just need to solve edges with the 3-4 OLL cases for solving edges only. The next step will mostly be M-slice PLL algs, namely U,U',Z and H-perms. there may be other non-M-slice algs but it is still a PLL alg which you most probably have already learnt. That is all for this crappy and probably very inefficient method. Please tell me whether this method was created before(probably), and comment your views on this method.

This is more or less PCMS though that doesn't do OLL/PLL as that is more inefficient and slower.
It's not too bad a method though not very widely used and it is generally acknowledged that roux is better because you don't have to deal with S or rotations which can be difficult to do smoothly in a slice heavy method. Cool idea though yes it has been thought of before.

#### Shiv3r

##### Member
This is more or less PCMS though that doesn't do OLL/PLL as that is more inefficient and slower.
It's not too bad a method though not very widely used and it is generally acknowledged that roux is better because you don't have to deal with S or rotations which can be difficult to do smoothly in a slice heavy method. Cool idea though yes it has been thought of before.
yeah, all corners/columns first, when optimized enough, become roux.

#### Shiv3r

##### Member
So I was looking at a proposed alg set a while back (L5EP, I think the original post called it TPLL so that's what I'll use), and it made me think about applying it to other methods, as it's one of the only truly viable 1LLSLL methods and I think it has some serious OH potential as all the algs are 2 Gen. I decided to incorporate them into what are currently the "Big 4" solving methods (movecount is simply predicted, I haven't had much time to test):

ROUX: Good ergonomics and movecount
-FB+DB Edge
-SB -1LS Edge (Oriented)
-EO+FB Edge
-COLL
-TPLL

ZZ (Original): Good ergonomics and movecount
-EO Line
-F2L -1LS Edge
-COLL
-TPLL

CFOP: Decent ergonomics and movecount
-Cross
-F2L -2(1 slot 1 LS edge oriented)
-VHLS
-COLL
-TPLL

PETRUS: Decent ergonomics, good movecount
-2x2x2
-2x2x3
-EO
-F2L -1LS Edge
-COLL
-TPLL

These are definitely works in progress, but I think that TPLL could be a valuble tool for OH in particular. This may be personal bias as I am a ZZ solver, but I think that if you were to use this and ZZ-CT, one would be OP at OH, because you pretty much eliminate all bad/long TSLE cases and get to end in a 2 gen solve. I would likely rank the methods as ZZ, Roux, CFOP, then Petrus for speedsolving; but this of course varies from person to person. Let me know your thoughts and any improvements to the methods!

after actually trying it, it may be decent. If you know COLL, it is actually pretty good.
I think that the problem is that if you are neutral with this and ZZ-CT, you have to decide between TSLE-TTLL and TPLL.
I think it may be a better Idea to use this subset if you are using ZZ, and normally do COLL-EPLL, because unless you get a really easy insert you can use this subset(which all except the 5-cycles, can be done as conjugated EPLL's), and COLL would be the same as you normally would. I actually may use this with ZZ for OH for a while, even though I went back to roux OH. I have seen this before but it was to be used in a different place and I didnt like it.

#### MethodNeutral

##### Member
Basically, you build 4 big 1x1x3 columns on 4 sides of the cube intuitively.
I don't know about anyone else, but I don't know of any way to build columns completely intuitively, I just do four F2L pairs and COLL (I can't be bothered to learn CLL or CMLL). Is everyone just overlooking this or is there something I don't know?? I'd be really interested in learning how to do this intuitively.

#### Shiv3r

##### Member
I don't know about anyone else, but I don't know of any way to build columns completely intuitively, I just do four F2L pairs and COLL (I can't be bothered to learn CLL or CMLL). Is everyone just overlooking this or is there something I don't know?? I'd be really interested in learning how to do this intuitively.
youre nit missing anything, you do CLL. or something like WV.

#### Teoidus

##### Member
Wait guys, I did some calculations for finishing off L10P of Lewis method (after F and U centers are solved, solving the last 10 wing pieces).

So the idea is to use a single comm to solve one DF wing + solve one other wing on LL, then do the same with the second DF wing (so now the wings are solved and there are at most 6 unsolved wings on LL). Then permute the remaining wings in 1 look. (leading to a 3look system)

I think this is actually feasible, since alg count is 6!/2! wing permutations * 1 wing orientations / 4 U symmetries = 90 cases.

#### Shiv3r

##### Member
Wait guys, I did some calculations for finishing off L10P of Lewis method (after F and U centers are solved, solving the last 10 wing pieces).

So the idea is to use a single comm to solve one DF wing + solve one other wing on LL, then do the same with the second DF wing (so now the wings are solved and there are at most 6 unsolved wings on LL). Then permute the remaining wings in 1 look. (leading to a 3look system)

I think this is actually feasible, since alg count is 6!/2! wing permutations * 1 wing orientations / 4 U symmetries = 90 cases.
I like the Idea, my only problem is the alg count. It may make sense to learn comms to do that though.
My 4look system is the way I'm using it right now, and I have gotten 1:01 with that so...
Ill tell you guys as soon as my PB hits sub-1

#### Teoidus

##### Member
I was using 2GR on reddit's daily scramble and got this wonderful 40 HTM solution:

D2 L' D' F2 D B2 L B U2 R F R U2 L2 B U' F' D2 L2 D'
x y // insp
U2 r u r' U' f2 // EOPair 6/6
r' F r // 2GLine 3/9
R U' M2 U R' u2 // Block 6/15
R U' R U R U R U' R' U R // F2L 11/26
U' R U R' U R U' R' U R U2 R' U' R2 // 2GLL+R2 14/40

#### sqAree

##### Member
I was using 2GR on reddit's daily scramble and got this wonderful 40 HTM solution:

D2 L' D' F2 D B2 L B U2 R F R U2 L2 B U' F' D2 L2 D'
x y // insp
U2 r u r' U' f2 // EOPair 6/6
r' F r // 2GLine 3/9
R U' M2 U R' u2 // Block 6/15
R U' R U R U R U' R' U R // F2L 11/26
U' R U R' U R U' R' U R U2 R' U' R2 // 2GLL+R2 14/40
It's interesting, I thought 2GR would turn out to be not too efficient, because solving with only R and U is known not to be too efficient. Now it seems like I was right in the sense that the 2-gen part is by far the longest in the method and wrong in the sense that the whole solve has still super few moves. Which together makes the method awesome. I'm pleasantly surprised. I consider learning that for OH once it's fully developed.

#### Teoidus

##### Member
Well, admittedly this is a lucky solve. <R,U> is not at all efficient, and average movecount is still projected to be just barely sub-50. However i have been surprised by a good number of low-40 or lower (I had one that was 34 moves!) solves--I think this is because of how lucky it's possible to be with each step (EOPair might be very easy, Block step could have preformed lines, F2L can make use of F2L-on-left and R2/U2 pseudos, OLL skips can happen, you can get pure sune 2GLLs, etc.) I think this luck can be further enhanced by learning more ways to solve the <R,U> subgroup (e.g. using TSLE-TTLL or CLS-L5E when last pair looks bad).

If you want a more representative sample of what 2GR solves are actually like, I've posted 9 example solves further up in this thread. I'm not "cherrypicking" these solves, they really are a list of all the 2GR solves that I've done so far. (Basically whenever I pull up a new cstimer scramble I plug it into alg.cubing.net and type up the solve. So in total I've only done 10 full 2GR solves.)

Including this last 10th solve, average movecount is 44.7 (σ = 6.05). Still lower than the expected 47, but I'm going to be a bit pessimistic and assume that I've just been getting lucky.

#### sqAree

##### Member
Well, admittedly this is a lucky solve. <R,U> is not at all efficient, and average movecount is still projected to be just barely sub-50. However i have been surprised by a good number of low-40 or lower (I had one that was 34 moves!) solves--I think this is because of how lucky it's possible to be with each step (EOPair might be very easy, Block step could have preformed lines, F2L can make use of F2L-on-left and R2/U2 pseudos, OLL skips can happen, you can get pure sune 2GLLs, etc.) I think this luck can be further enhanced by learning more ways to solve the <R,U> subgroup (e.g. using TSLE-TTLL or CLS-L5E when last pair looks bad).

If you want a more representative sample of what 2GR solves are actually like, I've posted 9 example solves further up in this thread. I'm not "cherrypicking" these solves, they really are a list of all the 2GR solves that I've done so far. (Basically whenever I pull up a new cstimer scramble I plug it into alg.cubing.net and type up the solve. So in total I've only done 10 full 2GR solves.)

Including this last 10th solve, average movecount is 44.7 (σ = 6.05). Still lower than the expected 47, but I'm going to be a bit pessimistic and assume that I've just been getting lucky.
I guess as a method developer you have to be pessimistic. ^^ But even with barely sub50 moves it still looks nice, because RU = tps max. It's ergonomic and has no drawback in look-ahead. It's funny when I think about CFOP whose idea it is to be much less efficient and use rotations to be able to solve some parts of it 2-gen and spam tps there; here we get the same with less moves and no rotations.
But well, I know I'm in the hype mood, so it might turn out less awesome than it sounds.

#### Teoidus

##### Member
I guess as a method developer you have to be pessimistic. ^^ But even with barely sub50 moves it still looks nice, because RU = tps max. It's ergonomic and has no drawback in look-ahead. It's funny when I think about CFOP whose idea it is to be much less efficient and use rotations to be able to solve some parts of it 2-gen and spam tps there; here we get the same with less moves and no rotations.
But well, I know I'm in the hype mood, so it might turn out less awesome than it sounds.
Yeah, from my experimentation with the method I'm very excited, as it feels like sub-50 movecounts largely depend on how good you are at solving the <R,U> subgroup w/ blockbuilding or algset tricks (which is good since those are improvable with practice).

Though, I would still be quite happy with a ~50 move average. This is comparable to Lau's Roux average movecount and is already ~10 moves more efficient than Felik's CFOP avg movecount.

Most "method theory" seems to account for CFOP's success over (or equality with) more efficient methods like Roux and ZZ by claiming that there's a lower possible max tps compared to CFOP's qtm optimized 2-gen + simpler lookahead. If this method is feasible, it doesn't look to me like there will be this tps cap to counterbalance the advantage it has over CFOP in movecount...

So maybe I shouldn't be too pessimistic after all.

But of course this all assumes the inspection can actually be done. The first step is still in development but after a lot of EOPair practice it's starting to "click" for me, so I'm hoping it will eventually be feasible to quickly plan it out and begin tracing CP.

#### xyzzy

##### Member
So the idea is to use a single comm to solve one DF wing + solve one other wing on LL, then do the same with the second DF wing (so now the wings are solved and there are at most 6 unsolved wings on LL). Then permute the remaining wings in 1 look. (leading to a 3look system)
But if you use 3-cycle comms for the DF wings, you can't completely control where the two solved wings are, so if you take into account that the two solved wings can be in any of 28 positions, this makes the case count blow up.

#### Teoidus

##### Member
But if you use 3-cycle comms for the DF wings, you can't completely control where the two solved wings are, so if you take into account that the two solved wings can be in any of 28 positions, this makes the case count blow up.
Whoops, I did math wrong. True case count should be 1/4 * 8! / 2!, not 1/4 * 6! / 2!. So actually it's 56 * 90 = 5040.

gg to that idea then

#### Shiv3r

##### Member
Teoidus, could you please make a tutorial on 2-gen redux? the problem I have is that I cannot for the life of me plan CP in inspection, maybe I should check the tables again...

Last edited:

#### Shiv3r

##### Member
Teoidus, I had a thought. If you are doing the CP tracking with 7 corners, and since slice moves don't break CP, couldn't you just always start with the DLB corner "solved", and then determine your Key swap from that, and then after you do CPline of FB+CP or whatever it is, then you use slice moves to fix the centers? that means that there is no setup moves... You just rotate so that the DLB corner is at the DLB spot, then solve from there.

because I suck at things like EOline, and CP on top of that is really hard, this is what I think Im gonne use for right now:
1.solve DLB and DLF corners and solve CP, if possible solve the DL edge(CPline)
2.solve the rest of first block with slice moves(and fix centers)
3.Solve 2x2x3 like OBLBL-3 (AKA Pootris), by solving DF+DB and EO at the same time, use L5E/LSE EO to do this by setting up oriented edges to the R face and then doing MU EO.(like in my ooold rotationless petrus idea)
4.solve 2-gen F2L and LL.
It's pretty much Noah's CP blocks/your alternate method... I think that the fact that you can always have 1 corner "solved" means you only have to deal with 7

#### Zanaso

##### Member
Teoidus, I had a thought. If you are doing the CP tracking with 7 corners, and since slice moves don't break CP, couldn't you just always start with the DLB corner "solved", and then determine your Key swap from that, and then after you do CPline of FB+CP or whatever it is, then you use slice moves to fix the centers? that means that there is no setup moves... You just rotate so that the DLB corner is at the DLB spot, then solve from there.
This is exactly what he has switched to doing, actually. You can see this by looking at his example solves. They all start with rotating so that DLB is solved, then he solves EO + DL using <R,U,F,r,u,f>.

Teoidus, could you please make a tutorial on 2-gen redux? the problem I have is that I cannot for the life of me plan CP in inspection, maybe I should check the tables again...
Is it determining the key swap that you're having trouble with? If so, you can message me on the discord server and I can teach you how to do this. I don't think he's published the DLF inserts that fix the CP when you know the key swap, though.

#### Teoidus

##### Member
Teoidus, I had a thought. If you are doing the CP tracking with 7 corners, and since slice moves don't break CP, couldn't you just always start with the DLB corner "solved"
As zanaso said this is what I am doing in inspection (and also what I said in my post on 2GR a while back, the first step is to solve DLB in inspection)

Teoidus, could you please make a tutorial on 2-gen redux? the problem I have is that I cannot for the life of me plan CP in inspection, maybe I should check the tables again...
I've published all the information you need to figure out how to reduce, but it's definitely not friendly yet. I'll release more user-friendly stuff once I get more things fleshed out.

As of right now I am deriving the DLF inserts by hand based on the following 3 key swap changes:

If you do start using FB -> 2x2x3+EO, let me know how fast you can orient the edges and solve DFDB and if you can regularly get 9 stm.

Also, please stop calling it pootris. It's just not a good name.