Remember, though, I based this off a method from Kenneth that did just that - he used CLL for the corners and then did L5EO/L5EP. I added some more little optimizations in the intuitive steps but I do think that making it more Fridrichy was an improvement, even if it was moving a little away from the 'theme' of the method. Kinda like how the blocks in Roux are a huge improvement over that CF method where you solve ledge+redge pairs.Originally Posted by Athefre
PCMS seems good.
Roux is a perfect example of how trying to crowbar PLL into a method isn't always a good idea.
I looked at a bunch of methods before, and saw this one as one similar to Roux, like Corners First.
I'm no Roux expert (I don't use it), but I think Roux is definitely better.
Some D edges in Roux can be eliminated during inspection, making look ahead much easier, and then only 2 D edges will remain unsolved the rest of the time, but you see them while doing M turns anyway.
In columns first, after making the columns, not only is it harder to look ahead during the 4 pairs because of D edges, you'll have to return to the D layer after making the columns. Plus, it seems to take a little more thinking since it has so many steps.
And with CFOP, D edges are all completed during F2L, and OLL and PLL have extremely fast easy recognition and execution.
Overall, CFOP is just less intuitive, and what's great about that is the only improvised part (the cross) is thought up during inspection.
I love how you're all focusing on the order of steps and other silly things that hardly make a difference when the real problem is the movegroups being used.
As I said, movegroup is awkward especially for EO where its MSU. <M,S>isn't too bad tho, perhaps it'd not be a silly idea to do centres last or something?
Also order of steps and the steps themselves DO make a huge difference...
Last edited by 5BLD; 07-06-2012 at 06:11 AM.
I'd be impressed if you could find an order of steps to negate the movegroup problems. The order of steps are in no way the biggest issue here.
Look at ZZRoux or FridrichRoux - there are quadrillions of step configurations that all basically amount to the same quality of system.
Oh of course it's not the biggest issue. Nor does it 'hardly make any difference'. Don't get me wrong, all I'm saying is it does make a significant difference.
As for thinking up a way to reorder, I can probably think of a different example where it does matter. Just here the move group is quite a big problem and is awkward no matter where you put it. Or why not just not do it...? We could do something else maybe that's easier...
Edit: why not build 1x1x3 blocks then CLL then solve remaining columns? I find that faster and I did that in my 20sub20 vid. This is an example of re ordering which may be helpful
Last edited by 5BLD; 07-06-2012 at 06:43 AM.
I don't see how it can make a significant different when the true bottleneck is <U,M,S(,D)>. Any (sensible) changes will be tiny compared to the change made by avoiding this movegroup.
Regardless of its practicality, I would like to see someone dedicate a couple years with it and see how far they get.
Posting Permissions
Reply With Quote
Bookmarks