• 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.
2Gen-redux is not a finshed method yet crafto22. as soon as it is finished he will make a tutorial, I have been talking with him.

Let me Repost this because evidently no one was listening the first time:(also it got drowned by posts asking about 2GR)
Hey guys. There is a 4x4 method like Yau but for ZZ me and Neuro came up with. It is called NS4. You start 3x3 stage with EOXcross every time.
it also allows you to figure out if you have OLL parity even when finishing edgepairing, and by adding a few algs to EPLL you will never have to waste another look to resolve PLL parity.
Here are the steps:
-Solve L & R centers
-Solve the Line edges, place them at DL and DR, so a D/D' move would place them correctly. Also place an oriented cross dedge and an oriented E-slice edge at FL/FR.
-Solve last 4 centers
-Solve last cross dedge (solving another dedge with 2-at-a-time at this point is good), then Resolve the cross. Pair up the E-slice edge with a corner to make an F2L pair and place in one of the back slots oriented.
-Edgepairing+EO. You can either EOpair, or solve 2-at-a-time while orienting the edges afterwards, it's up to your taste. Resolve OLL parity now if you have it.
-ZZF2L. You should have full EOCross, and one F2L pair already solved in the back. there is a 50/50 chance it is in the correct spot already, but if it isnt, now place it in the right spot. You now have EOXcross, and continue with ZZF2L/Rotationless F2L or whatever you want to call it
-Last layer. I HEAVILY suggest using COLL-EPLL, because by adding ~ 4 algs and the 2 pure parities to the EPLL algset, you get EPLL+parity, which solves PLL parity at the same time as well. EPLL+ parity algs here.

The original thinking behind this method was this: CFOP has Yau/Hoya, Roux has Meyer, but what does ZZ have? a shittier form of redux+beginner edgepairing, Z4(which no one uses). but after playing with this, I have found that having a yau-like version of ZZ wasn't the only advantage of this method. You also get a really fast 3x3 stage, and with only a few extra EPLL+parity algs you have a purely 2-look last layer(CFOP LL on 4x4 varies and can go as high as 4 with double parity). And movecount isn't a disadvantage as well; with help from Teoidus, we found that the average movecount is about 128, which is only a little worse than Yau(which is 120-140 moves), and more efficient than Meyer(130-150).

Anyone think this is interesting?
 
2Gen-redux is not a finshed method yet crafto22. as soon as it is finished he will make a tutorial, I have been talking with him.

Let me Repost this because evidently no one was listening the first time:(also it got drowned by posts asking about 2GR)
Hey guys. There is a 4x4 method like Yau but for ZZ me and Neuro came up with. It is called NS4. You start 3x3 stage with EOXcross every time.
it also allows you to figure out if you have OLL parity even when finishing edgepairing, and by adding a few algs to EPLL you will never have to waste another look to resolve PLL parity.
Here are the steps:
-Solve L & R centers
-Solve the Line edges, place them at DL and DR, so a D/D' move would place them correctly. Also place an oriented cross dedge and an oriented E-slice edge at FL/FR.
-Solve last 4 centers
-Solve last cross dedge (solving another dedge with 2-at-a-time at this point is good), then Resolve the cross. Pair up the E-slice edge with a corner to make an F2L pair and place in one of the back slots oriented.
-Edgepairing+EO. You can either EOpair, or solve 2-at-a-time while orienting the edges afterwards, it's up to your taste. Resolve OLL parity now if you have it.
-ZZF2L. You should have full EOCross, and one F2L pair already solved in the back. there is a 50/50 chance it is in the correct spot already, but if it isnt, now place it in the right spot. You now have EOXcross, and continue with ZZF2L/Rotationless F2L or whatever you want to call it
-Last layer. I HEAVILY suggest using COLL-EPLL, because by adding ~ 4 algs and the 2 pure parities to the EPLL algset, you get EPLL+parity, which solves PLL parity at the same time as well. EPLL+ parity algs here.

The original thinking behind this method was this: CFOP has Yau/Hoya, Roux has Meyer, but what does ZZ have? a shittier form of redux+beginner edgepairing, Z4(which no one uses). but after playing with this, I have found that having a yau-like version of ZZ wasn't the only advantage of this method. You also get a really fast 3x3 stage, and with only a few extra EPLL+parity algs you have a purely 2-look last layer(CFOP LL on 4x4 varies and can go as high as 4 with double parity). And movecount isn't a disadvantage as well; with help from Teoidus, we found that the average movecount is about 128, which is only a little worse than Yau(which is 120-140 moves), and more efficient than Meyer(130-150).

Anyone think this is interesting?
Oh okay perfect thank you for the quick response. It's simply difficult to find information when there are so many posts being made all at once. On the subject of your 4x4 method, it seems very interesting. I'm thinking about switching to ZZ-CT so this could be useful!
 
Anyone think this is interesting?

Yes, you have mentioned this and we have seen it, I'm sure some people find it interesting. However, reposting this at any available opportunity is not the way to go about spreading your method, and it is actually in the forum guidelines that you shouldn't do this. Maybe post something whenever there's a new development or something, but don't keep posting it unless people ask you to. Also, this didn't answer the question crafto asked, which will probably be covered up by new posts now, just like you mentioned. I had the same question as crafto, and if you can explain your 4x4 method, it would be greatly appreciated if you could explain this 2-gen reduction instead. Thanks.
 
Yes, you have mentioned this and we have seen it, I'm sure some people find it interesting. However, reposting this at any available opportunity is not the way to go about spreading your method, and it is actually in the forum guidelines that you shouldn't do this. Maybe post something whenever there's a new development or something, but don't keep posting it unless people ask you to. Also, this didn't answer the question crafto asked, which will probably be covered up by new posts now, just like you mentioned. I had the same question as crafto, and if you can explain your 4x4 method, it would be greatly appreciated if you could explain this 2-gen reduction instead. Thanks.
Preach. I feel someone could at least fill us in on what a key swap is or some of the basic functioning of this CP stuff...
 
Preach. I feel someone could at least fill us in on what a key swap is or some of the basic functioning of this CP stuff...

I can help you understand CP, actually. Basically, whenever you do anything 2-gen (I'll use R and U for clarity) it's impossible to swap two corners. You can cycle edges, but no corners. So, in order to reduce to 2-gen (i.e. 2G redux) you have to make some swap of corners first (I guess they're calling it a key swap). Still, I don't know what this key swap thing is other than that it solves CP, but hopefully this will help you understand what's going on until someone who is familiar with the method posts a tutorial/overview.
 
I can help you understand CP, actually. Basically, whenever you do anything 2-gen (I'll use R and U for clarity) it's impossible to swap two corners. You can cycle edges, but no corners. So, in order to reduce to 2-gen (i.e. 2G redux) you have to make some swap of corners first (I guess they're calling it a key swap). Still, I don't know what this key swap thing is other than that it solves CP, but hopefully this will help you understand what's going on until someone who is familiar with the method posts a tutorial/overview.
Thanks for the help, but I think I'm pretty clear on this part of the CP. I'm still a bit confused with the way the method works as a whole but I suppose once the tutorial is made it should dispel any confusion.
 
@crafto22 I'm sorry the explanations are so unclear. Most of what I've been posting on this thread is in-dev stuff so it's not very organized. So far the best resources for the theory behind 2GR are the first two links in my sig (I make some follow up posts after the second link, scroll down and you'll see them) and this video I made a little while back. They should give a 7/10-ish idea of how/why 2GR works.

Since I've written those things I've come up with a better way to detect and track CP during inspection and I'm working on a 2GR website to sorta collect all information needed to learn 2GR into one place. I'm pretty busy with schoolwork but hopefully I can get that up within 2-3 weeks.

In the meantime though, if you have any specific questions/things you're confused about feel free to ask and I will try to explain. I check this thread pretty often
 
@crafto22 I'm sorry the explanations are so unclear. Most of what I've been posting on this thread is in-dev stuff so it's not very organized. So far the best resources for the theory behind 2GR are the first two links in my sig (I make some follow up posts after the second link, scroll down and you'll see them) and this video I made a little while back. They should give a 7/10-ish idea of how/why 2GR works.

Since I've written those things I've come up with a better way to detect and track CP during inspection and I'm working on a 2GR website to sorta collect all information needed to learn 2GR into one place. I'm pretty busy with schoolwork but hopefully I can get that up within 2-3 weeks.

In the meantime though, if you have any specific questions/things you're confused about feel free to ask and I will try to explain. I check this thread pretty often
Thank you so much! This method has interested me for quite some time now, I'm very thankful for your response.
 
@crafto22 I'm sorry the explanations are so unclear. Most of what I've been posting on this thread is in-dev stuff so it's not very organized. So far the best resources for the theory behind 2GR are the first two links in my sig (I make some follow up posts after the second link, scroll down and you'll see them) and this video I made a little while back. They should give a 7/10-ish idea of how/why 2GR works.

Since I've written those things I've come up with a better way to detect and track CP during inspection and I'm working on a 2GR website to sorta collect all information needed to learn 2GR into one place. I'm pretty busy with schoolwork but hopefully I can get that up within 2-3 weeks.

In the meantime though, if you have any specific questions/things you're confused about feel free to ask and I will try to explain. I check this thread pretty often
Just outta curiosity, what is the basics behind the new recog method for the key? I really would enjoy a slightly simpler way to identify it. Thanks again
 
Hey everyone, so I have been very interested in ZZ-CT recently, but I have progressed so much with CFOP that I see little hope in ever using ZZ as my main method. I don't know if this concept has been proposed before, but it allows me to use TSLE and TTLL in my CFOP solves with the use of (on average) only one or two extra moves! And TSLE/TTLL is far more efficient than LS/OLL/PLL, of course. So here's the idea:

The solve begins as usual, with cross and the first two pairs. The next step consists of pairing up the third CE pair and using a VHLS algorithm to solve the pair along with EO. I'm able to do this quite quickly, and most VHLS algorithms are only one or two moves longer than the standard insertion, although there is of course that split second required to identify the EO case. One would then proceed with TSLE and TTLL to finish the solve.

Here's an example, since I'm almost certain my explanation was not very well written:

Scramble: U B2 R' D2 L F2 R2 D2 F2 U2 L' B2 U R B' D2 B2 R D L'

x2 // inspection
R B' R2 u' L2 // cross
y' L' U2 L U' L' U L // first pair
R U' R' f' L' f // second pair
R' U' R // CE pair
Okay now at this point the edges that need to be flipped in order to solve the pair and EO are the LU and RB edges. This is because the alg we're going to use to solve the pair is unable to affect the RF edge, simply because that's not how VHLS works. This means we are solving EO relative to the RF edge's orientation. Therefore we do it like this:
U' B L U L' B' // VHLS alg that flips LU and RB; EO is now solved
y' U R' U' R U R' U R // TSLE
y U2 R U2 R' U' R' U2 R2 U R2 U R U // a nice 2-gen TTLL

Total moves: 48 HTM

That's a pretty damn good move count for a CFOP variant if you ask me!
 
I
Hey everyone, so I have been very interested in ZZ-CT recently, but I have progressed so much with CFOP that I see little hope in ever using ZZ as my main method. I don't know if this concept has been proposed before, but it allows me to use TSLE and TTLL in my CFOP solves with the use of (on average) only one or two extra moves! And TSLE/TTLL is far more efficient than LS/OLL/PLL, of course. So here's the idea:

The solve begins as usual, with cross and the first two pairs. The next step consists of pairing up the third CE pair and using a VHLS algorithm to solve the pair along with EO. I'm able to do this quite quickly, and most VHLS algorithms are only one or two moves longer than the standard insertion, although there is of course that split second required to identify the EO case. One would then proceed with TSLE and TTLL to finish the solve.

Here's an example, since I'm almost certain my explanation was not very well written:

Scramble: U B2 R' D2 L F2 R2 D2 F2 U2 L' B2 U R B' D2 B2 R D L'

x2 // inspection
R B' R2 u' L2 // cross
y' L' U2 L U' L' U L // first pair
R U' R' f' L' f // second pair
R' U' R // CE pair
Okay now at this point the edges that need to be flipped in order to solve the pair and EO are the LU and RB edges. This is because the alg we're going to use to solve the pair is unable to affect the RF edge, simply because that's not how VHLS works. This means we are solving EO relative to the RF edge's orientation. Therefore we do it like this:
U' B L U L' B' // VHLS alg that flips LU and RB; EO is now solved
y' U R' U' R U R' U R // TSLE
y U2 R U2 R' U' R' U2 R2 U R2 U R U // a nice 2-gen TTLL

Total moves: 48 HTM

That's a pretty damn good move count for a CFOP variant if you ask me!
I thought of something like this but with VHLS and then WV, so you get an OLL skip right then. I don't think it has much advantage as something like, say, petrus.
 
I

I thought of something like this but with VHLS and then WV, so you get an OLL skip right then. I don't think it has much advantage as something like, say, petrus.
Of course, I realize standard ZZ would be much better, but this is an alternative for anyone who is either looking to switch to ZZ-CT from CFOP or who prefers to stick with the early steps of CFOP as oppose to those of ZZ in order to finish with CT.
 
Just outta curiosity, what is the basics behind the new recog method for the key? I really would enjoy a slightly simpler way to identify it. Thanks again

Basically you look at the corners that belong at DRB and DRF. Based on where they are, you can look at the permutation of 3 other corners to figure out what your LL would look like if you solved DRB + DRF with <R,U>. This lets you find out which LL corners need to be swapped.

There are simple patterns of 3 corners to look at based on where DRB and DRF are. Currently making pretty pictures to help illustrate. Should be out in the coming weeks
 
EDIT: Disregard this, I'm stupid. Original post hidden in a spoiler box.

most VHLS algorithms are only one or two moves longer than the standard insertion

People keep bringing up EO before the last slot using something like VHLS and they're all flawed in exactly the same way.

The claim you're making is false. It's "true" for normal VHLS, but not if you're orienting the edges during the third slot. You're not accounting for the cases where the edge in the last slot is misoriented, which require one or two extra triggers (i.e. 3-7 moves) to fix. Partial edge control before the last slot is definitely beneficial and I'm pretty sure every fast cuber does that, but full edge control, just so you can do TSLE/TTLL, seems pointless.

(Actually, it's not even true for normal VHLS with R U' R' insert, and definitely false for VHLS with R U R' insert. The only short cases are R U'/U2 R' (3 moves), R U R' (3 moves), sledge (4 moves) and flip + insert (6 moves, two distinct cases), so you really have only 5 good VHLS cases out of 16. (ed: I'm bad at counting; there are only 16 cases.))
 
Last edited:
People keep bringing up EO before the last slot using something like VHLS and they're all flawed in exactly the same way.

The claim you're making is false. It's "true" for normal VHLS, but not if you're orienting the edges during the third slot. You're not accounting for the cases where the edge in the last slot is misoriented, which require one or two extra triggers (i.e. 3-7 moves) to fix. Partial edge control before the last slot is definitely beneficial and I'm pretty sure every fast cuber does that, but full edge control, just so you can do TSLE/TTLL, seems pointless.

(Actually, it's not even true for normal VHLS with R U' R' insert, and definitely false for VHLS with R U R' insert. The only short cases are R U'/U2 R' (3 moves), R U R' (3 moves), sledge (4 moves) and flip + insert (6 moves, two distinct cases), so you really have only 5 good VHLS cases out of 32.)
First off, lay off the accusations, what I'm saying is NOT false, you seem to misunderstand what I'm explaining. Flipping the fourth slot edge is never necessary, and most VHLS algs are 5 moves. The standard insert is 4 moves. Where is the flaw here, exactly?
 
@xyzzy I'll concede my explanation was not very clear, but many points you are bringing up are invalid considering the way I intend to use VHLS. It isn't VHLS. It's specific VHLS algs (only 6 or 7 I believe are necessary) in order to solve EO in relation to a certain piece.

Sent from my Moto G (4) using Tapatalk
 
@xyzzy I'll concede my explanation was not very clear, but many points you are bringing up are invalid considering the way I intend to use VHLS.

Hm, okay. I was skimming through your earlier post and misread something. Apologies.

Point still remains that VHLS isn't really all that good, however. There are, in fact, only 5 out of 16 VHLS cases (counting both R U R' and R U' R' inserts) that use at most five moves, or 4 out of 8 cases if we're looking at only the R U' R' cases.

There's also the case where the last slot edge is in place, but flipped; it's rare and can be avoided most of the time anyway, so I guess it doesn't matter.
 
Hm, okay. I was skimming through your earlier post and misread something. Apologies.

Point still remains that VHLS isn't really all that good, however. There are, in fact, only 5 out of 16 VHLS cases (counting both R U R' and R U' R' inserts) that use at most five moves, or 4 out of 8 cases if we're looking at only the R U' R' cases.

There's also the case where the last slot edge is in place, but flipped; it's rare and can be avoided most of the time anyway, so I guess it doesn't matter.
Yes, I usually try to avoid the last edge in place bit flipped. I do realize this is not a fully developed concept yet, but I'm working on improvements.
 
Back
Top