The New Method / Substep / Concept Idea Thread

[Thermex]

@efattah interesting... this method is pretty much the same thing but solves L6C in a more efficient way. I have a ton of trouble with the blocks as I myself can barely lookahead through a 1×2×3, but I'll probably get used to it after a lot of practice. Do you have any knowledge on the most efficient way to solve L8E? I have a feeling you could use an LMCF finish but I've always been a bit confused how you do the edges during E2L/L6E.

A crazy solve I just got with this method:

(Hand scramble)
FS: y z U2 r U2 r' (4/4)
SS: z' y' F' L' F' (3/7)
OSC: y U' F' U' F (4/11)
PSC: R2 x U R' D2 R U' R' D2 (8/19)
FLFR: y M2 U (2/21)
LSE: x' M U2 M U2 M U' M' U' M2 U M2 U (12/33)

Despite the unnecessary amount of rotations, I got a 14.98, which is pretty good for me especially considering I had like a 2-3 TPS and don't even have the algs genned for this method I was able to cancel one move of the A perm during PSC to set up the F face to insert the FLFR edges, which was pretty cool.

 

[crafto22]

@Thermex I'd love to look into BOPE with you, it seems amazing! So how exactly does L6C work? How many algs?

 

[crafto22]

Just got a 10.58 with your method, @Thermex ! I've done around 2 or 3 hours of practice with it so far and am averaging around the same as I do with Roux (13-15 seconds).

 

[Thermex]

@crafto22 Dang that's awesome! I'll start a private conversation with you, Neuro, Spencer131, me, and anyone else who wants to join where I include the link to the LSC doc. To solve LSC you need to a). Orient the corners, and b.) Permute them.

 

[TDM]

This is an old method from a year ago, but only yesterday did I do some solves to get an idea of the movecount and it's actually better than expected. I did an Ao50 last night and got 34.3x moves after CPFB (attempting to use speedsolve solutions). Obviously this would have been more efficient than speedsolves no matter how much I tried to do things normally, but it's certainly around 35 moves after CPFB, and assuming CPFB is around 12 moves* this gives an average of 47 moves, which is nothing special, but certainly worth considering. The algorithm count is 105, or ~165 with EOLR, or 210-270 including mirrors, but they're incredibly easy algorithms to mirror since they're 2-gen and the mirroring is front/back.

* Teoidus was getting a little less than 12 moves with a fixed block, so take away a little bit assuming you'd have some amount of CN, and then add on a bit to make up for inefficiencies in speedsolves, and it's about 12. I don't know how to do CPFB yet so I'm using his movecounts.

Steps:

1. CPFB (12 moves/0 algorithms)
2. SB Square (9 moves/0 algorithms)
3. Solve corners, and insert edge with <U, M> at some point during the algorithm (12 moves/210 algorithms, or 105 with fixed square location/if you mirror the algs)
4. LSE (14 moves/60ish algorithms if using algorithmic EOLR)

Alternatively, step 3 can be solving the corners only, and then step 4 could be L7E split into (i) FR+EO (or BR+EO) and (ii) EP. However I'm expecting this to be even less efficient. Step (i) would be algorithmic.

It's certainly not a groundbreaking method by any means, but now I realise that the movecount isn't sup-50, I thought it was at least worth sharing.

E: Forgot to include an example solve. Here's the first scramble from qqTimer:
U L2 D L2 U2 F2 U' B2 F2 R2 U2 R U2 F2 D F R' B' L2 D L'

z2 R' U R' U R F' R2 U R2 B' // CPFB (10/10)
r U R U' R U2 R' U' R // SSquare (9/19)
U' R U R' U2 R U R' U M' U2 R U R' // Corners+FR (14/33)
U M U' M' U2 M U2 M U' M' U2 M U2 // LSE (13/46)
View on alg.cubing.net.

 

[Neuro]

This is an old method from a year ago, but only yesterday did I do some solves to get an idea of the movecount and it's actually better than expected. I did an Ao50 last night and got 34.3x moves after CPFB (attempting to use speedsolve solutions). Obviously this would have been more efficient than speedsolves no matter how much I tried to do things normally, but it's certainly around 35 moves after CPFB, and assuming CPFB is around 12 moves* this gives an average of 47 moves, which is nothing special, but certainly worth considering. The algorithm count is 105, or ~165 with EOLR, or 210-270 including mirrors, but they're incredibly easy algorithms to mirror since they're 2-gen and the mirroring is front/back.

* Teoidus was getting a little less than 12 moves with a fixed block, so take away a little bit assuming you'd have some amount of CN, and then add on a bit to make up for inefficiencies in speedsolves, and it's about 12. I don't know how to do CPFB yet so I'm using his movecounts.

Steps:

1. CPFB (12 moves/0 algorithms)
2. SB Square (9 moves/0 algorithms)
3. Solve corners, and insert edge with <U, M> at some point during the algorithm (12 moves/210 algorithms, or 105 with fixed square location/if you mirror the algs)
4. LSE (14 moves/60ish algorithms if using algorithmic EOLR)

Alternatively, step 3 can be solving the corners only, and then step 4 could be L7E split into (i) FR+EO (or BR+EO) and (ii) EP. However I'm expecting this to be even less efficient. Step (i) would be algorithmic.

It's certainly not a groundbreaking method by any means, but now I realise that the movecount isn't sup-50, I thought it was at least worth sharing.

This is very similar to a method that I made a few months ago called 2GRoux. It used a 3 step CPFB and requires 57 algs

1: CPFB
1a: Pair- done the same way as in 2GR but no worries on EO
1b: Line- insert last corner while solving CP
1c: FB- solve FB using <RrUuME>
2: SB+PP- solve second block and do Pinkie Pie setup
3: OLL(CP)- solve OLL, can be <RrUM>
4: LSE- very efficient because of Pinkie Pie

I seem to remember this achieving mid-40 movecounts. CPFB probably can't be planned in inspection, but you could plan line and view step 2 as F2B+PP. My biggest issue with the method was transitioning from line to solving FB as well as not having full pseudo 2G OLL, but it is still the favorite of the 3x3 methods I have made this far

 

[TDM]

This is very similar to a method that I made a few months ago called 2GRoux. It used a 3 step CPFB and requires 57 algs

1: CPFB
1a: Pair- done the same way as in 2GR but no worries on EO
1b: Line- insert last corner while solving CP
1c: FB- solve FB using <RrUuME>
2: SB+PP- solve second block and do Pinkie Pie setup
3: OLL(CP)- solve OLL, can be <RrUM>
4: LSE- very efficient because of Pinkie Pie

I seem to remember this achieving mid-40 movecounts. CPFB probably can't be planned in inspection, but you could plan line and view step 2 as F2B+PP. My biggest issue with the method was transitioning from line to solving FB as well as not having full pseudo 2G OLL, but it is still the favorite of the 3x3 methods I have made this far

I remember this being proposed. Sadly this method (I think) gives little-to-no advantage over regular Pinkie Pie for 2H because many of the 2-gen or pseudo 2-gen OLLCPs are relatively inefficient. In fact for regular CMLL, the 2-gen U and T cases are two of the worst ones. It may have potential for OH though, where anything pseudo 2-gen is very fast.

 

[Hazel]

Here's a 3x3 idea:
Step 1: 2x2x2 block in DBL along with solving FL and RB edges
Step 2: use keyhole to insert DLU and DRB corners, then solve last CE pair
Step 3: COLL
Step 4: EO
Step 5: EP (probably 2 looks so there aren't way too many algs)

Example: B' D L2 R2 U L2 U R2 U' R2 F2 U' B D2 U B D' R U2 F2 D'

2x2x2+FL/RB: x2 U F R U' F2 R U' R L // (9/9)
Keyhole: (D U2) R U R' D2 U' R U R' U R U' R' D // (15/24)
last CE pair: U2 F' U2 F r U r' // (7/31)
COLL: F U R U' R' U R U2 R' U' R U R' F' // (14/45)
EO: U R U R' U' M' U R U' r' // (10/55)
L3E: y' U' R U R' U' R' U' R' U R U2 // (11/66)

 

[Thermex]

@TDM I'm confused, are you talking about BOPE or something else? I don't recall any recent posts involving solving a CPFB...

 

[TDM]

@TDM I'm confused, are you talking about BOPE or something else? I don't recall any recent posts involving solving a CPFB...

I should have been more clear: that was the first time I've posted about this method. I didn't think it was worth posting before. This is a "new" (new to most people) method.

 

[Neuro]

I remember this being proposed. Sadly this method (I think) gives little-to-no advantage over regular Pinkie Pie for 2H because many of the 2-gen or pseudo 2-gen OLLCPs are relatively inefficient. In fact for regular CMLL, the 2-gen U and T cases are two of the worst ones. It may have potential for OH though, where anything pseudo 2-gen is very fast.

Thanks for the feedback! While I do like the method and think it has some potential, I realized most of these things already, hence why I didn't do very much with it. Maybe we can get together and make a CP Roux variation that has some potential?

CPFB in my style also gives ~12 move solutions pretty easily and I believe that it's a lot easier than planning full FB and tracking CP with it.

What may have some amount of potential is L5C or TCMLL (basically what you proposed). It's also quite easy to break into 2GLL. Other than that, maybe so COLE (Corner Orientation Lase Edge), EODFDB, and TTLL. Throwing ideas around, maybe something will stick

EDIT: Oh and if you want to go completely ham; do CPFB, F2L, and Pseudo 2G 1LLL. 600+ algs. I would not reccomend this to anyone besides someone who wants to rival Jabari

 

[Hazel]

I also just came up with a weird Petrus-style method that is actually not too bad:
Step 1: solve 2x2x3 block
Step 2: solve last 2 CE pairs
Step 3: Insert last First Layer edge while solving EO (14 super easy M/U algs)
Step 4: ZBLL or COLL/EPLL

I just got a 19.53 Ao12 with it containing an 11.60-second single!

Example: L' D F2 B' R' D' B R' D2 L' U2 L2 F2 U' B2 U2 F2 L2 U2 R2 U'

z2 U2 D R' D L F U2 R B' R' // 2x2x3 (10/10)
U R U R' U' L' U L U' F U F' // F2L (12/22)
M' U M U2 M' U M U M' U2 M // LE+EO (one of the worst 2 cases) (11/33)
R U R' U2 R U' R' U2 R U' R2 F' R U R U' R' F U' // ZBLL (19/52)

Yeah I know 52 moves is a lot, but just ZBLL took up 19 of them so otherwise, it's pretty efficient.

 

[Thermex]

@Aerma This is a great idea! Other than BOPE and maybe LMCF this is the closest I've seen a method get to being sub-40 moves. Here are my movecount estimates:

1. 2×2×3 (12 at best)
2. Pairs (~10 moves)
3. EODR (8 moves)
4. ZBLL (12 moves)

<45 moves with AUFS, probably around 42-43. Pretty ergonomic too, I'd be kinda surprised if this hasn't been proposed before.

 

[shadowslice e]

@Aerma This is a great idea! Other than BOPE and maybe LMCF this is the closest I've seen a method get to being sub-40 moves. Here are my movecount estimates:

1. 2×2×3 (12 at best)
2. Pairs (~10 moves)
3. EODR (8 moves)
4. ZBLL (12 moves)

<45 moves with AUFS, probably around 42-43. Pretty ergonomic too, I'd be kinda surprised if this hasn't been proposed before.

Clearly you haven't read M-CELL which covers quite a few methods such as this.

 

[Hazel]

@Aerma This is a great idea! Other than BOPE and maybe LMCF this is the closest I've seen a method get to being sub-40 moves. Here are my movecount estimates:

1. 2×2×3 (12 at best)
2. Pairs (~10 moves)
3. EODR (8 moves)
4. ZBLL (12 moves)

<45 moves with AUFS, probably around 42-43. Pretty ergonomic too, I'd be kinda surprised if this hasn't been proposed before.

Thanks! Probably the first concept I've come up with that isn't a total flop. I'll add a link to my original post to the EODF algs.

 

[Hazel]

(sorry for the double post)
@shadowslice e, I'm not sure I understand what M-CELL is, I read the post on it but from what I understand it seems different. Could you explain how it relates to my proposal please?

 

[Neuro]

WaterRoux, LMCF, LLOB with ZBLL, and ZZ with ZBLL all have movecounts that low.

I am positive this method has been proposed before or at least some variation of it.

I do think it has potential, just fact check before you post. You can force this to solve in HK as well, would have less algs. It can be quite flexible if used correctly

 

[sqAree]

Is there a document about BOPE or somewhere to read / learn, cause it's getting confusing to scroll through the last few pages of this thread.

 

[Hazel]

WaterRoux, LMCF, LLOB with ZBLL, and ZZ with ZBLL all have movecounts that low.

I am positive this method has been proposed before or at least some variation of it.

I do think it has potential, just fact check before you post. You can force this to solve in HK as well, would have less algs. It can be quite flexible if used correctly

A little while back I proposed a very similar method but it was more CFOP-like than Petrus, and was much less efficient than this. Maybe that's what you're thinking of?

 

[shadowslice e]

(sorry for the double post)
@shadowslice e, I'm not sure I understand what M-CELL is, I read the post on it but from what I understand it seems different. Could you explain how it relates to my proposal please?

M-CELL describes the set of methods which leave an edge (and a corner) out of the F2L when solving then solve them either during LL or just before to give easier cases. There's a whole set of variants with lots of different things in them.

This is one variant for petrus;
1) 2x2x3
2) form one pair+insert(+orient?)
3) 2nd pair
Then the edge would be inserted (and permuted perhaps) then whatever's left is solved with an alg (such as ZBLL).

It can also produce extremely low movecount solves.