CriticalCubing
Member
LLOB is a method whose aim is to provide an alternative way to finish L10P that allows for higher max TPS and lower movecount. It gives the solver the flexibility to turn fast and spam TPS during ZBLL, while still being efficient for the Block building/F2L part of the solve. It’s also for people who don’t want to use traditional Roux (CMLL + LSE). It has lower move count than CFOP, is more efficient than CFOP, rotationless and efficient than ZZ-a EOF2L. You get the same result as CFOP F2L while being more efficient and turning slower, while ending with ZBLL and allowing good prediction ability for ZBLL. Your solve, for the most parts, is pauseless.
LLOB Document: http://bit.ly/llobmethod
8.41 ao5 with OLL/PLL for LL instead of ZBLL, as I don't know ZBLL yet. You can be sub 8 with this method and even sub 7.
LLOB Document: http://bit.ly/llobmethod
The approach we propose is EO+DFDB + ZBLL for LL. The aim was to provide an alternative way to finish L10P that allows for higher max TPS and lower movecount in exchange for a very large alg count. Yes, sure, it might sound very similar to something people propose on a weekly basis, but in this case, the details matter and are what make this something other than a regular roux-cfop hybrid post.
Let's look at the 3 L10P methods
CMLL + LSE
This is standard for Roux. Avg movecount: 10 CMLL (computed from avg of all the algs in my cmll sheet + 0.25 AUF) + 13 LSE (assuming 8 EOLR/EOFB and 5 4c, essentially the most advanced LSE there is) = 23 STM total
DF+DB, OLL, PLL
This is what beginners propose all the time. Avg movecount: 6 DFDB (I just got 10 random state LSE scrambles from cstimer and solved DFDB) + 10 OLL (from here + 0.25 AUF) + 13 PLL (from avging algdb.net algs + 0.5 AUFs) = 29 STM total
DF+DB+EO, ZBLL
This is what we are proposing. Avg movecount: ~8 DF+DB+EO (again, got 10 random state LSE scrambles and solved) + 15 ZBLL (optimal movecount for ZBLL is 12.08, so I'm overestimating generously for the sake of argument. For comparison, optimal PLL movecount is 11.5 and avg movecount for speedoptimized PLL algorithms on algdb.net is ~12.8) = 23 STM total
Note that our proposed L10P finish, on average, would take as many moves as CMLL + very advanced LSE (which often entails learning additional CMLLs to influence EOLR cases). So yes, the "only" difference between this and what a beginner proposes is that EO is done with insertion of DF/DB edges, and we use ZBLL instead of OLL/PLL, but it's clear that this difference is crucial. In this case, this method is as efficient as world-class L10P and so the standard objection to "roux-cfop hybrid" posts (namely, inefficiency) that prevents them from taking off does not stand; hence the indicator that "it looks like other methods that have been shot down before" shouldn't come into play here.
Now there are two further objections that I think can be raised at this point:
1) It may be just as efficient as vanilla roux, but why do this silly stuff? It disrupts flow; CMLL/LSE is a cleaner approach.
2) If you're going to learn FULL ZBLL, why not learn the method that was meant to be used with it, ZZ?
And my responses:
Objection 1) I'm going to assume the crux of this objection is not that EO+DFDB just "feels unclean" or "unnatural," as these are rather subjective points; instead I'm assuming the main point is that there seems no reason to go to such lengths if you can get as much bang for only 42 algs' buck. My response to this is that there is indeed a small advantage to this approach over standard CMLL/LSE: specifically, flow can be much better with EODFDB/ZBLL. There are two advantages I see:
(i) Very good prediction. During SB, it is very easy to track DFDB edges + D center, so there should be no pause between SB and EODFDB. During EODFDB, it is very easy to recognize CP (because corners are just being AUFed back and forth), and imo possible to predict the position of two edges; hence, there should be no pause between EODFDB and ZBLL. Currently, Kian believes the main bottleneck of a Roux solve is the often frustratingly long pause to recognize CMLL (the rest of his solves are pretty much pauseless). By performing this recognition during the execution of EODFDB, we can eliminate this pause, leading even more fluid solves.
(ii) Higher tps. In CMLL/LSE, 10 moves are drilled algorithmic face turns and 13 are MU spam; in EODFDB/ZBLL, 8 moves are MU spam and 15 are drilled algorithmic face turns. I think it is safe to say that face turns can achieve a higher max tps than MU spam (Lau's 0.6 Uperm suggests 11.6 stps, while... well, I believe there's a 20TPS T perm somewhere out there?), so even if EODFDB/ZBLL may achieve the same movecount as CMLL/LSE, it has the potential to be faster.
Objection 2) Well, this is an interesting one. ZBLL was invented for ZB, and then used in ZZ, and now we are trying to say it can be used in this Roux-hybrid thing as well. So now let's compare ZZ-a and EODFDB/ZBLL: both finish with ZBLL, so we'll just compare EOF2L movecounts:
ZZ-a: 6 EOLine + 25 F2L (stepwise optimal, taken from ss forums post) = 31 STM EOF2L
EODFDB/ZBLL: 7 FB + 15 SB + 8 EODFDB = 30 STM EOF2L
Importantly, I have way more experience with Roux than I do with ZZ, so for the sake of argument I took stepwise optimal F2L movecount for ZZ and the average movecounts I get for my own F2B in Roux (which are, I'm sure, able to be improved). Note that even with these conservative figures the Roux approach to building EOF2L appears to be as (if not more) efficient. There is now a question of ergonomics, and on this front I think the the two approaches can be equally fast. Some may prefer ZZ F2L (slightly awkward EOLine but rotationless, easy lookahead and RUL) while others may prefer Roux F2B (slightly awkward FB but rotationless and RrUM). I'm not sure an argument can be made for one being strictly better than the other, but if someone equally competent/experienced with both methods says otherwise then I'd gladly stand corrected.
So in sum I think that this method is nothing amazingly innovative or revolutionary, but certainly deserves more than to be simply dismissed as another reinvention of a shitty wheel. The ideas are simple (the only differences between this and commonly proposed DFDB/OLL/PLL are really just EO+DFDB and ZBLL in place of OLL/PLL), but they have merit.
Let's look at the 3 L10P methods
CMLL + LSE
This is standard for Roux. Avg movecount: 10 CMLL (computed from avg of all the algs in my cmll sheet + 0.25 AUF) + 13 LSE (assuming 8 EOLR/EOFB and 5 4c, essentially the most advanced LSE there is) = 23 STM total
DF+DB, OLL, PLL
This is what beginners propose all the time. Avg movecount: 6 DFDB (I just got 10 random state LSE scrambles from cstimer and solved DFDB) + 10 OLL (from here + 0.25 AUF) + 13 PLL (from avging algdb.net algs + 0.5 AUFs) = 29 STM total
DF+DB+EO, ZBLL
This is what we are proposing. Avg movecount: ~8 DF+DB+EO (again, got 10 random state LSE scrambles and solved) + 15 ZBLL (optimal movecount for ZBLL is 12.08, so I'm overestimating generously for the sake of argument. For comparison, optimal PLL movecount is 11.5 and avg movecount for speedoptimized PLL algorithms on algdb.net is ~12.8) = 23 STM total
Note that our proposed L10P finish, on average, would take as many moves as CMLL + very advanced LSE (which often entails learning additional CMLLs to influence EOLR cases). So yes, the "only" difference between this and what a beginner proposes is that EO is done with insertion of DF/DB edges, and we use ZBLL instead of OLL/PLL, but it's clear that this difference is crucial. In this case, this method is as efficient as world-class L10P and so the standard objection to "roux-cfop hybrid" posts (namely, inefficiency) that prevents them from taking off does not stand; hence the indicator that "it looks like other methods that have been shot down before" shouldn't come into play here.
Now there are two further objections that I think can be raised at this point:
1) It may be just as efficient as vanilla roux, but why do this silly stuff? It disrupts flow; CMLL/LSE is a cleaner approach.
2) If you're going to learn FULL ZBLL, why not learn the method that was meant to be used with it, ZZ?
And my responses:
Objection 1) I'm going to assume the crux of this objection is not that EO+DFDB just "feels unclean" or "unnatural," as these are rather subjective points; instead I'm assuming the main point is that there seems no reason to go to such lengths if you can get as much bang for only 42 algs' buck. My response to this is that there is indeed a small advantage to this approach over standard CMLL/LSE: specifically, flow can be much better with EODFDB/ZBLL. There are two advantages I see:
(i) Very good prediction. During SB, it is very easy to track DFDB edges + D center, so there should be no pause between SB and EODFDB. During EODFDB, it is very easy to recognize CP (because corners are just being AUFed back and forth), and imo possible to predict the position of two edges; hence, there should be no pause between EODFDB and ZBLL. Currently, Kian believes the main bottleneck of a Roux solve is the often frustratingly long pause to recognize CMLL (the rest of his solves are pretty much pauseless). By performing this recognition during the execution of EODFDB, we can eliminate this pause, leading even more fluid solves.
(ii) Higher tps. In CMLL/LSE, 10 moves are drilled algorithmic face turns and 13 are MU spam; in EODFDB/ZBLL, 8 moves are MU spam and 15 are drilled algorithmic face turns. I think it is safe to say that face turns can achieve a higher max tps than MU spam (Lau's 0.6 Uperm suggests 11.6 stps, while... well, I believe there's a 20TPS T perm somewhere out there?), so even if EODFDB/ZBLL may achieve the same movecount as CMLL/LSE, it has the potential to be faster.
Objection 2) Well, this is an interesting one. ZBLL was invented for ZB, and then used in ZZ, and now we are trying to say it can be used in this Roux-hybrid thing as well. So now let's compare ZZ-a and EODFDB/ZBLL: both finish with ZBLL, so we'll just compare EOF2L movecounts:
ZZ-a: 6 EOLine + 25 F2L (stepwise optimal, taken from ss forums post) = 31 STM EOF2L
EODFDB/ZBLL: 7 FB + 15 SB + 8 EODFDB = 30 STM EOF2L
Importantly, I have way more experience with Roux than I do with ZZ, so for the sake of argument I took stepwise optimal F2L movecount for ZZ and the average movecounts I get for my own F2B in Roux (which are, I'm sure, able to be improved). Note that even with these conservative figures the Roux approach to building EOF2L appears to be as (if not more) efficient. There is now a question of ergonomics, and on this front I think the the two approaches can be equally fast. Some may prefer ZZ F2L (slightly awkward EOLine but rotationless, easy lookahead and RUL) while others may prefer Roux F2B (slightly awkward FB but rotationless and RrUM). I'm not sure an argument can be made for one being strictly better than the other, but if someone equally competent/experienced with both methods says otherwise then I'd gladly stand corrected.
So in sum I think that this method is nothing amazingly innovative or revolutionary, but certainly deserves more than to be simply dismissed as another reinvention of a shitty wheel. The ideas are simple (the only differences between this and commonly proposed DFDB/OLL/PLL are really just EO+DFDB and ZBLL in place of OLL/PLL), but they have merit.
Last edited:
