• 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.
This might be a decent maegaminx LSLL method, although I certainly worry about the alg count...

1. Solve a 1×2×2 block on the back left
2. Orient the rest of the pieces while inserting the FR edge into its slot (probably >200 algs)
3. TTLL (probably not much more than 100 algs here considering there's a 1×2×2 solved already)

As I said, I feel like step 2 would be way too many algs but I feel some good ideas could be built off this method layout that could have less algs.
 
This might be a decent maegaminx LSLL method, although I certainly worry about the alg count...

1. Solve a 1×2×2 block on the back left
2. Orient the rest of the pieces while inserting the FR edge into its slot (probably >200 algs)
3. TTLL (probably not much more than 100 algs here considering there's a 1×2×2 solved already)

As I said, I feel like step 2 would be way too many algs but I feel some good ideas could be built off this method layout that could have less algs.
Step 2 is way too many algs. It becomes feasible if you solve the corner at the same time but that basically becomes minitripod which is not bad but I haven't been bothered to learn all the algs so use a reduce version atm.
 
Step 2 is way too many algs. It becomes feasible if you solve the corner at the same time but that basically becomes minitripod which is not bad but I haven't been bothered to learn all the algs so use a reduce version atm.
What do you mean by "if you solve the corner at the same time"? Wouldn't that add more algs? Also would this be a feasible method (algwise) if you did EO before all the steps?
 
What do you mean by "if you solve the corner at the same time"? Wouldn't that add more algs? Also would this be a feasible method (algwise) if you did EO before all the steps?
I do the second step intuitively. I mean leave just the 4 LL corners (and 3 edges but I usually solve them though as said before I use a rediced alg set).
 
I have an idea for a roux last slot finish, and I'm confident that it will blow the traditional roux finish out of the water. My idea is to orient last 5 corners while inserting the last slot edge, eo+df+db, and finally ttll. And by the way, you would have to solve the first square of the second block in the back
 
I have an idea for a roux last slot finish, and I'm confident that it will blow the traditional roux finish out of the water. My idea is to orient last 5 corners while inserting the last slot edge, eo+df+db, and finally ttll. And by the way, you would have to solve the first square of the second block in the back

This approach is actually less efficient than traditional roux:
10 OL5C + last edge
8 EODFDB
14 TTLL + 1.5 AUF
= 33.5 moves for LS + L10P

vs traditional roux:
5 last pair
9 CMLL
14 LSE
= 28 moves for LS + L10P

You can question my OL5C estimate, since I really only genned a random sample of 6-7 to get an idea (some were 8-9 moves, others 13-14), but I am confident in my other estimates (they're backed pretty solidly by HARCS analysis). Sure, OL5C might be off, but I would have to be off by 33.5 - 28 = 5.5 moves just to break even with traditional roux; that would mean OL5C has an average movecount of ~4.5... I dont' think this is the case.
 
This approach is actually less efficient than traditional roux:
10 OL5C + last edge
8 EODFDB
14 TTLL + 1.5 AUF
= 33.5 moves for LS + L10P

vs traditional roux:
5 last pair
9 CMLL
14 LSE
= 28 moves for LS + L10P

You can question my OL5C estimate, since I really only genned a random sample of 6-7 to get an idea (some were 8-9 moves, others 13-14), but I am confident in my other estimates (they're backed pretty solidly by HARCS analysis). Sure, OL5C might be off, but I would have to be off by 33.5 - 28 = 5.5 moves just to break even with traditional roux; that would mean OL5C has an average movecount of ~4.5... I dont' think this is the case.
I'm a bit skeptical about some of the Roux estimates as well as the OL5C estimates, this is more or less what I would predict...

Roux:
6-7 move pair (you can get some nasty cases here such as FR edge stuck on the d-layer and DRF corner oriented)
10 move CMLL (I know optimal is 9 moves but I've heard from Kian Mansour and other experts that their CMLLs average ~10 moves)
14 move LSE
~30-31 move LS

This other method:
8 move OL5C (I have a feeling none of the algs you genned included any of the 4-6 ultra fast cases)
8 move EOFB
14 move TTLL
~30 move LS

I definitely think you're right that this doesn't blow Roux out of the water, and in terms of movecount it's about the same. But I've tried using this a couple of times and find it a bit more ergonomic than Roux, especially because although TTLL=L6E movecount, TTLL only requires 1 alg that could executed fluently whereas Roux L6E uses 2-3 algs that require some pauses if you're not super practiced. I personally think I have to agree with you that a 1-2 move reduction and slightly better ergonomics isn't really worth it to learn 100 extra algs, but I can see the appeal of this method. I'd be willing to generate algs for it since all that needs to be generated are the optimized TSLEs that don't require EO to be preserved, but I don't really know who would be interested in learning it.
 
Roux:
6-7 move pair (you can get some nasty cases here such as FR edge stuck on the d-layer and DRF corner oriented)
You can get these nasty cases, but with proper blockbuilding you should be averaging ~5 for last pair. These block movecounts are taken from an avg100 of mine (and I would hardly say my blox are optimal).

10 move CMLL (I know optimal is 9 moves but I've heard from Kian Mansour and other experts that their CMLLs average ~10 moves)
You're right about this, I keep getting 9 stuck in my head for COLL/CMLL for some reason. Sorry about that. CMLL should be 10 + 0.75 AUF.

= 5 pair + 10.75 CMLL + 14 LSE = 29.75 total

This other method:
8 move OL5C (I have a feeling none of the algs you genned included any of the 4-6 ultra fast cases)
Sure, I'll give this to you. I'm skeptical (just because there are some ultra fast cases doesn't mean the average can be brought down by 2 whole moves), but I don't have any data. I'll try running a HARCS analysis on this step.
However, I will add 0.75 AUF.

14 move TTLL
Don't forget your AUFs: they add 1.5 moves on average.

= 8.75 OL5C + 8 EODFDB + 15.5 TTLL = 32.25 total

I definitely think you're right that this doesn't blow Roux out of the water, and in terms of movecount it's about the same.
Even if it breaks even (which I am skeptical of), you are learning around 5 times as many algs. With the number of algs you're learning, you might as well learn ZZ-b and match roux movecounts with easier lookahead and <R,U,L> rotationless F2L (make of that what you will, I know some people prefer RrUM but RUL F2L sounds pretty damn nice to me).

although TTLL=L6E movecount
This is false.

TTLL only requires 1 alg that could executed fluently whereas Roux L6E uses 2-3 algs that require some pauses if you're not super practiced.
Have you seen Kian execute LSE? Yes, it takes practice, but it's pretty much pauseless (except when he sometimes fails on 4c recog), and I'm not sure TTLL is exactly 0-pause either.

I personally think I have to agree with you that a 1-2 move reduction and slightly better ergonomics isn't really worth it to learn 100 extra algs, but I can see the appeal of this method. I'd be willing to generate algs for it since all that needs to be generated are the optimized TSLEs that don't require EO to be preserved, but I don't really know who would be interested in learning it.

To be completely blunt, I'm not sure I see the point. I don't see the 1-2 move reduction and all I'm seeing in exchange is a higher alg count, worse recognition, inability to build FR square without doubling alg count, and potential rotations in the solve (if you stick with CT's 33% 2gen TTLL) that never would have been there in traditional roux.
 
Last edited:
Alright, @Arc ran a HARCS analysis: 10000 simulated solves on the proposed method ("TSLE" is OL5C + FR edge)

Looks like we were both off, the avg is around 9.125.

upload_2017-8-6_16-27-48.png
 
I've kind of made a new cross variation. I'm currently calling it C2FE (or cross with 2 flipped edges) where you make the cross but with 2 opposite flipped edges. I think this would help if you are not color neautral or if there is a hard cross. When you get to last layer, instead of doing full oll or f sexy f',you put the 2 flipped edges in the F and B, and you do M' U' x4 (or M' U x4). You do that when you have a L case and you put the 2 already oriented edges in the front and left. This is like a double edge sword though, as it can make your cross easier but can make you LL harder. It depends though in which is more important.
 
I've kind of made a new cross variation. I'm currently calling it C2FE (or cross with 2 flipped edges) where you make the cross but with 2 opposite flipped edges. I think this would help if you are not color neautral or if there is a hard cross. When you get to last layer, instead of doing full oll or f sexy f',you put the 2 flipped edges in the F and B, and you do M' U' x4 (or M' U x4). You do that when you have a L case and you put the 2 already oriented edges in the front and left. This is like a double edge sword though, as it can make your cross easier but can make you LL harder. It depends though in which is more important.
Is this actually any better than making a bad cross?

Here your adding at least 8 moves on compared to maybe 4 for a bad cross and the extra moves for the cross would be more ergonomic and executed more quickly as you're not using the same moves each time.
 
I’ve been thinking about a 2-look Last Slot Last Layer method recently:

The first part is MLS. MLS (Manning Last Layer) involves inserting the last F2L pair while orienting all 4 LL corners using 1 of 26 algorithms. It’s basically Winter Variation, but with better algs since you don’t have to preserve the EO.

The second part is MMLL (Miranda Manning Last Layer). MMLL is a 1LLL subset where all the corners are already oriented. I’m fairly certain that there’s a total of 133 algorithms, excluding regular PLL cases, but somebody else will have to check this.

MM (as I call it) is pretty much a reverse ZB: instead of solving EO during your LS before doing 1LLL, you do CO instead (before doing 1LLL). Full edge control has fewer algorithms than full corner control, but it dramatically reduces the LL alg count from 493 to only 133.

ZB pros:
- ZBLLs occur naturally (i.e. without intentionally affecting LL during LS) much more often than MMLLs
- More developed, good algs have already been found
- there’s a lot of easy cases
Cons:
- ALG COUNT

MM pros:
- Significantly fewer algs than ZBLL
- slightly easier/faster CP recognition
- If you know full ELL, you already know over 1/5 of MMLL
Cons:
- algs aren’t as good, mainly due to not as much work having been put into them, and none of them can be pure 2-gen
- not as many short, easy cases

Overall, I think that MM has potential to be really great! It has all the benefits of ZBLL, but without having nearly as many algs. I have tested out recognition myself to an extent, and it really doesn’t seem to be that bad. I feel that with more time spent with organization and development, and with practice, recognition could be very quick. All of the algs I've made so far can be found here.
 
I’ve been thinking about a 2-look Last Slot Last Layer method recently:

The first part is MLS. MLS (Manning Last Layer) involves inserting the last F2L pair while orienting all 4 LL corners using 1 of 26 algorithms. It’s basically Winter Variation, but with better algs since you don’t have to preserve the EO.

The second part is MMLL (Miranda Manning Last Layer). MMLL is a 1LLL subset where all the corners are already oriented. I’m fairly certain that there’s a total of 133 algorithms, excluding regular PLL cases, but somebody else will have to check this.

MM (as I call it) is pretty much a reverse ZB: instead of solving EO during your LS before doing 1LLL, you do CO instead (before doing 1LLL). Full edge control has fewer algorithms than full corner control, but it dramatically reduces the LL alg count from 493 to only 133.

ZB pros:
- ZBLLs occur naturally (i.e. without intentionally affecting LL during LS) much more often than MMLLs
- More developed, good algs have already been found
- there’s a lot of easy cases
Cons:
- ALG COUNT

MM pros:
- Significantly fewer algs than ZBLL
- slightly easier/faster CP recognition
- If you know full ELL, you already know over 1/5 of MMLL
Cons:
- algs aren’t as good, mainly due to not as much work having been put into them, and none of them can be pure 2-gen
- not as many short, easy cases

Overall, I think that MM has potential to be really great! It has all the benefits of ZBLL, but without having nearly as many algs. I have tested out recognition myself to an extent, and it really doesn’t seem to be that bad. I feel that with more time spent with organization and development, and with practice, recognition could be very quick. All of the algs I've made so far can be found here.
I think this has been proposed before (as Anti-ZBLL or something but don't quote me on that). The main reason that it isn't used is the same reason no one uses CFCE: the algs suck and are significantly worse than ZBLL (and that's not because they aren't very "developed"- someone tried to push it a year or so ago and they concluded that abut half of the cases have no real good algs compatable with even the worse ZBLL and the set as a whole is much more inefficient due to WV being longer and anti-ZBLL longer than ZBLL).

Basically the only advantage it has is that there is a lower alg count.

E: actually it's called COALL
 
I have a set of 26 algs that does CO+FR in 8 moves on average. You actually do an average of 2 moves to set up a case, and then perform an alg which is 6 moves avg. And if I add a few more algs it will get rid of the bad setup cases which take like 5 moves. This is less moves than tsle, and a lot less algs
 
The main reason that it isn't used is the same reason no one uses CFCE: the algs suck and are significantly worse than ZBLL

I constantly hear people saying ELL algorithms are bad. This hasn't been my experience (recognition is a different story). Has anyone ever posted a time-attack of ELL or ELL algorithm timings?
 
I have a set of 26 algs that does CO+FR in 8 moves on average. You actually do an average of 2 moves to set up a case, and then perform an alg which is 6 moves avg. And if I add a few more algs it will get rid of the bad setup cases which take like 5 moves. This is less moves than tsle, and a lot less algs

Feel free to post it. HARCS was using optimal <R,U,M,r> algs. Mixing in <R,U,F,r> or <R,U,D,r> at discretion would probably result in a lower move count. If @mDiPalma made custom states work in analysis (pls) I would have numbers for pure <R,U,F,r> and <R,U,D,r> optimal too.
 
1. 2x2x3 (12/12)
2. F2L Pairs (10/22)
3. Corners (10/32)
4. L5E (12/44)

Plain and simple lol.

Example:

U2 B' R2 B U2 F' R2 B' R2 B2 U F2 U' R' B2 D2 U' L F' D2

z2 y F2 L2 U' F' R2 (D U) r2 U2 r2 // FB (9/9)
y R U' R' U' F' y' U' R' U R' F R F' // Pairs + easy CP case (12/21)
R' U' R U' R' U2 R // Corners (7/28)
d M U' M U' M2 U' M' U2 M2 U2 M' U2 // L5E (13/41)

Sorta lucky but even so, this could definitely be sub-45 STM.
 
Back
Top