• 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.
Just a quick update, I have eliminated the fixed rotation in LMCF by creating E2L pair algorithms that rotate the cube as part of the algorithm. I am wondering if this has ever been attempted in any other method? Examples for embedded z/z' are:
R F' M' B u'
F r E' R' B'
These are reasonably fast and don't require regrips.
 
I believe some COL last slot cases effectively do a z/z' as well, usually through wide moves.
 
I apologize for not having read the whole thread, so all of this may have been already suggested. I mentioned these ideas in the ZZ vs. CFOP etc. thread, but they probably fit better here. Has anybody tried:
Instead of EOLine going EO[2x2x3]Block? I can't even plan full EOLine in inspection, but if somebody was really good at ZZ it seems like it could combine the best of ZZ and Petrus.
Secondly, and this is truly half-baked: let's assume you do an EOBlock on the bottom left as described above, then build the easiest 1x2x3 block instead of the one that goes on the bottom. Would recognition be too difficult to finish the solve with ZBLL, AUF, ARF?
Building an EO 3x2x2 in one step is too hard. The best Petrus solvers can't generally plan the 3x2x2. Might as well use Heise if you're going that route.

Your second idea is just a pseudo block. It has an advantage in move count by a little and a disadvantage in recognition depending on what LL you use. Generally I think the consensus is that it's not worth it.
 
EDIT: Apparently (and not surprisingly) this is already a thing.

I was doing untimed solves and solving F2L when I ran into this LS case:
visualcube.php


and then I thought, since this case happens a lot and is pretty annoying, would it be possible to solve the case and the OLL at the same time?

Although I haven't tried generating any algorithms for this, I played around with different ways of solving the pair and what effect they have on the OLL. I'll show a few examples later.

Let's say this turns out to be a good idea, people find good algs, and it becomes one of those advanced subsets you can learn, along with things like WV, SV, CLS, pure OLL, etc. The question that follows is, how many algorithms are there in this set? Would it be manageable or a large commitment like VLS or ZBLL?

Normal OLL has 58 cases (including a skip), but there are 216 possible ways to orient the pieces, as you would find out if you tried learning VLS. However, most (51) OLL cases are counted 4 times in the 216 figure, because they can occur from 4 different angles. 5 of them are only counted twice, and 2 of them are only counted once. That accounts for all 216 cases, 51*4+5*2+2*1=204+10+2=216.

With this set, however, the OLL will have an odd number of edges flipped, so none of the cases are symmetrical. Therefore, every case is counted 4 times in the 216 orientations, so there are 54 cases.

I would divide the cases up first into the two EO cases, 3 edges oriented or 1 edge oriented. This gives two sets of 27. Each set would consist of:
4 S
4 -S
4 T
4 U
4 L
4 π
2 H
1 O

The specific case could be determined by where the flipped (if 3 edges are oriented) or oriented (if 3 edges are flipped) edge is with relation to the corners.

Here are a few algs I found:
visualcube.php
visualcube.php

(U) R U' R' U y' R' U2 R U2 R' U R
visualcube.php
visualcube.php

(Dw) R' U' R U2 R' U2 R U' y R U R'

Okay, fine, those are just inverses of each other, but those aren't the only way to flip the FR edge, I have a lot of tricks up my sleeve. (I'll make a google doc with more algs if people are interested)
 
Last edited:
I may be wrong, but my guess is that this is a large enough alg set with a specific enough application that it's probably not worth it. What would almost certainly be worth learning is the 2 algs necessary to solve edge orientation from that position. The alg you give is the one I've figured out, except I would usually try to avoid the y rotation and finish with F U moves instead of R U.
 
I may be wrong, but my guess is that this is a large enough alg set with a specific enough application that it's probably not worth it. What would almost certainly be worth learning is the 2 algs necessary to solve edge orientation from that position. The alg you give is the one I've figured out, except I would usually try to avoid the y rotation and finish with F U moves instead of R U.
54 isn't awful; some people learn ZBLL without always solving EO which means knowing almost 500 algs that you can only use maybe a third of the time. I think you're absolutely right about EO though, and I found an alg for the other case but I can't remember it right now. I think this could be a set like WV where most people don't learn every case because some of them are bad, but some are very useful and easy to recognize, for example this new one I found:

visualcube.php

F R' F' R y' R U2 R2' U' R2 U' R'
 
Sorry, I didn't read your post carefully enough. I thought you were saying there were 216 cases. 54 is a lot better. I still think it's probably not worth forcing that last slot to get a specific OLL set, and probably not worth learning the set if you aren't going to force the slot. As far as ZBLL, you can always fix EO first, with F R U R' U' F' or F U R U' R' F' to force a ZBLL case.
 
I was doing untimed solves and solving F2L when I ran into this LS case:
visualcube.php


and then I thought, since this case happens a lot and is pretty annoying, would it be possible to solve the case and the OLL at the same time?

Although I haven't tried generating any algorithms for this, I played around with different ways of solving the pair and what effect they have on the OLL. I'll show a few examples later.

Let's say this turns out to be a good idea, people find good algs, and it becomes one of those advanced subsets you can learn, along with things like WV, SV, CLS, pure OLL, etc. The question that follows is, how many algorithms are there in this set? Would it be manageable or a large commitment like VLS or ZBLL?

Normal OLL has 58 cases (including a skip), but there are 216 possible ways to orient the pieces, as you would find out if you tried learning VLS. However, most (51) OLL cases are counted 4 times in the 216 figure, because they can occur from 4 different angles. 5 of them are only counted twice, and 2 of them are only counted once. That accounts for all 216 cases, 51*4+5*2+2*1=204+10+2=216.

With this set, however, the OLL will have an odd number of edges flipped, so none of the cases are symmetrical. Therefore, every case is counted 4 times in the 216 orientations, so there are 54 cases.

I would divide the cases up first into the two EO cases, 3 edges oriented or 1 edge oriented. This gives two sets of 27. Each set would consist of:
4 S
4 -S
4 T
4 U
4 L
4 π
2 H
1 O

The specific case could be determined by where the flipped (if 3 edges are oriented) or oriented (if 3 edges are flipped) edge is with relation to the corners.

Here are a few algs I found:
visualcube.php
visualcube.php

(U) R U' R' U y' R' U2 R U2 R' U R
visualcube.php
visualcube.php

(Dw) R' U' R U2 R' U2 R U' y R U R'

Okay, fine, those are just inverses of each other, but those aren't the only way to flip the FR edge, I have a lot of tricks up my sleeve. (I'll make a google doc with more algs if people are interested)

https://sites.google.com/site/babbyandhunny/3x3x3/ols-fe
 
@efattah I have a quick question that relates to LMCF/WaterRoux that could help with the development of future methods. I feel like the problem with WaterRoux is the fact that having the DL, FL, and BL edges solved after solving your corners with TEG is not really that helpful. Not enough edges are solved on the cube to be able to solve the remaining 9 edges in two more steps that are under 500 algorithms total. So I've been wondering: what are the most efficient edges to have solved with the corners after you solve the corners? I feel like maybe if you did something like..

1. 2×2 block on back left
2. Solve the seven reamaining 7 corners somehow
3. Solve the rest of the 9 edges in 2-3 algs

...it could turn out more efficient than solving the edges the way you do in WaterRoux (I doubt the example I just showed was faster, that was just for demonstration purposes).
 
Last edited:
@efattah I have a quick question that relates to LMCF/WaterRoux that could help with the development of future methods. I feel like the problem with WaterRoux is the fact that having the DL, FL, and BL edges solved after solving your corners with TEG is not really that helpful. Not enough edges are solved on the cube to be able to solve the remaining 9 edges in two more steps that are under 500 algorithms total. So I've been wondering: what are the most efficient edges to have solved with the corners after you solve the corners? I feel like maybe if you did something like..

1. 2×2 block on back left
2. Solve the seven reamaining 7 corners somehow
3. Solve the rest of the 9 edges in 2-3 algs

...it could turn out more efficient than solving the edges the way you do in WaterRoux (I doubt the example I just showed was faster, that was just for demonstration purposes).

After some months of experimenting I no longer think that solving any edges then corners is feasible, as it is already hard enough to 1-look the corners even if you just start with the corners and almost impossible to 1 look the corners if you also solve edges before them. With that I went back to optimizing LMCF and my latest variant is almost like a reverse WaterRoux and I think it is the best by far I have developed thus far:
1. Solve corners with EG or TEG
2. Look ahead during last corner algorithm moves, to as much of the cube as you can, and decide which sub-method you finish with based on the 'lucky' draw you get after the corners
3. Based on a certain draw, you can finish with this variant: Using either a single algorithm or a string of intuitive moves, solve 3 edges of the U-layer while simultaneously executing a z rotation as part of the algorithm. My new favorite is f R U' M' U R' B'. The key here is that the definition of 'solved' is complicated. You are allowed 1 disoriented U layer edge (either in correct position or not), and this counts as solved. You are also allowed a second solved but disoriented edge on the U layer and this also counts as solved.
4. Now you are in Waterman configuration except unlike Waterman the semi-solved face is on R. You now solve the remaining L and R edges using Waterman algorithms, the last of which orients the M slice while solving the last two ledges/redges.
5. Permute M-Slice

This 'optimized' LMCF/Waterman has drastically improved ergonomics, with most solves having no rotations and many solves having almost no regrips either.

However the method is still not fully viable. The huge 'problem' when solving corners first is that after the corners you essentially have a random 'draw' on the edges. The 12 cube edges will be (obviously) in a random configuration, but it will never be totally disorganized. In approximately 90% of situations the edges actually have some type of lucky organizational principle. For example, with the above variant, if you have (by luck) 3 U layer edges already in the U-layer, then a single (expanded) ELL solves them all at once. That is a good scenario. But other times the clustered edges may be on another face, or you can have a scenario where the U and D layer edges are essentially 'swapped' and can be easily exchanged, then U and/or D can be solved via ELL algorithms. My point is this method needs certain decision trees after the corners where you choose one of several sub-methods to finish the edges maximizing your 'luck', since at least one of the several sub-methods will have a 'lucky-draw' after the corners. Right now the above variant works well in around half the solves and really well in about a quarter of them. But I still need to develop variants for the other fraction where it doesn't work that well.

TEG1 is very useful for this method since it makes 1-look on the corners even much easier.
 
@efattah Hmm. That sounds interesting and hopefully can be a sub 40 movecount method (you could call it "LerMCF" :p). The only problem I see with with it is that although I do think most commited cubers could learn this and it is very efficient/ergonomic, many people wouldn't be willing to learn this because of how "un-concrete" the steps are, if that makes any sense. It's a lot easier to just recognize a case and solve it with a simple, memorized algorithm. This LMCF variant seems to require a bit more intuition and thinking to solve the edges, which is partly what makes it so fast, but I think a lot of people would therefore find it too difficult. I also think if you showed some example solves it would probably help, and I'd certainly be willing to learn it as it sounds effiecient and fun.

With all that said, I would like to try to make some WaterRoux-like variant that is similar to this in that the last couple of steps are solving edges, but with more "concrete" steps. I would like the steps to have the same format as WaterRoux:

1. A block that consists of at least two edges and one corner
2. Finish solving the corners (I've actually made specefied methods for solving 5, 6, and 7 corners on a 3×3 that could be used here)
3. 2-3 algorithms that solve the remaining edges

... but maybe with something different than a 1×2×3 block as the first step. Like you said, I definitely don't think anybody could 1-look the corners AND the block (unless you made something useless like a 1×2×2 or a 1×1×3), but thats not the point of the method. I just want to try to make something similar to WaterRoux that could be easier for some cubers to learn, but similar in efficiency to your method. So, any ideas which edges are most efficient to solve in the first step? (I've tried a couple of combinations of pieces with no luck).

P.S. have you finished any TEG algs yet? I sent you a message about that but you haven't responded yet. (I'm nearly done with the DFL set, I'll post those algs here on Wednesday when I'm finished with them.)
 
iirc, the non-concreteness is what really puts the LM in LMCF. A big selling point is being able to branch out to one of many possible next steps in order to take advantage of lucky cases. Each step is, in a way, multiple rolls at the luck die instead of just the single roll that you get in normal methods.
 
Here I is a simple method I thought about is similar to columns and cfop and it requires no new algs to solve if you know cfop I call is fcop where you solve 4 pairs(they don't need to match the centers) then you solve the centers and as many cross edges as you can then you do ll this method has a lower movecount than cfop most of the time but look ahead can be a bit harder what do you think of these method
 
Here I is a simple method I thought about is similar to columns and cfop and it requires no new algs to solve if you know cfop I call is fcop where you solve 4 pairs(they don't need to match the centers) then you solve the centers and as many cross edges as you can then you do ll this method has a lower movecount than cfop most of the time but look ahead can be a bit harder what do you think of these method

The problem with this method is creating F2L pairs is very difficult since the edge piece you are looking to pair could be on the D slice where the cross normally would be. Further since you have 4 more 'random' edge floating around during F2L pair creation, you are less likely to catch sight of the next edge you are looking for...
 
The problem with this method is creating F2L pairs is very difficult since the edge piece you are looking to pair could be on the D slice where the cross normally would be. Further since you have 4 more 'random' edge floating around during F2L pair creation, you are less likely to catch sight of the next edge you are looking for...
That's why I said it's hard to look ahead and even if the edge is in the D layer is not that many moves and f2l is more efficient in this method than in cfop
 
As I was on my 9 hour car ride home from a vacation, I was experimenting with 4x4 and came up with this direct solution method.

1) Solve the L face center and "solve" the R center by filling it with R and U colors. This will ensure that the F, D, and B centers wI'll be easily accessible for the next few steps.
2) Solve a 1x3x4, off of the L center, as in the Meyer method.
3) Expand the 1x3x4 into a 2x3x4. The best way I have found to do this is to loosely follow these steps:
a) Solve the half-center on the D face.
b) Solve the remaining pieces by building 2 1x1x3 blocks, made of 2 centers and an edge, and insert them. This sounds rather inefficient, but shortcuts can be made. In a way, it's similar to building F2L pairs.
4) Expand the 2x3x4 into a 3x3x4 using the same procedure.
5) Solve the rest of the F3L. The best way I have found to do this is as such:
a) Rotate the unsolved side to the F face. Build the 2 1x1x3 corner-edge-edge pairs and place them.
b) Solve the 2 remaining D face edges.
c) Solve the remaining centers with commutators.
OR (probably better)
b) Solve one D layer edge and 3/4 of the last 2 centers.
c) Solve the last edge and centers using one of ~32 algs, excluding commutators and mirrors.
6) CLL
7) K4 style ELL

Looks pretty promising to me. It seems decent on 5x5. I haven't tried it on bigger cubes. I'll try to get around to an example solve sometime tomorrow.
 
As I was on my 9 hour car ride home from a vacation, I was experimenting with 4x4 and came up with this direct solution method.

1) Solve the L face center and "solve" the R center by filling it with R and U colors. This will ensure that the F, D, and B centers wI'll be easily accessible for the next few steps.
2) Solve a 1x3x4, off of the L center, as in the Meyer method.
3) Expand the 1x3x4 into a 2x3x4. The best way I have found to do this is to loosely follow these steps:
a) Solve the half-center on the D face.
b) Solve the remaining pieces by building 2 1x1x3 blocks, made of 2 centers and an edge, and insert them. This sounds rather inefficient, but shortcuts can be made. In a way, it's similar to building F2L pairs.
4) Expand the 2x3x4 into a 3x3x4 using the same procedure.
5) Solve the rest of the F3L. The best way I have found to do this is as such:
a) Rotate the unsolved side to the F face. Build the 2 1x1x3 corner-edge-edge pairs and place them.
b) Solve the 2 remaining D face edges.
c) Solve the remaining centers with commutators.
OR (probably better)
b) Solve one D layer edge and 3/4 of the last 2 centers.
c) Solve the last edge and centers using one of ~32 algs, excluding commutators and mirrors.
6) CLL
7) K4 style ELL

Looks pretty promising to me. It seems decent on 5x5. I haven't tried it on bigger cubes. I'll try to get around to an example solve sometime tomorrow.
This is more or less OBLBL with a k4 LL though as far as I'm aware OBLBL has not been experimented with much so good luck with your development.
 
Back
Top