• 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.
It really depends on the alg set in my experience. The main problem I have with ZZ is all the L moves which force regrips. It could be good but I find that the EoLine does too little and can often impede lookahead.
I would be hesitant to say that ZZ combines the best aspects of Roux and ZZ because Roux benefits as it has very unrestricted free block building. It also has a harder F2L than CFOP. Instead of saying that it combines them I would say it walks a middle path on which it can't fully benefit from either aspect (not to say it couldn't be good but it isn't as straight forward as "it combines the best of Roux/CFOP".

I would be very cautious in saying that more variants makes a method better. While you could make an argument that more variants=more areas to improve though at the same time a lot of the variants contradict each other so you can only use a handful at a time.

LS techniques consist a far larger array than simply phasing (though phasing can be an ok technique when transitioning to ZBLL). ZZ-CT is also not very good at all. In fact, I think the general consensus is that it is worse than COLL/EPLL (the misconception is mostly due to the fact that Chris Tran is very good at marketing- incidentally I would consider most of what he says suspect until I get proof of the things he says, also, CT predates his proposal by a fair bit).


Personally I think that this is probably the way to go. Incidentally you might want to have a look at
this thread I posted on how current methods seem to fall into 2 camps in general and why some have more variants than others

You might find a few more recent methods fairly interesting and see the variations that modern cubing has begun to cover (and a lot of them don't actually end in LL or use LBL) I would give Leor, SSC, PCMS, 2GR, M-CELL, ZB, 42 and LMCF a quite glance and maybe try to evaluate why they are good or perhaps not quite as viable.

I also made a thread which compiles quite a few different resources which method developers might want to take a look at. Harcs and cube explorer are also good for quick evaluation of basic methods.

Anyway, I hope this doesn't induce wall of text syndrome too much and I wish you all the best in your future explorations! :)

Thanks, I might look at all those methods tomorrow. But thanks for giving such big answer that covers all questions I would have asked :D

I am excited to see what we can come up with and how long it will take, that the speedcubing majority switches from CFOP if an other method seems to be better and what method it will be. And when?

I guess it will take long to see a big change but probably there will happen something in like 5 years.

Btw the main reason why I am so interested in this topic is because I want the „best“ method or the „most efficient“ one so I dont have to learn new algs when a better method comes out xD (I am really lazy lol). I even stopped learning PLL xD (I already know 10 or so).

But yeah, thanks for your answer, seems like there are even more „good“ methods than I have exspected.
 
new method (bfce)

1) 2x2x2 block
build a 2x2x2 block in DBL

2) F2l-1+P
solve the 3 pairs and place two of them in F2l along with DF and DR while the third pair goes in the top layer
not nessisarily in that order

3) copls
(corners orientate and permute last slot)
solve all the corners with the placement of the last slot with an algorithm (1/324)(you already have the pair)

4) ell
solve the final 4 edges with an algorithm (1/29)
 
I am excited to see what we can come up with and how long it will take, that the speedcubing majority switches from CFOP if an other method seems to be better and what method it will be. And when?
I guess it will take long to see a big change but probably there will happen something in like 5 years.

No matter what method we (or anyone else) finds, it is extremely unlikely that any majority of cubers would ever switch from CFOP. Personally I don't believe CFOP is the future, but we cannot argue that it is extremely fast, and the high movecount is offset by the extremely fast LL algorithms. Any new method would offer only a marginal improvement in speed potential at the expense of YEARS of re-learning (in all likelihood). For that reason, if some new 'grand' method was found, it would be new cubers that would most likely learn it. In that sense it could take a whole cubing 'generation' for the CFOPers to 'retire' and be replaced by people who never knew CFOP in the first place. The best example is Kian Mansour, the fastest Roux solver to date, who never even learned CFOP and started with Roux based on the accomplishments of the previous best Roux solver, Alex Lau.
 
My idea for a 'corners first' method:

1) Solve corners like a 2x2 (Ortega, CLL, EG etc.). Does not have to be relative to centers.
2) solve all center-edges (should create 4 bars of three that aren't perpendicular to each other). Can be done intuitively.
3) solve two opposite bottom edges. this should create 2 'U' shapes on opposite sides. (can be done intuitively)
4) Orient all of the edges using 'M' and 'U' moves. [EO]
5) Solve the last bottom 2 edges using 'M' and 'U' moves. [B2E]
6) Use M-perms, U-perms, and Z-perms to solve the top 4 edges [L4E]
7) solve centers using 'M' moves (minimum of 4 moves)

Tell me what you think
 
This looks like a variation on SSC where you don't orient edges. Kind of a more primitive form of a good method.
 
My idea for a 'corners first' method:

1) Solve corners like a 2x2 (Ortega, CLL, EG etc.). Does not have to be relative to centers.
2) solve all center-edges (should create 4 bars of three that aren't perpendicular to each other). Can be done intuitively.
3) solve two opposite bottom edges. this should create 2 'U' shapes on opposite sides. (can be done intuitively)
4) Orient all of the edges using 'M' and 'U' moves. [EO]
5) Solve the last bottom 2 edges using 'M' and 'U' moves. [B2E]
6) Use M-perms, U-perms, and Z-perms to solve the top 4 edges [L4E]
7) solve centers using 'M' moves (minimum of 4 moves)

Tell me what you think
Tons of problems here. The first one is that solving E-slice edges after corners is terribly inefficient. Much better to start in the style of PCMS. Second problem here is that you're not solving the L/R centers with DL/DR, making recognition very difficult later and also forcing the solve to end in a silly center commutator. Third problem, you've broken down the LSE step from Roux into EO -> DF/DB -> EPLL. Which is bad. The classic Roux method of EO -> ULUR -> L4E is much better, and even better if you expand it to EOLR -> L4E. Last problem is that you're ending in a center commutator which is silly.
 
Tymon Kolasiński
Tons of problems here. The first one is that solving E-slice edges after corners is terribly inefficient. Much better to start in the style of PCMS. Second problem here is that you're not solving the L/R centers with DL/DR, making recognition very difficult later and also forcing the solve to end in a silly center commutator. Third problem, you've broken down the LSE step from Roux into EO -> DF/DB -> EPLL. Which is bad. The classic Roux method of EO -> ULUR -> L4E is much better, and even better if you expand it to EOLR -> L4E. Last problem is that you're ending in a center commutator which is silly.
I know it is very inefficient and similar to roux. but not all methods have to be efficient.
 
Tymon Kolasiński

I know it is very inefficient and similar to roux. but not all methods have to be efficient.
What Arc is saying is that doing corners then E-slice is not only inefficient, but much slower then solving the four F2L pairs before doing CLL. Then, the best way to do L8E would be just to insert 2 D-layer edges to reduce it into LSE like in Roux, but at that point you're just doing Roux with slower and less efficient blocks.
 
My idea for a 'corners first' method:

1) Solve corners like a 2x2 (Ortega, CLL, EG etc.). Does not have to be relative to centers.
2) solve all center-edges (should create 4 bars of three that aren't perpendicular to each other). Can be done intuitively.
3) solve two opposite bottom edges. this should create 2 'U' shapes on opposite sides. (can be done intuitively)
4) Orient all of the edges using 'M' and 'U' moves. [EO]
5) Solve the last bottom 2 edges using 'M' and 'U' moves. [B2E]
6) Use M-perms, U-perms, and Z-perms to solve the top 4 edges [L4E]
7) solve centers using 'M' moves (minimum of 4 moves)

Tell me what you think

Since Waterman isn't really a corners first method (it solves one slice minus one edge before the remaining corners), then LMCF is probably the only 'current' corners first method that truly starts with the corners. I think more thought should be placed into how to best solve the edges after solving the corners. Having said that, I don't think what you propose is an improvement, but that it is not to discourage you from coming up with something else, more ingenious. In particular what is needed is a method in line with Waterman's advanced variation where you try to solve 1-2 edges at the same time as solving the corners, by either using different CLL variants for each case or by injecting M/M' moves into the CLL algorithms (which is what Waterman would do, and what tyrannical caterpillar does). If you can come up with a good way to do that, it would be huge.
 
VLS + TTLL = ZZCT for CFOP
I was just messing around and this was kinda cool. It might be pretty move efficient.

Steps
1. Cross
2. F2L - 1*
3.VLS**
4.TTLL

* The last f2l edge must be orientated and paired with a corner where the U color is facing towards you.

** The the unpaired f2l corner will help identify what VLS case you have. VLS cases are identified by the edge orientation and corner orientation.
 
Last edited:
In a lot of cases TTLL has a better average move count and they the cases are generally pretty fast. They also are 2 gen or 3 gen. I also just thought that this method is just interesting.
 
TTLL alternate?
So maybe you like ZZ and TSLE but you don't want to learn the extra 72 algs, I don't know, but here's another way to solve TTLL that's probably slower and less efficient but with less algs:
1) Use an EPLL to make a solved 1x2x2 block in UBL
2) L4C (11 algs? I'm not sure)
The cool thing about this L4C is that you don't have to worry about the UF and UR edges because they'll have to solve themselves since 2 edges can't be swapped.
 
The cool thing about this L4C is that you don't have to worry about the UF and UR edges because they'll have to solve themselves since 2 edges can't be swapped.
while this is true, you can get odd Parity for both Edges and Corners which evens itself out. Also, how do you solve the Bottom Layer Corner with L4C?
 
I think @JTay proposed and developed something of that sort.
Yes, developed it earlier this year. It's the Ribbon Method. Check it out on the wiki. I've developed every single alg myself over the last few months. In short, solve an addition edge during cross in the E Slice, finish the three pairs, orient the last 9 pieces with TOLS, then permute those 9 with TTLL.
 
while this is true, you can get odd Parity for both Edges and Corners which evens itself out. Also, how do you solve the Bottom Layer Corner with L4C?
You would probably just use an alg or commutator to solve the four corners.
 
What Arc is saying is that doing corners then E-slice is not only inefficient, but much slower then solving the four F2L pairs before doing CLL. Then, the best way to do L8E would be just to insert 2 D-layer edges to reduce it into LSE like in Roux, but at that point you're just doing Roux with slower and less efficient blocks.

*faster and more efficient* , but ok

idk y yall h8 on pcms for no reason. try it

Yaknow, I feel that a lot of people don't form their own educated opinions because they are not naturally curious enough.

Everyone hates L4C, for example. Why? Because whoever put algs on the wiki put the optimal ones from some obscure orientation. THESE ARE ZBLLs PEOPLE. THERE ARE GOOD ALGS FOR THOSE CASES; THOSE JUST AREN'T IT. Because of this misconception, everyone immediately throws out any method idea that ends in L4C.

Everyone hates PCMS. Why? Because the name includes "S", suggesting 1/4 of this method is awkward S moves. You can do d/y moves to convert S to M. The average CFOPper does 10 TRILLION rotations per solve. Why is just 1 off-limits? Because of this misconception, everyone immediately throws out any idea that passes through a columns state.

Everyone hates CP-variants like CPLS. Why? Because some 9-yr old, somewhere in a thread last necro'd 100 years before Christ, said it was hard to detect corner permutation, and scarcely anyone has tried it since. Because of this, people throw out decent variants like CPLS, which are phenomenally efficient in their alg/movecounts, compared to other methods.

I think we need a reformation. An Ultron-esque clean slate. A great purge.

</rant>
 
Last edited:
*faster and more efficient* , but ok

idk y yall h8 on pcms for no reason. try it

Yaknow, I feel that a lot of people don't form their own educated opinions because they are not naturally curious enough.

Everyone hates L4C, for example. Why? Because whoever put algs on the wiki put the optimal ones from some obscure orientation. THESE ARE ZBLLs PEOPLE. THERE ARE GOOD ALGS FOR THOSE CASES; THOSE JUST AREN'T IT. Because of this misconception, everyone immediately throws out any method idea that ends in L4C.

Everyone hates PCMS. Why? Because the name includes "S", suggesting 1/4 of this method is awkward S moves. You can do d/y moves to convert S to M. The average CFOPper does 10 TRILLION rotations per solve. Why is just 1 off-limits? Because of this misconception, everyone immediately throws out any idea that passes through a columns state.

Everyone hates CP-variants like CPLS. Why? Because some 9-yr old, somewhere in a thread last necro'd 100 years before Christ, said it was hard to detect corner permutation, and scarcely anyone has tried it since. Because of this, people throw out decent variants like CPLS, which are phenomenally efficient in their alg/movecounts, compared to other methods.

I think we need a reformation. An Ultron-esque clean slate. A great purge.

</rant>
Wow, you are really passionate about this :D
Idk really, I just heard someone say that about PCMS a while back and it made sense. As a method, it is fun :D
 
Back
Top