• 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.
Also, I've been thinking about a way to do the 2x2 method you were talking about. Could it be like ZZ for 2x2, but with CPBar instead of EOLine? I would definitely learn this. CPBar would be a butt to master, though. EDIT: Would this be an example solve?
BRASS

I was actually trying this just an hour or so ago using ZZ-porky v2 for CP. It's great for 2x2 since the setup is so minimal compared to 3x3 (you can often skip it, or maybe do 1-2 moves) - but recognition is a pain. Finding a decent side to start on takes me 15 seconds :p I only started learning ZZ-d two days ago though so I'm still not very good at it. I'm sure it could be better with practise.
 
So wayyy back in 07 i learned the rubiks cube "7 step solution" and i thought hm there has got to be a faster method for placing the corner edge pairs in f2l. so rather than doing research i developed my own method. turns out its basically edge first keyhole (cross 3 edges last f2l pair hopefully forcing a yellow cross) with this method and up to 6 look last layer i got a sub 30 avg. 22.98 pb, I switched 2 months to full cfop and (1pll 2oll) but i think edge first keyhole paired with oll and pll is a fantastic method for begginer- intermediates who dont want to figure out each f2l case.

my method used triggers RUR' and the lefty mirror, i held white on left side

nothing super new but yeah :)
 
Okay, so some of the TOLL- algorithms are still from the old algorithm set, and most of the EPBLs aren't generated, but here you go. All of the OLLs and TOLL+ algs are <R, U> 2-gen, but some affect bottom layer permutation to produce a better algorithm (one alg swaps the DRF and DRB corners, but is 4 moves shorter (and much more fingertrick-friendly) than the alg for that case that preserves bottom layer permutation).
 
Okay, so some of the TOLL- algorithms are still from the old algorithm set, and most of the EPBLs aren't generated, but here you go. All of the OLLs and TOLL+ algs are <R, U> 2-gen, but some affect bottom layer permutation to produce a better algorithm (one alg swaps the DRF and DRB corners, but is 4 moves shorter (and much more fingertrick-friendly) than the alg for that case that preserves bottom layer permutation).
Perfect, thanks!
 
I was also thinking of this: What would happen if we combined the second and third steps of Twisty Ortega? We'd get the Twisty Erik-Gunnar method, or TEG. Would it be practical? Probably not.

There would be 15 subsets with 42 algorithms each (minus CLL which has 41 algs).
CLL (41)
TCLL+/- (84)
EG-1 (42)
TEG-1A+/- (84)
TEG-1B+/- (84)
TEG-1C+/- (84)
TEG-1D+/- (84)
EG-2 (42)
TEG-2+/- (84)
This would mean that you would have to recognize from 629 different cases (over 130 more than ZBLL), solvable by a minimum of about 220 algorithms.

Bleh, example solves (this method is for the lulz)
Solve using TCLL+
Solve using TEG-1A+
Solve using TEG-1D-

This is a method I dream of learning, but simply way too many algorithms (I haven't even learned full CLL yet). ZBLL's 490+ cases are solvable by a minimum of "only" about 140 algorithms.
 
3x3 method

1. F2L-2 edges

2. CLL

3. LSE ( a more algorithmic approach)

Example solve:

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

x2 y' L2 D' L' U' R' U' F L F L' B' R B R U2 R' R' U' R U R' U' R

U' R U R' U R U L' U R' U' L

U2 R' U2 R2 F R' F' B U B' R2 U2 R

Now, I dont have any good algs for this, other than well, CLL, so I just used cube explorer for the LSE stage.
 
3x3 method

1. F2L-2 edges

2. CLL

3. LSE ( a more algorithmic approach)

Example solve:

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

x2 y' L2 D' L' U' R' U' F L F L' B' R B R U2 R' R' U' R U R' U' R

U' R U R' U R U L' U R' U' L

U2 R' U2 R2 F R' F' B U B' R2 U2 R

Now, I dont have any good algs for this, other than well, CLL, so I just used cube explorer for the LSE stage.

Sounds kinda like the Roux-CFOP Hybrid method. I use that whenever I solve Roux (I suck at blockbuilding).
 
twisty stuff

I'm sure as soon as the concept of TCLL was thought of, this was also thought of.
The main problem is sheer number of algorithms.
Last night (bit coincidental) I was thinking about this, too.
I think another big problem with this is the stress involved during inspection. Imagine looking at a 2x2 and seeing an easy EG-1 face, or an easy TEG-2- face, or a TEG-1C+ case, and having to decide which to do, all under 15 seconds. The problem with knowing this many methods is making the choice of what to do in any given situation.
Speaking realistically, I think TEG-2 is perfectly do-able, considering it's just as many cases as TCLL.
TEG-1 is just too much, though if you were to learn it, you'd be (theoretically) better off, because EG-1 faces are more common than CLL and EG-2 cases combined.
iirc, if you're building faces efficiently, the chances of an EG-1 case is 4/6, and CLL and EG-2 are both 1/6 each.
has anyone analyzed the chances of a TCLL, TEG-1, or TEG-2 face if building efficiently? I would think it would be the same as their regular counterparts, but I can't be sure
sorry if that post was unorganized :)
 
Another one

EOCross

F2L however the corners do not have to be in the correct permutation

OCLL

PBL


I dont know if this has been thought of, or if the number of algorithms is just too much. Seems cool to me though
 
Another one

EOCross

F2L however the corners do not have to be in the correct permutation

OCLL

PBL


I dont know if this has been thought of, or if the number of algorithms is just too much. Seems cool to me though
Why not EOLine? Also you'll have to do either rotating or some awkward moves for PBL, so I don't think it would be very fast.

There would be 12*22 = 264 cases, 263 excluding solved.
 
Another one

EOCross

F2L however the corners do not have to be in the correct permutation

OCLL

PBL


I dont know if this has been thought of, or if the number of algorithms is just too much. Seems cool to me though

I think that PBL is too many algorithms!! :p I hate algorithms!! its probably awkward also! But you don't need ANY algorithms if you do it this way:

https://www.speedsolving.com/forum/showthread.php?50964-ZZ-Edges-First-discussion

did I mention I hate algorithms??

-Lyn
 
Another one

EOCross

F2L however the corners do not have to be in the correct permutation

OCLL

PBL


I dont know if this has been thought of, or if the number of algorithms is just too much. Seems cool to me though

What about (if you really like EOCross):

EOCross.
F2L minus CP.
OCLLEP (Orient corners and permute edges in one algorithm). This is about 8*11=88 algorithms.
PBL. This is quite a few algorithms, but not as much as before. Too lazy to calculate.

The PBL won't be as many algs as before, but with the addition as OCLLEP instead of OCLL, the number of algs may still be too high for practicality.


On another note, what about Ortega for 3x3?

Solve a side
Solve the E-slice edges
OLL
PBL

PBL would only have 7743 cases! Not too much, right? And if we allow AUF/ADF, it reduces to only 484 cases!

EDIT: Maybe the ZZ/Ortega Hybrid-ish method would look like this?

EDIT TO THE EDIT: I love this thread because I get to make example solves for methods that I've never seen before
 
Last edited:
One way to do CFOP, for a guaranteed x-cross :)

two 1x2x2 blocks opposite each other, with two extra edges solved.

EO (M,U)

Solve x-cross,

COLL

EPLL

Example solve: here

seems interesting but isn't the solving two extra edges a little move wasteful? you insert those edges, then you have to solve the corners, might as well do them at the same time but that would be roux or some type of free fop.
 
The reason I say to insert the edges is because when you solve your corners, you can easily recognize the OLL, so you could just do OLL then PLL, but COLL would be more efficient. I also realize that almost all methods now are made to be efficient. But just because it is not efficient doesn't mean it cant be good. also, I just got a 15.894 single doing this, and my PB overall is actually 11.405 (my signature is a liar)
 
Last edited:
So regarding my post on my columns first method that I posted a week or two ago, I recently updated that post to contain this alg (r' d l2 d' R) by ryan heise to help with the corner orientation (it twists the ufl and dfr corners) which should help to reduce the move count below 60 (which was what I had my solves usually coming to).
 
Last edited:
What about a 1LLL with ZBLL style, but using Winter/Summer variation instead of VHLS/ZBLS? The number of LL algs would be <=150 as opposed to almost 500 ZBLLs. I know this idea has been thought of before, but I haven't seen much discussion on it. I would also think that recognizing CP+ELL would be much faster than EP+CLL.
 
What about a 1LLL with ZBLL style, but using Winter/Summer variation instead of VHLS/ZBLS? The number of LL algs would be <=150 as opposed to almost 500 ZBLLs. I know this idea has been thought of before, but I haven't seen much discussion on it. I would also think that recognizing CP+ELL would be much faster than EP+CLL.

That's been done a lot of times before. I actually have bad algs generated for all of the cases (well, good algs for a couple). Recog is much easier, it's a bit harder than PLL.

Also, the number of algs is actually >150. Sorry.
 
Back
Top