# The New Method / Substep / Concept Idea Thread

#### Sion

##### Member
Here's an example solve:

Scramble: D2 R2 F2 U2 F2 D' B2 D' F2 D' R2 B' F U' B2 L' U' L' F' R2 D

First Corners: F2 D2 L' y2 D2 (R' D R D')3

COLL: x2 U' L' U' L U' L' U2 L

CPLL: U R' F R' B2 R F' R' B2 R2

DLDR:U2 M U2 M' R' U M' U2 M U R y

First Belt Edge: U M U' R' U M' U'

Second Belt Edge: R2 U' M' U r'

Third Belt Edge: M' L' U' M2 U L

Fourth Belt Edge: M' L U M U' L'

DFDB: M U' M2 U M' U' M U

EOLL R U R' U' M' U R U' r'

(EPLL Skip)

#### Teoidus

##### Member
o wait guys zz-porky v2 is neat and all but like

all we need is a way to reduce corner permutation to the set solvable wholly <L,U> and then wholly <R,U> in inspection and we'll have an actual missing link filler

we know that a permutation of 8 corners can be expressed in terms of a key swap + position of BLD sticker. once forcing all the left block pieces into L and U, this key swap + BLD can be converted into a swap of two pieces both on <L,U>. The left block is solved <L,U> so the identity of the pieces that need to be swapped won't change (since permutation fix invariant under <L,U>)

#### Sue Doenim

##### Member
I've been looking for a way to better the roux method, and I have tried doing corner permutation while finishing the second block, with an LS mindset. If this is done, OLLCP can be done with only 57 algorithms (as opposed to 331) and mostly R, r, U, and M moves. This also brings up a question: why is CPLS done like CLS, instead of with the full F2L pair? I've generated the full-pair cases, and they are not bad.

#### Teoidus

##### Member
Hm, might be that it's more moves to make the pair and so on average you get better movecounts out of insert edge + CLS vs make pair + insert pair & CLS

#### Metallic Silver

##### Member
I thought about FreeRoux. FreeRoux is pretty intense. 0 _ 0

#### Teoidus

##### Member
Free roux also goes by simultaneous or non-linear blocks i think. can get you some really nice movecounts

#### Teoidus

##### Member
Like a pinky pie with psuedo2gen algs only:
CPFB (10)
SBsq (7)
LE + ULUR/UFUB on D (~6?)
LC + CO + EO (12?)
L6E (8)
= 43 STM avg

Thoughts? Better ways to finish L12P (LS + CO + L6E)?

#### Sue Doenim

##### Member
I know Old Pochmann, and I was looking into learning M2/R2. However, I was kind of disappointed with so many x rotations. I then began thinking about possibly using M moves instead of M2, so you can put it in place oriented without requiring rotations. Is this possible? I haven't thought of a way to make it work, but maybe someone else could. If so, It could be a much faster method.

#### Teoidus

##### Member
Unfortunately not, you'll still have cases where when setting up to the buffer, you either need to use F/B moves or an x rotation. What's more is that you'll actually have to alternate between using M and M' to solve pieces

What you could do is consider setting up pieces into UF instead of into UB. This would let you use F moves in your setups (for example things like F R F')

#### xyzzy

##### Member
all we need is a way to reduce corner permutation to the set solvable wholly <L,U> and then wholly <R,U> in inspection and we'll have an actual missing link filler
Textbook group theory result says that there are 3600 (out of 8!=40320) corner permutations that can be solved like that, so setting up the corners to one of these ⟨R,U⟩ ⟨L,U⟩ states probably takes 1-3 moves on average. The hard parts are (i) how to recognise if we're in this set of states and (ii) how to get there. And once we're in this set, we no longer have to track anything! If we solve the left block using only L and U moves, we'll automatically be reduced to 2-gen.

Unfortunately this gets messier once we take the edges into account. We have to do EO and get the LD/LF/LB edges out of the R layer, which probably takes around 5 moves, and we have to track CP throughout that. (Or if we leave the M slice free, we don't have to do EO, which might be better?)

The left block is solved <L,U> so the identity of the pieces that need to be swapped won't change (since permutation fix invariant under <L,U>)
I don't think this works. Just because it's invariant under ⟨R,U⟩ doesn't mean it has to be invariant under every 2-gen subgroup.

Let's say the scramble is just F2 M2 F M2 F2 M2 F M2 (for simplicity). Then the key swap is URF-UBR, and if we solve the left block using U L2 U' L2 U' L2 U2 L2, assuming invariance, the key swap becomes DLF-ULB. But how can the key swap involve a piece in the left block that's already solved?

#### Teoidus

##### Member
Unfortunately this gets messier once we take the edges into account. We have to do EO and get the LD/LF/LB edges out of the R layer, which probably takes around 5 moves, and we have to track CP throughout that. (Or if we leave the M slice free, we don't have to do EO, which might be better?)
Yeah, this was one of my biggest issues with the idea. Forcing left block every time alone takes some extra moves (it's more like 2-3 on average but I don't like it since it means we'd have to track every left block edge during EOLine to fully plan CP in inspection). Perhaps the best way to go about it would be to force left block while placing the corners into one of those states, but then the current method I have of detecting CP breaks down.

I don't think this works. Just because it's invariant under ⟨R,U⟩ doesn't mean it has to be invariant under every 2-gen subgroup.
This should work, though it's likely I'm not being very clear. Since any 6-corner permutation can be reduced by a single swap on U, and since any 2gen scrambling <L,U> won't change the permutation of the U layer corners wrt each other when DLF and DLB are once again solved <L,U>, any permutation of the 8 corners in which DLF and DLB are solvable <L,U> has a single swap that makes all 8 corners solvable by <L,U> and then <R,U>. This swap will be invariant under <L,U> in the sense that the same pieces (not necessarily the same positions) will need be swapped after <L,U> to solve DLF and DLB (since the only possible permutation the <L,U> business could've done given that DLF and DLB have been solved once more and that <L,U> is 2-gen group is something in <U> which of course doesn't do anything to CP wrt <R,U>)

So we take the key swap we get from tracking after we've forced left block <L,U>, and we convert it into a single swap on <L,U> that doesn't involve the DLF or DLB pieces. This swap doesn't change after solving the left block, so if we swap now then corners are solvable by <L,U> and then <R,U>, but if we solve left block <L,U> now and then swap the same pieces later (when they are on the U layer) the rest is still solvable <R,U>.

This isn't as good as the same positions need be swapped, but looking for identity of two pieces is still much better than looking at the relation between 4 i.e. Porky v2.

Last edited:

#### xyzzy

##### Member
Since any 6-corner permutation can be reduced by a single swap on U, and since any 2gen scrambling <L,U> won't change the permutation of the U layer corners wrt each other when DLF and DLB are once again solved <L,U>, any permutation of the 8 corners in which DLF and DLB are solvable <L,U> has a single swap that makes all 8 corners solvable by <L,U> and then <R,U>.
Oh! This makes a lot more sense than what I was thinking of. Yeah, this should work. I'm still not sure if there's a good way to determine the swap during inspection, though. I just tried doing a solve on an <L,U,R> scramble, and even with the EOline already done, it still took me minutes to determine the key swap. (But I'm also really bad at tracking pieces during inspection in general, bleh.)

// insp: key swap is white-red-green with yellow-red-blue
U' L' U R U2 L' U2 L2 U2 L U L' U' L // left block
L' U R2 U' L // diagonal swap
R2 U2 R2 U2 R2 U' R' U' R U // F2L on left
U' R2 U R U' R U // antisune lol

Made one R move while forming the left block, but that doesn't affect the CP state since the yellow-orange corners were on the L face and permuted relative to each other at that point. What I did for the CP recognition was to mentally solve DLF and DBL (ignoring orientation), then trace cycles to determine the swap for <R,U>; it seems like this could be reasonably fast with loads of practice.

#### Teoidus

##### Member
What I did for the CP recognition was to mentally solve DLF and DBL (ignoring orientation), then trace cycles to determine the swap for <R,U>; it seems like this could be reasonably fast with loads of practice.
Hmm. I wonder if you could mentally "solve" DLF and DBL but do so with swaps, then begin tracing with a swap that's needed to "correct for" the swaps needed to solve DLF/DBL (essentially given two swaps to solve DLF and DBL, the third swap will make the resulting permutation reachable <L,U>). Would make things logistically a bit easier; basically whenever hit DLF or DBL just trace it as if it were the piece that's currently at DLF or DBL (which simulates the swap)

Overall though I'd agree with you that this looks very complex. It would, if practiced, essentially fulfill the "missing link" of ZZ, but I'm not sure if it's worth it because there are so many moves required to force <L,U> left block and then correct CP when time comes.

I think it's still worth looking into a more general way to find and track these sorts of swaps though. If there could be a way to easily keep track of the swap while solving ZZF2L as normal (i.e. alternating between RU and LU), then reducing CP to 2gen with the first pair to complete a 1x2x3 block (either left or right is fine). Would basically be like ZZ-d except you don't have to solve left block first and no recognition step disrupting the flow of the F2L.

#### Think It's Impossible?

##### Member
To reduce the algorithm count of pinky pie (full OLLCP), why not solve UL UR on bottom before you insert the last pair of SB, then orient the top layer edges while inserting the last pair of SB (ZBLS), solve the COLL then insert UL UR and do 4C?

I see two possible ways of reaching the net result of EO plus UL UR on bottom. The first (and to me the most plausible) way to approach this is solving UL UR on bottom after building the back square, then solve the last pair like CFOP and do ZBLS.

You could also solve the last pair of SB then place UL UR although so far I have not found a consistent way of doing this.

I don't see any big problem, of course there are some last pair EO cases that suck or you may get a bad CFOP pair (only a problem with the first way).

Any thoughts?

#### Teoidus

##### Member
Pinkie Pie really is only viable if you learn the full OLLCP sadly. The extra moves needed if you use EOLS + ULUR on bottom + COLL ends up being less efficient than normal Roux

#### TDM

##### Member
To reduce the algorithm count of pinky pie (full OLLCP), why not solve UL UR on bottom before you insert the last pair of SB, then orient the top layer edges while inserting the last pair of SB (ZBLS), solve the COLL then insert UL UR and do 4C?

I see two possible ways of reaching the net result of EO plus UL UR on bottom. The first (and to me the most plausible) way to approach this is solving UL UR on bottom after building the back square, then solve the last pair like CFOP and do ZBLS.

You could also solve the last pair of SB then place UL UR although so far I have not found a consistent way of doing this.

I don't see any big problem, of course there are some last pair EO cases that suck or you may get a bad CFOP pair (only a problem with the first way).

Any thoughts?
Not worth it. If you're doing that you might as well insert them at the start of the solve - and then do F2B like CFOP F2L. But of course this is then just a less efficient version of ZB.
Pinkie Pie isn't supposed to be used in every solve, only where it's convenient to do so.

Also ZBLS+COLL is more algs than OLLCP, so you're not reducing the required number of algorithms. I also think that, in general, COLLs are also slower than the average OLLCP.

#### MethodNeutral

##### Member
I've been learning COLL in an attempt to convince myself I don't need to switch to CFOP/Fridrich (I use ZZ) and I decided to look into ELL... It turns out it's only 25 algs. So, consider a LL method with COLL/CLL first (42 algs) then ELL to finish up. It's a total of 67 algs for a 2LLL, compared to CFOP's 78. It isn't much of an improvement, but I haven't seen it mentioned anywhere. Is there an obvious flaw I'm missing?

#### obelisk477

##### Member
I've been learning COLL in an attempt to convince myself I don't need to switch to CFOP/Fridrich (I use ZZ) and I decided to look into ELL... It turns out it's only 25 algs. So, consider a LL method with COLL/CLL first (42 algs) then ELL to finish up. It's a total of 67 algs for a 2LLL, compared to CFOP's 78. It isn't much of an improvement, but I haven't seen it mentioned anywhere. Is there an obvious flaw I'm missing?
What you're missing is that this has been a method almost since the dawn of speedcubing.

https://www.speedsolving.com/wiki/index.php/CFCE

EDIT: Also, there's 29, not 25. Looks like you're not counting EPLL, which is another 4

#### GenTheThief

##### Member
Is there an obvious flaw I'm missing?
As obelisk kindly pointed out, yes, it has been invented before.

One reason that CLL/ELL it isn't a main-stream method is the recognition.
OLL/PLL recognition is fairly easy, and COLL recognition is also easy. However, ELL recognition, by our current systems, is not.

It isn't much of an improvement, but I haven't seen it mentioned anywhere.
I'm not sure where you have looked, but it is a very old method that would be practically anywhere.
Please check the wiki or use the search bar before posting, anything really. The forum is >10 years old, and lots of methods have been proposed.

#### MethodNeutral

##### Member
What you're missing is that this has been a method almost since the dawn of speedcubing.

https://www.speedsolving.com/wiki/index.php/CFCE

EDIT: Also, there's 29, not 25. Looks like you're not counting EPLL, which is another 4
Thank you very much, I've seen CFCE listed under methods but never taken the time to look into it. Also, I'm new to the forums, so if I have a question about a method (NMLL), where would I put it? I don't even know what it stands for because all of the entries I've found on it are very short.

One reason that CLL/ELL it isn't a main-stream method is the recognition.
OLL/PLL recognition is fairly easy, and COLL recognition is also easy. However, ELL recognition, by our current systems, is not.

I'm not sure where you have looked, but it is a very old method that would be practically anywhere.
Please check the wiki or use the search bar before posting, anything really. The forum is >10 years old, and lots of methods have been proposed.
Thank you for your insight into why it isn't popular.
I couldn't find it because I wasn't sure what to search for, but I'll make sure I check next time.