The New Method / Substep / Concept Idea Thread

[shadowslice e]

ZZ has R/L regrips, Roux has R,r regrips. To avoid that, reduces to <R,U,D> and then <R,U> and then <M,U>. Nice and ergonomic and less algs than CMLL for LS CO, though CP recog still sucks

EOLine on Left (6-8 STM)

FB + CP (~7 STM)

SB + LS (~15 STM)

4b + 4c (5-11 STM)

33-41 STM

I would be very interested if you could find a way to do this but when i tried it (basically combining SSC and B2), I couldn't find a nice way to do step 1 followed by step 2 or vice versa and just decided that CO would be better than CP. I think the problem is that CP is best done when ignoring EO but doing EO interferes with CP so either way around is not very nice. It also doesn't help that CP is not exactly easy to recognise.

Also, if you're doing SB unless you influence the three edge pieces needed in it (which is hell all on its own), you'll most likely be using {R,U,M2,r2} which still means quite a few regrips and possibly more than with the other methods because you are doing more moves so I think that the method in the current form would actually have more regrips than quite a few existing methods.

Incidentally, due to my looking into it, I have a set of algs for step 3 around somewhere if you want them.

Good luck with the method though! I hope that you find a way around all these issues!

 

[Teoidus]

I would be very interested if you could find a way to do this but when i tried it (basically combining SSC and B2), I couldn't find a nice way to do step 1 followed by step 2 or vice versa and just decided that CO would be better than CP. I think the problem is that CP is best done when ignoring EO but doing EO interferes with CP so either way around is not very nice. It also doesn't help that CP is not exactly easy to recognise.

Also, if you're doing SB unless you influence the three edge pieces needed in it (which is hell all on its own), you'll most likely be using {R,U,M2,r2} which still means quite a few regrips and possibly more than with the other methods because you are doing more moves so I think that the method in the current form would actually have more regrips than quite a few existing methods.

Incidentally, due to my looking into it, I have a set of algs for step 3 around somewhere if you want them.

Good luck with the method though! I hope that you find a way around all these issues!

Good to know algs are generated already for step 3 I'm not the most enthusiastic about alg generation

I agree that CP recog just seems very annoying (and is what'll probably end up making me toss this idea). However I noticed that all zz-porky LS inserts are <R,U,L>, which means that the FB+CP+EO could be done essentially like the last pair of the left block in zz-porky. Instead of trying to solve a CE pair + CP with <R,U,L> you would solve last FB corner + CP with <R,U,D>. This gives me hope somewhat (as I hear that porky recog isn't as terrible after some while) so I'm looking into old porky docs to see if I can find something good.

Though also, influencing of SB edges should be fine, since just have to force them out of DF and DB in order to ensure <R,U> SB. Can be done in <= 2 STM (worst case being edges at DF+UB or UF+DB). This would make the whole solve essentially: whole cube group EOLine, <R,U,D> FB+CP, at most 1 M or R move, <R,U> SB+CLL, <M,U> 4b+4c.

What did you end up thinking of your CP recognition system for Briggs? Maybe I could use that (though seems like it was meant to be used during inspection when you have time to think)

looks interesting. what does LS stand for? can you write an example solve?

Last Slot - the idea being the last pair of SB would be solved along with the CLL, leaving 4b+4c.

I'll try and get an example solve up soon

 

[Teoidus]

Little example solve with the first scramble I got from cstimer:

y // red front master-race
r' U r B' r' F2 r // LOL (7/7)
U2 R U'D2 // 2x1 on D (4/11)
D' R U' R' D R2 D' // last corner + CP (7/18)
// reduce SB to <R,U> (0/18)
U R' U' R2 U2' R2' U R U2 R' U' R // SB (12/30)
U2 R U R' U R U2 R' // CLL, don't know algs yet (8/38)
U' M2' U M' U2 M' U M2 U2 // LSE (9/47)

I have no idea if that CP approach is optimal yet, (I'm basically finding them via trial and error right now) and I just went ahead and solved the CLL with a Sune since I don't have the algs yet. Already 47 STM though, so that's nice. I'll do one more

 

[Teoidus]

Okay, second example solve:

y
r' U R' D' x' U2D2 L' // LOL (7/7)
// 2x1 on D (0/7)
D R U' R' U R2 D // FB corner + CP (7/14)
r2 // Force <R,U> SB (1/15)
U R U R2 U2' R2' U R // SB (8/23)
U' M2 // force UL in nice position (2/25)
R U R' U R U2 R' // CMLL (7/32)
M2 U M2 U' M2 U2 M2 // LSE (7/39)

Once again, don't know if FB+CP or SB+CO are optimal (though SB was so nice here that SB+CLL might have been).
If we just wave away the CP recognition for now, the rest of the method looks promising.

 

[shadowslice e]

Stuff

Yeah the recognition system was designed for inspection and is completely unsuitable for using while actually solving (at least in my experience) so I would just start from scratch instead of trying to adapt it (though using 6 corners instead of 8 as that was one of the reasons why mine had to be complicated due to dealing with all 8 simultaneously)

 

[2180161]

Alright, someplace I haven't posted in forever!
I took a look at the method L2LK, and thought it was a cool idea. However, the amount of algs needed was extremely high (220?) So I have come with an approach to lessen the number, while still having the nice 2-gen L5E. It is kind of strange, has a few drawbacks, but I have been getting around 20 consistently, with little practice. It may also be considered more of a variant or LS method, but it is fairly move efficient.

1. F2L-1. Solve however you like. Place the empty slot at FR
2. EO+C Solving edge orientation while solving your FR slot corner (33 algs)
3. COLL Corners of last layer. Preserves EO. (42 algs) OR OCLL then CP (10 algs-but 2 look)
4. L5E (16 algs, 4 of which are EPLL. When solved 2 gen, avg moves is about 11)
Example solve:
Scramble: D2 U2 R' D2 L R2 B2 F2 U2 L' D2 F U2 B2 L2 R2 B' U' L2 U2
x y2 L F' R' D L' D2 L D'// cross
U L R' U R L2 U' L R U' R' L' U L U' L' U L// F2L-1
y2 U' F' U2 F R U2 R'// EO+C
U' L' U2 L' D' L U2 L' D L2 // COLL
R U' R' U' R U2 R' U R U R'//L5E
54 HTM, about the same as average CFOP, and I'm extremely inefficient (I mean, just look at my cross )

Spoiler: Pros

Same lookahead as CFOP
Last 3 steps are algs allowing for fast turning
2-gen "LL"

Spoiler: Cons

Large amount of algs (91)
Not the most efficient, kind of in the middle
Recognition for L5E isn't the greatest

 

[Teoidus]

Alright, someplace I haven't posted in forever!
1. F2L-1. Solve however you like. Place the empty slot at FR
2. EO+C Solving edge orientation while solving your FR slot corner (33 algs)
3. COLL Corners of last layer. Preserves EO. (42 algs) OR OCLL then CP (10 algs-but 2 look)
4. L5E (16 algs, 4 of which are EPLL. When solved 2 gen, avg moves is about 11)

So the tradeoff EO+C/COLL/EPLL vs Last Pair/OLL/PLL
Same number of looks
Alg count 86 vs CFOP 78
Move count likely slightly lower
Ergonomics probably better (COLL -> 2gen finish)
Chance of accidental ZBLL is 1/5 vs 1/8 (no edge control)

 

[Cale S]

Alright, someplace I haven't posted in forever!
I took a look at the method L2LK, and thought it was a cool idea. However, the amount of algs needed was extremely high (220?) So I have come with an approach to lessen the number, while still having the nice 2-gen L5E. It is kind of strange, has a few drawbacks, but I have been getting around 20 consistently, with little practice. It may also be considered more of a variant or LS method, but it is fairly move efficient.

1. F2L-1. Solve however you like. Place the empty slot at FR
2. EO+C Solving edge orientation while solving your FR slot corner (33 algs)
3. COLL Corners of last layer. Preserves EO. (42 algs) OR OCLL then CP (10 algs-but 2 look)
4. L5E (16 algs, 4 of which are EPLL. When solved 2 gen, avg moves is about 11)
Example solve:
Scramble: D2 U2 R' D2 L R2 B2 F2 U2 L' D2 F U2 B2 L2 R2 B' U' L2 U2
x y2 L F' R' D L' D2 L D'// cross
U L R' U R L2 U' L R U' R' L' U L U' L' U L// F2L-1
y2 U' F' U2 F R U2 R'// EO+C
U' L' U2 L' D' L U2 L' D L2 // COLL
R U' R' U' R U2 R' U R U R'//L5E
54 HTM, about the same as average CFOP, and I'm extremely inefficient (I mean, just look at my cross )

Spoiler: Pros

Same lookahead as CFOP
Last 3 steps are algs allowing for fast turning
2-gen "LL"

Spoiler: Cons

Large amount of algs (91)
Not the most efficient, kind of in the middle
Recognition for L5E isn't the greatest

I've thought of this before, I think it's only useful when you have the corner already placed or if you use ZZ

I made an alg list for the last step: http://bit.do/FRL5E

edit: ok I need to fix the algs again

 

[Jack T]

I've got a subset of sorts in mind which consists of completing a PLL which is on both the top and bottom faces of the cube (this would be accomplished by doing F2L but with wrong corners). I used a program called Cube Explorer (here's a link for download: http://kociemba.org/cube.htm) to generate 'scrambles' which would solve these. For example, having a J-Perm on the U face and an A-Perm on the D face (refer to image below, named the J + A Perm) COULD be solved in two different algorithms, but that would be 23 moves with an awkward rotation between. It could also be solved in one, relatively easy, 11 move algorithm; U R2 B2 U B2 U' R2 U' B2 U B2. Anyway, this "subset" of mine thus uses 63 unique algorithms (PLL on top layer and CPLL on bottom combined, being 21x3 algorithms). Combined with COLL too, you're left with 12 unique algs - 4 EPLL x 3 CPLL (while this is not taking into consideration the orientation of the permutations, you can easily adjust them using D and U moves, as you would do with normal PLL).
The images below show three examples of this "subset" (not using COLL), I hope you lot think this is worth more than a few short examples. If so, I'd like to elaborate on how this subset could/would be used.

J + A Perm: [U R2 B2 U B2 U' R2 U' B2 U B2]

(As mentioned, this would have been solved in 23 moves without this Alg. Now it's less than half at 11 moves.)

Double T Perm: [U R2 U2 B2 D' B2 R2 F2 L2 D' L2 U2 F2 D]

(I found that, alternatively, for the Double T, you could do [(x U2 M2 U2 x' l' R') (E-Perm) l2], which - despite having rotations - is still pretty fast, but also has a tonne of moves to it. This alg uses the same number of moves as the normal T Perm surprisingly, too, at 14 moves.)

Ga + E Perm: [U F2 R2 B2 L2 U' R2 D2 R2 U R2 U R2 B2 D R2]

(I added this one to show that even the most convoluted of permutations have short algorithms - the two seperate algorithms would total to 26 moves, and have some really awkward and confusing rotations to get that E Perm right. This uses nearly half that count at 16 (the same as the E Perm itself!), and uses no rotation at all. On the diagram, it might seem like recognition would be hell, but you can easily force certain CPLLs on the D face, and the U face PLLs would be exactly the same as usual.)

 

[xyzzy]

I've got a subset of sorts in mind which consists of completing a PLL which is on both the top and bottom faces of the cube (this would be accomplished by doing F2L but with wrong corners).

Interesting idea here (and welcome to the forum!). The algs for T+T and G+E you posted aren't very long, but they're still on the long side, and they involve loads of half turns and awkward regrips. All PBLs can be done with <R,U,D>, so maybe you can try generating algs restricted to those moves and see how good/bad/short/long/fingertricky/awkward the new algs are. Those cases with only CPLL on D can also be done <L,U,R>.

Don't forget about the parity cases either, like if you have a corner 2-cycle or 4-cycle on the D layer (e.g. this), which doubles the case count. You could avoid the parity cases while doing F2L, but that would severely limit the freedom in choosing which corner to pair with which edge, which kind of defeats the purpose. (You already have a decent amount of freedom in the first two pairs, where you don't have to care about parity, but for the third and fourth pairs, which are more restricted, you get two ways to form c/e pairs if you don't care about parity and only one if you do.)

On the flip side, if you can freely swap DFR and DBR during COLL, all the diagonal-swap COLL cases can now be done <R,U> 2-gen, which may or may not be useful.

Edit: It might also be useful to look at which PLL variants are in use nowadays:

• PLL itself is used by most serious cubers (except Roux users).
• COALL (PLL without oriented edges) has been proposed a few times and the alg count isn't too large, but most algs suck.
  
• ZZ-HW (PLL with FR unsolved) was proposed a few months ago, and then seemingly abandoned because the diagonal CP algs suck.
  
• TTLL/ZZ-CT was proposed soon after (PLL with DFR unsolved but oriented), and quite a few people are learning it or have already finished learning it.
• Full PBL hasn't really been considered because there're a lot of algs, and some of them suck.
• Edge PBL mostly sucks too (compared to doing EPLL twice), unless you're good at executing lots of S2 moves.
  
• There's a "parity" PLL too, where the D layer is a DF-DB swap and the U layer is oriented. A few nice algs like the parity EPLLs, but the rest are meh and it's usually better to just do the cross properly.

Edit #2: Some 2-gen diag/adj COLLs:

Spoiler

I took one of the first few 2-gen algs Cube Explorer generated, so these might not be the best for smooth execution. They're also all kinda long, but 2-gen!!!!

CO skip: R U R2 U R' U R2 U' R U' R2 U' R' = [R U R2 U R' U: R2]
T: R U2 R' U R' U' R2 U R U2 R U' R U' R2
U: R U2 R U' R' U R' U' R U' R U R2
L: R U2 R2 U2 R U' R2 U R U2 R' U R' U R'
S: R U R2 U R' U R2 U' R U' R U R U2 R' = alg for CO skip case cancelled into Sune
A: inverse/mirror of S
pi: R U' R2 U2 R2 U2 R U' R U2 R U' R2 (doesn't use R' or U)
H: R2 U' R2 U' R U R U2 R U' R U R2 U R'

 

[Jack T]

Interesting idea here (and welcome to the forum!). The algs for T+T and G+E you posted aren't very long, but they're still on the long side, and they involve loads of half turns and awkward regrips. All PBLs can be done with <R,U,D>, so maybe you can try generating algs restricted to those moves and see how good/bad/short/long/fingertricky/awkward the new algs are. Those cases with only CPLL on D can also be done <L,U,R>.

Yes, I actually realised the awkwardness with those two cases later that day, and was about to make an edit or a repost stating a way to make forcing an A-Perm on the D face a lot easier. Plus, I found that most (since I haven't actually gotten ALL of the algs finished yet) algs which have an A-perm on the D face, while still using moves which would be considered awkward, are actually more fingertrickable than expected. For example, a T-E case I have uses [U F2 D F2 L2 F2 L2 D2 L2 D R2 D B2 D’ R2 F2]. With some getting used to, this is actually kinda comfortable to perform, or at least that's what I've found. I've also found that with some cases, particularly those with B and R moves, a cube rotation DOES makes them easier to do (which is partly what I hoped to avoid). Also, with some algs, using wide moves helps ergonomics too (e.g, Aa-Aa - [U M2 U M2 F2 r2 U’ F2 U2 R2 U’ F2 r2].

Don't forget about the parity cases either, like if you have a corner 2-cycle or 4-cycle on the D layer (e.g. this), which doubles the case count. You could avoid the parity cases while doing F2L, but that would severely limit the freedom in choosing which corner to pair with which edge, which kind of defeats the purpose. (You already have a decent amount of freedom in the first two pairs, where you don't have to care about parity, but for the third and fourth pairs, which are more restricted, you get two ways to form c/e pairs if you don't care about parity and only one if you do.)

As for how to prevent parity-like cases, during F2L, you could look for corners which simply have the cross colour and one of the corresponding edge colours (e.g, rather than looking for a white-green-orange corner to match with the green-orange edge, you could find any corner which has either white and green OR white and orange, and it would be usable), and you would makes sure at least one pair (maybe the third, after the pairs with the most freedom) is wholly correct.

On the flip side, if you can freely swap DFR and DBR during COLL, all the diagonal-swap COLL cases can now be done <R,U> 2-gen, which may or may not be useful.

I am going to be honest, I don't know exactly what that means - I stated about COLL more hypothetically, since I don't actually know many cases at all for it.
From what I can guess though, that would certainly make COLL faster and easier, yes.

Thanks for taking a look at the concept, it's highly appreciated!

Edit: Algorithms could also be made on top for the parity-like cases, perhaps like altered versions of U face PLLs.

 

[DXPower]

What do you guys think of this?

It's a 5x5 edge pairing method I came up with a few weeks ago.
After posting here I've modified the method a bit. Instead of doing the 4th edge as a freeslice edge, you do it right after you complete the first edge pair. So you look at the bottom edge (bedge) in the FL slot, and put the corresponding center edge (cedge) into the FR slot, replacing the newly completed edge pair. If you do a d, you make a "bottom hat". You can then either use the newly created empty slot in BR to put in the top edge (tedge) and complete the full edge there, or take out the bottom hat by putting in the bedge for the next top hat in FL. If you do the former, you have to fix the top hats by undoing the slice move.

I'm still trying to reduce the number of bad cases when you first start out (bad cycles, basically). The entire method works off of forcing a 3 (4, with the new thing I came up with?) cycle with the edges.

There's a full thread here

 

[Shiv3r]

okay, so a decent Idea for a vandenbergh method spin-off for squan:
instead of simultaneously solving u and D corners and then solving U and D edges with waaay too many algorithms, perhaps solving the bottom corners while solving the top edges and then solving the top corners and bottom edges may make for better algs.
lemme check the alg count quick: 9 EPLL's*3 corner cases = 27 algs.
That is much less than normal CBL+EBL, I'm just not sure if the algs will be very move-efficient.
Also, orientation+cubeshape both layers may be a better Idea tbh

 

[Sion]

Here is a dumb corners first method I used to help me get familliar with the M slice. it is almost entirely intuitive, and a big beginners variant of roux:

1: Solve D corners and DL and DR edges
2: CLL
After this point the whole solve is 4 gen
Using L, R, U, and M, solve the equator edges.
After this, do a lse variant and done.

I'm hoping this could help people get used to usage of the M layer as a vital tool in speedsolving and intuitive solving.

 

[Shiv3r]

Here is a dumb corners first method I used to help me get familliar with the M slice. it is almost entirely intuitive, and a big beginners variant of roux:

1: Solve D corners and DL and DR edges
2: CLL
After this point the whole solve is 4 gen
Using L, R, U, and M, solve the equator edges.
After this, do a lse variant and done.

I'm hoping this could help people get used to usage of the M layer as a vital tool in speedsolving and intuitive solving.

This may be the thing we need to attract peope to Roux. A lot of people are trying to figure out how to get more newer people into Roux, this may be very useful.

 

[Sion]

This may be the thing we need to attract peope to Roux. A lot of people are trying to figure out how to get more newer people into Roux, this may be very useful.

Not sure how... can you explain a bit?

 

[Shiv3r]

Not sure how... can you explain a bit?

I have been telling that the roux community needs to come up with a way to have more beginners learn roux. I have believed that a corners-first style beginners method may be the answer, such as the one at rubikscube.info. This is also a good runner-up,your method, and I see how it would make a good beginner's corners first method.

 

[shadowslice e]

I have been telling that the roux community needs to come up with a way to have more beginners learn roux. I have believed that a corners-first style beginners method may be the answer, such as the one at rubikscube.info. This is also a good runner-up,your method, and I see how it would make a good beginner's corners first method.

I think the reason there are less roux solver than CFOP solvers is more down to the fact that when you type in "how to solve a rubik's cube" into youtube, the first hundred results are all CFOP related (I say this because i know (of) a fair few people (myself included) who actually learned roux reasonably easily without ever learning things such as F2L and stuff like that (I know of at leas one who still can't do F2L CFOP style even though his blockbuilding is actually pretty good))

 

[Shiv3r]

I think the reason there are less roux solver than CFOP solvers is more down to the fact that when you type in "how to solve a rubik's cube" into youtube, the first hundred results are all CFOP related (I say this because i know (of) a fair few people (myself included) who actually learned roux reasonably easily without ever learning things such as F2L and stuff like that (I know of at leas one who still can't do F2L CFOP style even though his blockbuilding is actually pretty good))

That's why creating a roux-style beginners method and making it something like that is important to create bigger diversity in the cubing world, which is a thing I think should happen. I want the percentage of people using CFOP to drop to around 60% from what it is not(95-98%)

 

[Teoidus]

I'm not sure there's an easy silver bullet to attract peopel to roux. There's just too much CFOP content