• 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.

Proposed ZZLS and VIM!

I have most of the architecture done. I made it somewhat fit for human consumption. I have a solving table and the case I'm going to stick with. The architecture is simply cross plus 3 F2L slots. EO if needed. Look. Alg. look. solve. AUF if needed.

The case I'm going to stick with is corner piece that should be clockwise from the trapped edge oriented and permuted in position 1. Other corner piece that shares the trapped edge color in position 4.

The solve table looks like this. If you see any mistakes let me know. Every case came out of cube explorer rotation free.

Mythology and metaphor is coming back - I think pipkikass will be very happy with it. It can be used as a recognition device.

Kirjava says this is the same thing as solving on the up face and it could be. He asked what the uses would be. If say you had the first two layers and edge orientation and you looked at the back edge (or deduced what it was). Used an ambiguous not quite solving not quite permuting alg A to nail one corner piece in back but only permute a second corner also in the back? A lazy and incomplete third/half of a COLL alg? What might the advantages be?

1) No Brunos.
2) No Double Sunes
3) Final AUF could be clearly visible before alg A
4) The whole Last layer could be rotation-less if alg A was.
5) Almost everything you need to recognize the case would be clustered up front.
6) Recognition could almost be about corner orientation
The following things I suspect but can't do the math for right now.
7) Limited F & B moves
8) You could do something clever with phasing.

What kind of lookahead could you develop?

I will think some more, dream some more, work some more, and hopefully be back tomorrow with my alg A set.
 
Last edited:
I admit I don't quite fully understand your method yet, but just on your advantages:
1 and 2-what's wrong with Brunos and double sunes? They are some fast algs.
4 - Do you mean AUF-less? I don't see many people rotating to perform LL. Or do you mean for recog? I know PLL recog can be done by just seeing two sides but can OLL?
 
I admit I don't quite fully understand your method yet, but just on your advantages:
1 and 2-what's wrong with Brunos and double sunes? They are some fast algs.
4 - Do you mean AUF-less? I don't see many people rotating to perform LL. Or do you mean for recog? I know PLL recog can be done by just seeing two sides but can OLL?

On their own they are not that great for move count and sometimes they are mistaken for the other.

AUF's would be minimized. There would be no reason to do one in between alg A and alg B. No need to use one to peek around or reposition between alg A and alg B.

With some look a head and some good practice you might even be able to cancel U moves that happen between alg A and B.
 
Last edited:
Most of these algs are too long and incredibly hard to execute. It's not much of a triumph to say they're rotation free when I have to regrip 2 or 3 times per alg.

Watch this - then start adding restrictions like "no B moves" when generating algs.

EDIT: oh, and UaC1 of solving the dragon is a longer and slower than doing it the normal way. R U' R U' R' U' R U R U R U' R. It isn't a promising indication for the rest of the algs.
 
Last edited:
They are just a lower limit and and a chance to look at the amount of F/B moves. A proof of concept.

They are not as low as I hoped. Everything outside of the C1 row and the S column are incredibly low for their respective OLL+PLL cases. They can be sexed a little up later. We'll see how long the opening moves are and if they are bad. My eyes are not working well right now but I only see 6 14fs in 54 cases while PLL has 7 14fs in 28 cases.

I did something similar to what you suggest but 3x for half the forging cases and got a move count between 8 and 12move that were likable pure 2-gen except for 3 cases where a rotation to make an made an OKish alg. I didn't keep track of absolute lowest number but I never saw a 6. Im gonna add another axis of freedom (swapping non phasing positions) to what I did before (checking each orientation of the secondary corner) see if it can go lower.
 
Last edited:
Did a test case for back porting some of this to the normal last layer. The the idea of nailing a corner with certainty and pinning another with only permutation then solving a PLL with a conflated set of OLLs. That might be a CFOP killer on it's own.

this is an F Perm case conflated. Cube explorer saves these as generators...

F2 L2 B' F2 U B' R2 F D' B R2 B F' U' (14f*)
R2 D B' L2 D L2 D2 L2 F' D' F L2 B R2 (14f*)
R2 B' L2 F' D F L2 D2 L2 D' L2 B D' R2 (14f*)
R' U R U' R' U L' U' L U' F2 R' F2 R2 (14f*)
F U F R' D2 L B' L' D2 R2 F' R' U' F' (14f*)
R2 B U2 F R' F' U2 R2 U2 R U2 B' R' (13f*)
F U2 L2 D F' D' L2 B' U B U2 F' U (13f*)
R B U2 R' U2 R2 U2 F R F' U2 B' R2 (13f*)
L U2 R' U' R B2 D L D' B2 U2 L' U' (13f*)

That's the move count for solving an F perm normally then also with sunes, anti-sunes, headlights, chameleons, bow ties. Look at the move counts at the end. Look at number of front and back moves for the separate OLLs & PLLs kinda cancel each other out except for that middle case might be a candidate for rotation.
 
Last edited:
They are just a lower limit and and a chance to look at the amount of F/B moves. A proof of concept.

They are not as low as I hoped. Everything outside of the C1 row and the S column are incredibly low for their respective OLL+PLL cases. They can be sexed a little up later. We'll see how long the opening moves are and if they are bad. My eyes are not working well right now but I only see 6 14fs in 54 cases while PLL has 7 14fs in 28 cases.

I did something similar to what you suggest but 3x for half the forging cases and got a move count between 8 and 12move that were likable pure 2-gen except for 3 cases where a rotation to make an made an OKish alg. I didn't keep track of absolute lowest number but I never saw a 6. Im gonna add another axis of freedom (swapping non phasing positions) to what I did before (checking each orientation of the secondary corner) see if it can go lower.

Going back to the Solve the Dragon bit, the whole top row is pointless. Having gone through all the algs on that row they all skip OLL and it is actually faster to solve normally with R U' R' and PLL rather than one alg with U, R, L, F, B and D moves which "could be sexed up later" (to what? An even longer 2-gen alg?)

and 13f as a lower bound seems to be a lot of moves. Especially for something that may/may not create a skip ultimately.
 
Going back to the Solve the Dragon bit, the whole top row is pointless. Having gone through all the algs on that row they all skip OLL and it is actually faster to solve normally with R U' R' and PLL rather than one alg with U, R, L, F, B and D moves which "could be sexed up later" (to what? An even longer 2-gen alg?)

and 13f as a lower bound seems to be a lot of moves. Especially for something that may/may not create a skip ultimately.

I was looking at columns S and F. I didn't like the idea of column S but those algs are like the shorter pure corner orientation algs and somehow fewer moves. Column F is shorter than or equal to a pure F perm.

My thinking is the lower the absolute move count is the shorter the good and executable algs are.
 
Last edited:
I was looking at columns S and F. I didn't like the idea of column S but those algs are shorter than or equal to pure corner orientation algs.
Column F is shorter than or equal to a pure F perm.

Shorter doesn't mean better. And before you say you'll make the algs better later, making them better will probably mean making them longer since all of these algs have come straight from Cube Explorer and are optimal.

As for column S, I have literally gone through every case and using the monoflip commutator or sune or some sort of edges oriented OLL+PLL, and all are faster than the algs you proposed in their rawest form

EDIT: just read back through the whole thread. You seem to be ignoring anything that doesn't support your idea (which was riddled with errors to begin with) including numerous criticisms from people that really know what they're talking about. I'm done.
 
Last edited:
You seem to be ignoring anything that doesn't support your idea (which was riddled with errors to begin with) including numerous criticisms from people that really know what they're talking about. I'm done.

I'm not entirely ignoring people who have some knowledge. I have developed a method out of the madness and not stopping because someone else hastily says "you can't - you shouldn't" is part of the method.

Thank you for coming this far.
 
Last edited:
You'd be well advised to change your pic - very disconcerting.
Btw, I think if there's anything that beats CFOP, it's ZZ-b+. I don't see any advantage of your proposed method over it, even if you also use ZZLS.
 
You'd be well advised to change your pic - very disconcerting.
Btw, I think if there's anything that beats CFOP, it's ZZ-b+. I don't see any advantage of your proposed method over it, even if you also use ZZLS.

What about Roux? Or there are some other minor methods that were never really given a chance that could be at least as good as CFOP.
 
Back
Top