• Welcome to SpeedSolving.com — the world’s largest puzzle community!

    You’re currently browsing as a guest, which means you have limited access to discussions, resources, member profiles, and community features.

    Join 50,000+ cubers and puzzle enthusiasts from around the world to ask questions, share solves, improve faster, and be part of the community.

    Registration is free, fast, and easy — create your account today.

    Already a member? Log in here to hide this message and start participating.
Definitely. I'll do the math at some point, but that's >10 even without the 4 moves for making the pair.

Even so, the movecount remains low.

EoLine: 7
Left Block: 10 at most
Corner: 3 at most
WVCP: 15
L6E: 12

Total: 47 moves. Still pretty low :P

anyway, I said "This might work for something" as in for some cases.
 
Even so, the movecount remains low.

EoLine: 7
Left Block: 10 at most
Corner: 3 at most
WVCP: 15
L6E: 12

Total: 47 moves. Still pretty low :P

anyway, I said "This might work for something" as in for some cases.

Well, it's probably more like 50 since you still haven't factored in the pair building. Still low but not worth it for the alg count and recognition.
 
Well, it's probably more like 50 since you still haven't factored in the pair building. Still low but not worth it for the alg count and recognition.
It's actually even more, left block is at least 12 moves max, and EOline is 9, not 7. So max movecount should be at least 54.(Assuming you're number for L6E is correct.)
This might work for something:

EOLine - 7 moves
Left Block - 7 moves
Corner in DBR - 2 moves
WVCP: 10 moves
Modified L6E - 12 moves

Total: 38 moves

I don't mean to come across as rude, but did you do any research before coming up with these numbers? You got almost all of them wrong, and ended up at least 16 moves off..
 
Last edited:
I thought up of a method a couple weeks ago, here it is.

Step 1: 2x2x3 on DL without the FD edge. This can be done in 2 ways: 2x2x2 in DBL then insert the FLD+FL pair, or FB plus DB edge.
Estimated time for pro/intermediate user: 1.5s/3s

Step 2: EO. Just like petrus, except you can also use the M layer. Insert the FD edge during this step.
Estimated time for pro/intermediate user: 2s/4s

Step 3: 2-Gen F2L
Estimated time for pro/intermediate user: 2s/4s

Step 4: LL. You can use OCLL/PLL, COLL/EPLL, ZBLL, or you can do something like WV while solving F2L.
Estimated time for pro/intermediate user: 1.5s/3.5s

The average time for a pro user is 7 seconds.
The average time for an intermediate user is 14.5 seconds.

Pros:
-Lowish alg count (unless you use ZBLL)
-VERY flexible (2 ways to do the first step, and many ways to do EO)
-Good use of inspection (6 pieces vs 4 pieces in CFOP)
-EO in last layer

Cons:
-High movecount? (Not sure)
-EO

After writing this down, I realize that this is basically Petrus, with (in my opinion) a better EO step and slightly less pieces to solve during the last step.

I also realize that this is pretty similar to something like Noah's CP Block Method 2.0 method, or Briggs. I haven't seen a method like this though. I apologize if this method has been brought up already.

inb4 "Or you could use Petrus."
 
I thought up of a method a couple weeks ago, here it is.

Step 1: 2x2x3 on DL without the FD edge. This can be done in 2 ways: 2x2x2 in DBL then insert the FLD+FL pair, or FB plus DB edge.
Estimated time for pro/intermediate user: 1.5s/3s

Step 2: EO. Just like petrus, except you can also use the M layer. Insert the FD edge during this step.
Estimated time for pro/intermediate user: 2s/4s

Step 3: 2-Gen F2L
Estimated time for pro/intermediate user: 2s/4s

Step 4: LL. You can use OCLL/PLL, COLL/EPLL, ZBLL, or you can do something like WV while solving F2L.
Estimated time for pro/intermediate user: 1.5s/3.5s

The average time for a pro user is 7 seconds.
The average time for an intermediate user is 14.5 seconds.

Pros:
-Lowish alg count (unless you use ZBLL)
-VERY flexible (2 ways to do the first step, and many ways to do EO)
-Good use of inspection (6 pieces vs 4 pieces in CFOP)
-EO in last layer

Cons:
-High movecount? (Not sure)
-EO

After writing this down, I realize that this is basically Petrus, with (in my opinion) a better EO step and slightly less pieces to solve during the last step.

I also realize that this is pretty similar to something like Noah's CP Block Method 2.0 method, or Briggs. I haven't seen a method like this though. I apologize if this method has been brought up already.

inb4 "Or you could use Petrus."

This is a somewhat good idea, but I suggested something almost identical to this a while back. So yeah, it's a good method, low movecount, efficient, yada yada yada, but the lookahead isn't great and EO in the middle of a solve is slow.
 
This is a somewhat good idea, but I suggested something almost identical to this a while back. So yeah, it's a good method, low movecount, efficient, yada yada yada, but the lookahead isn't great and EO in the middle of a solve is slow.

Alright, I'm dropping credit for the method, sorry about that.

Look ahead could be decent, especially look ahead into F2L, since once you know where the flipped edges are, you can track the pieces you need. The only bad look ahead imo is for EO recognition, so I'll work on that.

The reason that EO in the middle of a solve is slow I think is because EO isn't directly solving pieces. In the method, I combine EO and inserting FD, however, I think that it's possible to solve way more than that during EO. I'll work on it.

This method has a lot of capability, and I will keep working on developing it. I will also try to speedsolve the method, and see how close I can get to my CFOP average time, 14-16 seconds.
 
Random method that is probably really inefficient

Step 1. Cross
Step 2. F2L, but without corners
Step 3. Oll on top and bottom sides
Step 4. Pll on top and bottom
Step 5. Some algs
Step 6. Done, but inefficiently
 
Step 1. Cross
Step 2. F2L, but without corners
Step 3. Oll on top and bottom sides
Step 4. Pll on top and bottom
Step 5. Some algs
Step 6. Done, but inefficiently
This one is like a belt/zagorec hybird neither of which is great in terms of alg count, recog or move count
^^
But what if:
Step 1: E edges + orient bottom edges on bottom
Step 2: oll + bottom OLL (7*57)
Step 3: obl orient both layers X algs
Step 4: permute both layers. 21*21 algs
Lots of algs

this is literally the belt method.
 
Alright, I'm dropping credit for the method, sorry about that.

Look ahead could be decent, especially look ahead into F2L, since once you know where the flipped edges are, you can track the pieces you need. The only bad look ahead imo is for EO recognition, so I'll work on that.

The reason that EO in the middle of a solve is slow I think is because EO isn't directly solving pieces. In the method, I combine EO and inserting FD, however, I think that it's possible to solve way more than that during EO. I'll work on it.

This method has a lot of capability, and I will keep working on developing it. I will also try to speedsolve the method, and see how close I can get to my CFOP average time, 14-16 seconds.

Don't worry about it. I've also created methods identical to other people's methods before. I once literally recreated Briggs without knowing it, so yeah.
 
So for 3x3, I've been thinking about methods that solve CP.

1. 1x2x3 in DL
2.CP
3.<R,U,u,E> 2x2x3
4. EO without disturbing CP
5.<R,U> F2L
6.2GLL
Example solve:
Scramble:U' B2 L2 D2 R F2 L B2 F2 L2 B2 F2 D' L B R D F' U' L F2
x' y
L2 D' R2 L' U2 L D' B2 D2//FB
U2 R U2 L' U R U' L//CP
U' u' R' u R u R2 u'//2x2x3
R U' R U' R' U2 y M' U M y'//EO
U' R U' R U2 R2 U' R2 U' R U R' U2 R//F2L
U2 R' U2 R2 U2 R2 U' R2 U' R2 U R U//2GLL
You can see it on alg.cubing.net here.
I'm sure someone can do it more efficiently than I can, but that is all I have for now.
 
Last edited:
So for 3x3, I've been thinking about methods that solve CP.

1. 1x2x3 in DL
2.CP
3.<R,U,u,E> 2x2x3
4. EO without disturbing CP
5.<R,U> F2L
6.2GLL
Example solve:
Scramble:U' B2 L2 D2 R F2 L B2 F2 L2 B2 F2 D' L B R D F' U' L F2
x' y
L2 D' R2 L' U2 L D' B2 D2//FB
U2 R U2 L' U R U' L//CP
U' u' R' u R u R2 u'//2x2x3
R U' R U' R' U2 y M' U M y'//EO
U' R U' R U2 R2 U' R2 U' R U R' U2 R//F2L
U2 R' U2 R2 U2 R2 U' R2 U' R2 U R U//2GLL
You can see it on alg.cubing.net here.
I'm sure someone can do it more efficiently than I can, but that is all I have for now.

This is Briggs but EO is worse.
 
So for 3x3, I've been thinking about methods that solve CP.

1. 1x2x3 in DL
2.CP
3.<R,U,u,E> 2x2x3
4. EO without disturbing CP
5.<R,U> F2L
6.2GLL
Example solve:
Scramble:U' B2 L2 D2 R F2 L B2 F2 L2 B2 F2 D' L B R D F' U' L F2
x' y
L2 D' R2 L' U2 L D' B2 D2//FB
U2 R U2 L' U R U' L//CP
U' u' R' u R u R2 u'//2x2x3
R U' R U' R' U2 y M' U M y'//EO
U' R U' R U2 R2 U' R2 U' R U R' U2 R//F2L
U2 R' U2 R2 U2 R2 U' R2 U' R2 U R U//2GLL
You can see it on alg.cubing.net here.
I'm sure someone can do it more efficiently than I can, but that is all I have for now.

This is Briggs but EO is worse.

Actually it's more like NCPB2.0 cause you don't combine CP and FB
 
Hey guys. I was using PCMS the other day and came up with an idea to make it better:

Steps:

1. Build the pairs but without worrying about permutation of any pieces. Edge orientation may matter depending on how many algs you want to use.
Exec. time: 2-3 seconds
2. Orient U layer corners using one of 7 algs.
Exec. time: 1 second
3. Permute the columns.
Exec. time: 2-3 seconds
4. Solve the last 8 edges. My strategy for this is to solve 2 or 3 edges of the first layer with the centers followed by the last FL edge. At this point, you'll be left with ELL, which consists of 29 algs. You could also orient the LL edges while solving the last FL edge, which would leave EPLL.
Exec. time: 4-6 seconds

Total time: ~11 seconds, give or take

I'm guessing, if you're colour neutral, you could plan at least 3 pairs in inspection, and from what I've seen, the odds you already have 2 pairs solved are quite high, so one could plan the pairs step in inspection.

The disadvantage to this method is the mildly high-ish alg count. PBL has six cases, so combined with the edges, that's 6*(8 distinguished cases) = 48 algs, or 30 if you don't count mirrors. However, if you solve edge orientation of the pairs, that number drops to 12 algs. If you were willing to do a z2 or an x2 in the middle of the solve, the original number would drop to 40 algs, and without mirrors that's 25 algs and 10 algs if you orient the pair edges. I doubt 48 algs is unreasonable to most. Another disadvantage is the move set for the last 8 edges. <MSU> isn't that great, hence my time estimate for the last step. I'm guessing it would take a pro at least 4 seconds to solve the last step (PLEASE PROVE ME WRONG!).

So I think this *might* have some potential. I'll check it out, but I noticed that if I'm colour neutral, I usually get at least two pair solved. This means I can usually one-look the pairs. Recog wouldn't be that bad some the columns step because you basically recognise the PBL case then you recognize the edge case (diag swap, adj swap or solved + EO)

Tell me what you think. I'll post some example solves later to clear up any confusion.
 
This is a sort of Roux variant that solves a lot of stuff using algs. Be warned, this is an alg heavy method.

1. Build a Roux block
Moves: 8
Execution time: 2-3 seconds


2. Place the RD edge
Moves: 3
Execution time: 0.5 seconds


3. Build pairs without minding their placement within the two remaining slots nor the permutation of the edge and corner (all that matters
is CO and EO)
Moves: 8 (~4 per "pair")
Execution time: 0.5-1 second per pair


4. Orient the top layer corners
Moves: 7
Execution time: 0.5-1 second


5. Permute the corners and edges of the "pairs" as well as the top layer corners and orient all edges

Cases:
Top layer corners have 3 cases (diag swap, adj swap, solved)
Bottom layer corners have two cases (swap or solved)
The edge orientation has 12 cases (I won't name them all)
The pair edge permutation has 2 cases (swap or solved)
Knowing this, here is the number of cases:
Corners: 3*2 = 6 - 1 (two cases are technically mirrors)
Edges: 2*12 = 24
Total: 5*24 = 120 - 1 (solved) = 119 cases

Moves: From what I've seen so far, ~11
Execution time: 1-2 seconds


6. L6E with pre-oriented edges
Moves: 9
Execution time: 1-3 seconds

Total moves: 46 STM
Execution time: 6-10 seconds

Pros:
- Great lookahead compared to normal Roux due to permutation not being an issue for the SB
- EO is solved when going into L6E
- Low movecount
- Low theoretical execution time
- Pretty easy recognition for the alg-heavy step
- Algs are faster than intuition

Cons:
- High alg count
- Moves used during pair-building get used during alg execution, so this isn't saving many moves
- Blockbuilding (if you're a CFOP user like me)

Thoughts please.
 
Thoughts please.
It seems like you're making the method more complicated than it needs to be for no reason, you're going to great lengths to avoid doing second block and eo normally. Steps 4+5 are inferior to cmll, so the entire thing depends on your pseudo second block being better than a normal block, and I just don't think that's the case.

Place the RD edge
I do not like this meme.
 
Roux variant

1. Build a 1x2x3 block.
2. Build another block in the other side like in Roux.
3. Insert a white edge ( if you aren't colour neutral) between the blocks, if you haven't done it during blockbuilding
4.orient and permute corners
5. Algs to orient and permute last 2/4(plus oriented edge on last layer of it is not permitted) edges ( Not sure how many algs))
6.Solved
Thoughts?
 
Last edited:
Back
Top