• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 40,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

The New Method / Substep / Concept Idea Thread

Not sure if this counts as a concept. I've been toying around with a ZZF2L thing lately, which involves moving a stuck edge to its correct centre with a D2 while breaking the line, forming a pair, attaching it to the edge with a U move while fixing the line with a simultaneous D2, and placing down the block.

Example:
 Twizzle link 
 Setup 
z2 (R U)20 (L2 U L' R U2)31 R2
 Moves 
D2 //Solve DL, break EOLine
R L' //Setup insert
(U D2) //Attach pair, fix EOLine
L R U2 L //Done
 
So Ive wondered what extension to ZB we could make and I stumbled across a variant that may make a great extension for ZB, involving pseudoF2L and offering an alternative for 1 looking 3x3 (this is what I’m unsure of, but only taking permutation into account of this method which will be explained below, I think it will offer easier access to 1 looking).

Just like with the current state in F2L, I’ve envisioned this method’s first step as a pure art form, dependent on optimized solutions and great turning, optimized solutions involving what is only accessible to those who study algorithms & analyze solves with maximal thought process (maybe not maximal but to some great extent since pure F2L is pretty hard to 1-look/get good at).

1. Reduce the cube to F2L + EO + twisted corner in DFR & random AUD (these last two are optional and are not necessarily supposed to be used, just like TCLL & EG in 2x2)

2. Use one of 1,525 (estimated) algorithms to solve the rest of the pieces with 1 algorithm

3. AUD

I calculated 1,525 algorithms by first calculating the number of possible algorithms from F2L-TC+EO reduction by multiplying the number of TCLL cases on 2x2 (86 in total) by 12 (number of edge permutations), and then adding the number of cases in ZBLL including PLL (493) to get 1,525. This number and the size of information can be compared to learning around 1,500 to 2,000 hanzi characters (or kanji characters), but at least you get the benefit of having a practical use for those characters, meanwhile you may need muscle memory to keep all 1,525 (or 1,032 minus zbll) inside your head, and alongside seemingly more ambiguous algorithms with potentially harder to remember chunks, this only begs to question whether it is possible to learn this method. I leave it to everyone for their interpretation, my interpretation about this algorithm set (1,525) is like 3*ZBLL in terms of algorithm count, first hand difficulty, and learning.

Unfortunately, due to the number of cases there are, there will definitely be tricky outliers consisting of potentially ~20 moves optimal solution. I haven’t generated any algorithms but from the lowest move count (& optimal) algorithm I could find, I would say the (again, this is only an educated guess) bounds for movecount per alg would be somewhere within [9, 22].

Some algs will be listed below that I have found.

R U R’ U R U’ R’ U’ R U2 R’ U’ R U R’
R2 U2 R’ U’ R U’ R’ U2 R’

The use of an optional misoriented corner within the D layer will allow solvers to optionally missolve corners with their respective edge in the case of a potentially better reduction solution (feel free to name it anything like F2LTC or something else I don’t have any other names). There’s been many times I’ve had an 8 mover F2L pair and my inspection planning has been knocked to the ground with this 8 mover with no other good option in sight. Probably a skill issue maybe.

With some random slow solves I’ve done trying to figure out optimality & potential eyesight at what this method/extension could average in terms of movecount, I would say it could save us 3 to 10 moves from 65 using standard CFOP on average, but I won’t guarantee a 1 second save because of the alg count, maybe more like 0.5 or 0.25 if you do not take 1 looking or partial 1 looking into account, and maybe not even a second reduction for top solvers even with 1 looking, if it does not overall appear to be more optimal than ZB.

Overall, I would compare this method/extension as having the same information density as an entire language, alongside recognition. 1,525 algorithms (1,032 minus ZBLL) won’t be practical in daily life.

I’m leaving the name up to people to decide since I think using acronyms has caught up to my thinking ability. So far I’ve thought of “ZBTC” (zbll with a twisted corner), “TZB” (similar as before, but “twisted” is in front of “ZB”, but would get confusing to call it out randomly without context), or “TCLLE(O)” (twisted corner last layer & edge (orientation).

Tell me what you all think and if this has been mentioned before. I’m not a good solver but I’m interested in notable extensions to current methods of solving.
 
QuintillionQuber said:
So Ive wondered what extension to ZB we could make and I stumbled across a variant that may make a great extension for ZB, involving pseudoF2L and offering an alternative for 1 looking 3x3 (this is what I’m unsure of, but only taking permutation into account of this method which will be explained below, I think it will offer easier access to 1 looking).

Just like with the current state in F2L, I’ve envisioned this method’s first step as a pure art form, dependent on optimized solutions and great turning, optimized solutions involving what is only accessible to those who study algorithms & analyze solves with maximal thought process (maybe not maximal but to some great extent since pure F2L is pretty hard to 1-look/get good at).

1. Reduce the cube to F2L + EO + twisted corner in DFR & random AUD (these last two are optional and are not necessarily supposed to be used, just like TCLL & EG in 2x2)

2. Use one of 1,525 (estimated) algorithms to solve the rest of the pieces with 1 algorithm

3. AUD

I calculated 1,525 algorithms by first calculating the number of possible algorithms from F2L-TC+EO reduction by multiplying the number of TCLL cases on 2x2 (86 in total) by 12 (number of edge permutations), and then adding the number of cases in ZBLL including PLL (493) to get 1,525. This number and the size of information can be compared to learning around 1,500 to 2,000 hanzi characters (or kanji characters), but at least you get the benefit of having a practical use for those characters, meanwhile you may need muscle memory to keep all 1,525 (or 1,032 minus zbll) inside your head, and alongside seemingly more ambiguous algorithms with potentially harder to remember chunks, this only begs to question whether it is possible to learn this method. I leave it to everyone for their interpretation, my interpretation about this algorithm set (1,525) is like 3*ZBLL in terms of algorithm count, first hand difficulty, and learning.

Unfortunately, due to the number of cases there are, there will definitely be tricky outliers consisting of potentially ~20 moves optimal solution. I haven’t generated any algorithms but from the lowest move count (& optimal) algorithm I could find, I would say the (again, this is only an educated guess) bounds for movecount per alg would be somewhere within [9, 22].

Some algs will be listed below that I have found.

R U R’ U R U’ R’ U’ R U2 R’ U’ R U R’
R2 U2 R’ U’ R U’ R’ U2 R’

The use of an optional misoriented corner within the D layer will allow solvers to optionally missolve corners with their respective edge in the case of a potentially better reduction solution (feel free to name it anything like F2LTC or something else I don’t have any other names). There’s been many times I’ve had an 8 mover F2L pair and my inspection planning has been knocked to the ground with this 8 mover with no other good option in sight. Probably a skill issue maybe.

With some random slow solves I’ve done trying to figure out optimality & potential eyesight at what this method/extension could average in terms of movecount, I would say it could save us 3 to 10 moves from 65 using standard CFOP on average, but I won’t guarantee a 1 second save because of the alg count, maybe more like 0.5 or 0.25 if you do not take 1 looking or partial 1 looking into account, and maybe not even a second reduction for top solvers even with 1 looking, if it does not overall appear to be more optimal than ZB.

Overall, I would compare this method/extension as having the same information density as an entire language, alongside recognition. 1,525 algorithms (1,032 minus ZBLL) won’t be practical in daily life.

I’m leaving the name up to people to decide since I think using acronyms has caught up to my thinking ability. So far I’ve thought of “ZBTC” (zbll with a twisted corner), “TZB” (similar as before, but “twisted” is in front of “ZB”, but would get confusing to call it out randomly without context), or “TCLLE(O)” (twisted corner last layer & edge (orientation).

Tell me what you all think and if this has been mentioned before. I’m not a good solver but I’m interested in notable extensions to current methods of solving.
Click to expand...
I have seen this before, I believe it was called TZBLL or smth
 
I thought of an LSLL variant for CFOP and I'll just post it here because why not:

1. Last pair corner + EO
2. Last pair edge + CP
3. 2GLL

Honestly, I don't think this is a good idea. It's more algs than LS+OLL+PLL while still being 3 looks, you'll have to have your last slot in FR, and you have to recognize CP which is why I think this probably sucks. My reasoning for doing EO with the last corner instead of the last edge was to make CP recog the same as COLL recognition but even then it will probably be a problem. But maybe this could be of value so I'm just going to share it anyway
 
CubingPig said:
I thought of an LSLL variant for CFOP and I'll just post it here because why not:

1. Last pair corner + EO
2. Last pair edge + CP
3. 2GLL

Honestly, I don't think this is a good idea. It's more algs than LS+OLL+PLL while still being 3 looks, you'll have to have your last slot in FR, and you have to recognize CP which is why I think this probably sucks. My reasoning for doing EO with the last corner instead of the last edge was to make CP recog the same as COLL recognition but even then it will probably be a problem. But maybe this could be of value so I'm just going to share it anyway
Click to expand...
Thought of this as a joke method a while ago and called it epidote-ls or smth, I am prob not first person to think of it either tho
 
CubingPig said:
I thought of an LSLL variant for CFOP and I'll just post it here because why not:

1. Last pair corner + EO
2. Last pair edge + CP
3. 2GLL

Honestly, I don't think this is a good idea. It's more algs than LS+OLL+PLL while still being 3 looks, you'll have to have your last slot in FR, and you have to recognize CP which is why I think this probably sucks. My reasoning for doing EO with the last corner instead of the last edge was to make CP recog the same as COLL recognition but even then it will probably be a problem. But maybe this could be of value so I'm just going to share it anyway
Click to expand...
Last pair corner + EO seems about as fast as regular LS. So, you're effectively replacing OLL with last pair edge + CP, and PLL with 2GLL. Last pair edge + CP is probably about equal to OLL, but 2GLL is certainly slower than PLL in both recognition and execution time.

It's always an enticing thought to somehow combine LS + LL, but few methods of doing so exist that aren't simply worse than keeping them separate. It's useful to have certain tricks up your sleeve, like good Winter Variation or Magic Wondeful cases in addition to simple edge control, but these are far from a complete redesign of LS + LL.

Keep at it, though, you never know when you'll stumble across something great :)
 
2-Look WaterRoux:
- FB, back half of SB, L5C in 1-look (514 algs)
- L7E in 1-look (? 1000 algorithms)

EPLL-WaterRoux, 3-look
- FB, back half of SB, L5C in 1-look (514 algs)
- Solve DF,DB,FR while simultaneously orienting the upper 4 edges (?500 algorithms?)
- EPLL (4 algs)
 
New idea today - basically considering that ZZ-CT is kind of like the "OLL/PLL" of LSLL with orientation+edge and permutation+corner, I wondered about the idea of having a "CLL/ELL" of LSLL. Now doing L5C would make this variant instantly unviable as it has 614 cases just to solve them so at that point, you might as well just learn ZZ-A. So I had the idea of having the last F2L corner being inserted in its slot in any orientation then solving the LL corners while twisting that corner -- twisty COLL. This would only have 128 cases (42 COLL, 43 TCOLL-, 43 TCOLL+). Then, the last step would be L5EP with FR which would have 16 cases, so in total it would need 144 algorithms, thus making maintenance of this variant far easier and lower effort than the 493 algs of ZZ-a. I'm unsure of the quality of TCOLL algs or if they have even been generated at all, but I have been told that L5EP for FR is mostly decent, although there are some nasty cases. DoorKehStrah on the ZZ Method Server also proposed the idea of combining EOCross with the one twisted corner. Perhaps we could call this an EOTwistyFish lol :p. Starting with an EOTF would make it a genuine 2LLSLL. I'd love to hear your thoughts on this variant proposal and how y'all think it stacks up against OP and A.
 
CubingPig said:
New idea today - basically considering that ZZ-CT is kind of like the "OLL/PLL" of LSLL with orientation+edge and permutation+corner, I wondered about the idea of having a "CLL/ELL" of LSLL. Now doing L5C would make this variant instantly unviable as it has 614 cases just to solve them so at that point, you might as well just learn ZZ-A. So I had the idea of having the last F2L corner being inserted in its slot in any orientation then solving the LL corners while twisting that corner -- twisty COLL. This would only have 128 cases (42 COLL, 43 TCOLL-, 43 TCOLL+). Then, the last step would be L5EP with FR which would have 16 cases, so in total it would need 144 algorithms, thus making maintenance of this variant far easier and lower effort than the 493 algs of ZZ-a. I'm unsure of the quality of TCOLL algs or if they have even been generated at all, but I have been told that L5EP for FR is mostly decent, although there are some nasty cases. DoorKehStrah on the ZZ Method Server also proposed the idea of combining EOCross with the one twisted corner. Perhaps we could call this an EOTwistyFish lol :p. Starting with an EOTF would make it a genuine 2LLSLL. I'd love to hear your thoughts on this variant proposal and how y'all think it stacks up against OP and A.
Click to expand...
Sounds similar to zipper
 
What if, after EO223, for a fixed colour scheme (eg: yellow top, green front) you just memorise all possible corner colour patterns and then you recognise which swap needs to be done? And I don't mean piece relationships, I meant, literally memorise the actual colours (red green yellow, orange white blue, etc)
There are 6!=720 CP cases, but that's counting AUF. Wouldn't it be 720/4=180 if we found a way to standardise the "recog angle"? Maybe invent some rules, like:
"If there are two yellow stickers on the top forming a bar, hold them on the left", or "if they're diagonals, hold them in a slash position", or "if there is only one, keep it in UBL", etc.
Then you just drill those 180 colour recog cases and apply a short trigger to swap the corners around. I think you only need 6 but maybe I'm wrong
 
Last edited:
edward_9x said:
What if, after EO223, for a fixed colour scheme (eg: yellow top, green front) you just memorise all possible corner colour patterns and then you recognise which swap needs to be done? And I don't mean piece relationships, I meant, literally memorise the actual colours (red green yellow, red orange green, etc)
There are 6!=720 CP cases, but that's counting AUF. Wouldn't it be 720/4=180 if we found a way to standardise the "recog angle"? Maybe invent some rules, like:
"If there are two yellow stickers on the top forming a bar, hold them on the left", or "if they're diagonals, hold them in a slash position", or "if there is only one, keep it in UBL", etc.
Then you just drill those 180 colour recog cases and apply a short trigger to swap the corners around. I think you only need 6 but maybe I'm wrong
Click to expand...
This is the idea behind PCP recognition. The original idea was to check two corner orientations. For example, the orientation formed by the corner UD stickers and the orientation of the LR stickers. This will tell the location of the swap. For now I have only developed the version of looking for specific stickers.
 
You must log in or register to reply here.

Similar threads

Dane man
Calculating Method/Substep Efficiency
2
Replies
27
Views
5,814
brododragon
brododragon
M
What method is this?
2
Replies
24
Views
3,946
~Adam~
~Adam~
I
CFCE variant
Replies
4
Views
112
iqv124
I
StarStarSpace
CMLL-Skip (1/161) method proposal
Replies
7
Views
217
eeeeeeeee
eeeeeeeee
Filipe Teixeira
[Method of Learning] "WOODPECKER METHOD", does it have a good application in cubing?
Replies
2
Views
189
Registrau
Registrau
Back
Top