The New Method / Substep / Concept Idea Thread

[Pyjam]

BLockbuilding left right reduction method (BLRRM)

1. build a 1x2x3 intuitively on l
2. build solve the half cross that's on the d layer and the m slice while orientating the the edges
3. solve the rest of the cube with just R and U moves (sometimes u get parity, you can fix that by using commutatators)

It's a wonderful method.
We call it Leor, for Left – Edge Orientation (and middle slice) – Right

You can't finish the cube with <R, U> only unless you solve the corner permutation during step 1 (and that is really hard).
But you can build the right block with <R, U> only and the last layer with the method of your choice.

 

[Hazel]

idea~
1) 2x2x3 in bottom-back minus DB edge
2a) Solve FR, FL, and FD edges
2b) DB+EO
3) Last 2 corners + LL (not sure what the best way of doing this would be)

 

[Abram Lookadoo]

new method (bepp)

1) 2x2x3 block

1a) 2x2x2 block
create a 2x2x2 block

1b) 1x2x2 block
create an adjacent 1x2x2 block and attach it to the 2x2x2 block

2) eo
orient all edges and solve DF (with block in DB)

3) pairs

3a) forge pairs
forge the 2 remaining f2l pairs anywhere on the cube

3b) l2p+co
using an algorithm place the final 2 pairs while orienting all corners (1/115)

4) pll
permute all last layer pieces

 

[Thom S.]

new method (bepp)

1) 2x2x3 block

1a) 2x2x2 block
create a 2x2x2 block

1b) 1x2x2 block
create an adjacent 1x2x2 block and attach it to the 2x2x2 block

2) eo
orient all edges and solve DF (with block in DB)

3) pairs

3a) forge pairs
forge the 2 remaining f2l pairs anywhere on the cube

3b) l2p+co
using an algorithm place the final 2 pairs while orienting all corners (1/115)

4) pll
permute all last layer pieces

At first, that's really similar to Petrus, but undebately worse.
My suggestion for you would be to just insert the last pair with Winter Variation or Summer variation(or even leave out EO and do VLS if you want to become a crazy dude), dealing with whole pairs or corners while trying to do something efficient.

Although your Idea to solve EO and DR/DL at the same time could result in some helpful algorithms

 

[Cubow]

ZZ-B+

So as I know phasing just permutes the Edges so they are opposite to each other, but it doesnt completely permute them (correct me if I am wrong).

ZZ-B is a method, that uses phasing to reduce the LL algs to around 160-170

However, with Phasing, that completely orients the Edges we would have a CxLL Case. If my Calculations are correct it would be around 50 Algs for 1LLL.


Seems unrealistic because 1LLL with 50 algs would revolutionize (I am german, sorry for bad english) Speedcubing.

Would it work?

Btw this is my first post on speedsolving.com

 

[Teoidus]

It would give you a very small "1LLL" set, but it's a lot of work to permute edges fully, and for not much benefit (L4C isn't amazing)

Also, welcome to the forums

 

[Cubow]

It would give you a very small "1LLL" set, but it's a lot of work to permute edges fully, and for not much benefit (L4C isn't amazing)

Also, welcome to the forums

That idea is the Reason why I signed up ^^

Before I signed up (20 min ago) I played a bit around with my cube. Permuting the edges while solving last F2L pair would be only 6 cases. 6 Easy cases, around 7 moves with triggers only (RUR‘ and that stuff). So it wouldnt be hard. And then... 50 LLL Cases...

Seems unrealistic, that no one thought about that before so I guess I made a mistake somewhere... This cant work

Edit: Just looked it up, it would be around 86 algs with an average movecount of 12.
Seems ok to me for a 1LLL. The avg movecount would be even less than ZBLL then but with easier recognition and less algs. However, phasing+ would be around 5 moves more for F2L than with normal ZZ but because of the recognition of ZBLL being really hard, ZZ-B+ so phasing+ (thats how I call it ) + L4C may be even faster than ZBLL...

With just 86 algs. Well, thats an achievement

 

[Thom S.]

This cant work

Well, L4C is already 84 Algorithms so it's a bit bigger than 50 but still, it would have been a really good idea if L4C were a good set, unfortunitely it's considered to have the worst Last Layer cases.
I'd love to see what you/we can come up with different phasing things.

 

[Pyjam]

Recognition for edge permutation before the corners are oriented is also quite difficult to achieve quickly.

 

[Tao Yu]

CPLS -> 2GLL is probably a better idea in a similar vein, because 2GLL algs are faster:

1. Make a pair
2. Insert pair while forcing a 2GLL case (6 algs)
3. 2GLL (84 algs)

or

1. Insert FR edge
2. Solve DFR corner while forcing a 2GLL case (30 algs)
3. 2GLL

(Algs for the second step are here)

 

[Hazel]

CPLS -> 2GLL is probably a better idea in a similar vein, because 2GLL algs are faster:

1. Make a pair
2. Insert pair while forcing a 2GLL case (6 algs)
3. 2GLL (84 algs)

or

1. Insert FR edge
2. Solve DFR corner while forcing a 2GLL case (30 algs)
3. 2GLL

(Algs are here)

If you expanded it to any F2L-1 method (CFOP, blockbuilding, etc.) then you could insert the FR edge while orienting LL edges as step 1 and you wouldn't have to do things like EOLine

 

[Cubow]

If you expanded it to any F2L-1 method (CFOP, blockbuilding, etc.) then you could insert the FR edge while orienting LL edges as step 1 and you wouldn't have to do things like EOLine

EOLine doesnt only give you oriented edges on the last layer, but you also dont have to do cube rotations

 

[Cubow]

CPLS -> 2GLL is probably a better idea in a similar vein, because 2GLL algs are faster:

1. Make a pair
2. Insert pair while forcing a 2GLL case (6 algs)
3. 2GLL (84 algs)

or

1. Insert FR edge
2. Solve DFR corner while forcing a 2GLL case (30 algs)
3. 2GLL

(Algs are here)

I understand the first part but not the second, however it sounds like a good idea.
A 2GLL-Case is btw a case where corners are permuted and edges oriented.
Using ZZ or any other EO method Edges would already be oriented however I can imagine cornerpermutation being hard.
As corners arent oriented recognition could be a big problem.

 

[shadowslice e]

EOLine doesnt only give you oriented edges on the last layer, but you also dont have to do cube rotations

Yes though at the same time you could also do something akin to FB->2x2x3->EO and still get no cube rotations. You can arguably also have betters lookahead.

I understand the first part but not the second, however it sounds like a good idea.
A 2GLL-Case is btw a case where corners are permuted and edges oriented.
Using ZZ or any other EO method Edges would already be oriented however I can imagine cornerpermutation being hard.
As corners arent oriented recognition could be a big problem.

I think he knows exactly what 2GLL is (you might want to look up his yt)
Also, the recognition for 2GLL is actually reasonably simple especially when compared to things such as ZBLL so misoriented corners would be fine. In fact, you only really need to look at the orientation of the corners and 2 edges to work out any case.

Also, please don't double post. If you feel like you want to add something or reply to another comment edit the original post. Your analysis is good and it looks like you're beginning to get a sense of what is good and what is bad but remember there are still rules on the forum to follow

 

[Cubow]

Yes though at the same time you could also do something akin to FB->2x2x3->EO and still get no cube rotations. You can arguably also have betters lookahead.

I think he knows exactly what 2GLL is (you might want to look up his yt)
Also, the recognition for 2GLL is actually reasonably simple especially when compared to things such as ZBLL so misoriented corners would be fine. In fact, you only really need to look at the orientation of the corners and 2 edges to work out any case.

Also, please don't double post. If you feel like you want to add something or reply to another comment edit the original post. Your analysis is good and it looks like you're beginning to get a sense of what is good and what is bad but remember there are still rules on the forum to follow

Ok. Btw I had to look up what 2GLL is so I just explained it quickly for others who read this post who dont know ^^

But I think in general for a new efficient method the best base to start with is ZZ. It has blockbuilding which is more efficient than F2L in CFOP for example. Because its 3-Gen (Edges already oriented) there are no cuberotations and I personally think that recognition is alot easier when edges are already oriented, than if they arent.
ZZ basically combines Roux (blockbuilding, no cube rotations) with CFOP (easy F2L) for the first to layers + EO which is a small step with huge impact. I guess ZZ right now is the best method for the „future“ as it also allows more variants than Roux for example. ZZ makes also 1LLL possible which may be the standard for future speedsolving. I guess we should focus on LS-techniques (phasing). However it looks like there basically cant be anything new about phasing so we need different approaches to find a more effective way for LL+F2L. ZZ-CT is a good example, I heard that Chris Tran once said „Think outside the box“. I guess thats a good example.

Or maybe we should search for a completely different basemethod, Petrus also seems promising. Lars Petrus said on his website „A good Method does always something useful“. Maybe we should think about something different than solving a last-layer, Roux for example which solves LSE at the end. A last layer however always involves breaking something which gets us to long algorithms and while we do those it doesnt „always do something useful“.
As I said ZZ seems promising, especially compared to ZZ but a completely new method „Thinking outside the box“ + „Does always something useful“ would be really interesting. I guess we should get away from our „LBL“ thinking for that, maybe even without blockbuilding like in petrus. This sound weird but I feel like that the „LBL“ approach limits us in certain ways


That was a long post
Sorry when I missed the topic a bit, its just some general ideas of how a new method „could“ look like. Maybe you already knew all what I wrote but thats just what came into my mind rn

 

[Pyjam]

But I think in general for a new efficient method the best base to start with is ZZ.

I have been using ZZ for many years and then I've switched to Leor which I think is a step forward.
Leor is ZZ with the first two steps reversed: Left block first (à la Roux) then EO-line.

For me, Leor has many advantages over ZZ:
1) You take profit of pieces already in good place for a quick first block.
2) After step 1, there are no L moves until the last layer. At leat no L-moves during F2L.
3) During step 2 (EO-line), you may influence step 3 (right block); or sometimes a large part of the right block is done.
See: example 1, example 2.
4) The method is very flexible: you may start to orient the edges at the end of step 1; you may start to build the right block during step 2; you may do a partial EO-line, then complete the right block, then finish EO-line... You adapt to the situation.
5) Leor works very well for 4x4 too. See: four examples.

For the last layer, I've found that building the right block minus 1 edge then doing COLL + L5EPLL is more efficient (thanks to Justin Taylor), because L5EPLL adds only 24 algs over EPLL (12 for each edge FR and BR, but many are obvious mirrors) but they are not longer than EPLL algs and sometime they are shorter. Moreover Right block -1 edge is easier to perform (when building a complete right block is easy, I do it, of course).

It takes time to become accustomed to the different way to do the EO-line. It needs a lot of practice to find some tricks.

Overall, the ergonomics is better than ZZ, with a lot of possible optimizations.
And the method is fun because all 4 steps are very different.

You can find many examples I've posted in the 3x3x3 example solves thread.

 

[efattah]

While I think ZZ variants can be fast, I have stated earlier in the thread that after great experimentation with many different methods I believe the future of speed solving will be in direct solving, rather than anything that relies heavily on orienting a large number of pieces then solving them afterwards. While the fastest solvers would be direct-solvers, a great majority of cubers might still use orient-permute methods due to easier recognition and fewer algorithms. So it depends which group you are developing for.

 

[Y2k1]

I have been using ZZ for many years and then I've switched to Leor which I think is a step forward.
Leor is ZZ with the first two steps reversed: Left block first (à la Roux) then EO-line.

For me, Leor has many advantages over ZZ:
1) You take profit of pieces already in good place for a quick first block.
2) After step 1, there are no L moves until the last layer. At leat no L-moves during F2L.
3) During step 2 (EO-line), you may influence step 3 (right block); or sometimes a large part of the right block is done.
See: example 1, example 2.
4) The method is very flexible: you may start to orient the edges at the end of step 1; you may start to build the right block during step 2; you may do a partial EO-line, then complete the right block, then finish EO-line... You adapt to the situation.
5) Leor works very well for 4x4 too. See: four examples.

For the last layer, I've found that building the right block minus 1 edge then doing COLL + L5EPLL is more efficient (thanks to Justin Taylor), because L5EPLL adds only 24 algs over EPLL (12 for each edge FR and BR, but many are obvious mirrors) but they are not longer than EPLL algs and sometime they are shorter. Moreover Right block -1 edge is easier to perform (when building a complete right block is easy, I do it, of course).

It takes time to become accustomed to the different way to do the EO-line. It needs a lot of practice to find some tricks.

Overall, the ergonomics is better than ZZ, with a lot of possible optimizations.
And the method is fun because all 4 steps are very different.

You can find many examples I've posted in the 3x3x3 example solves thread.

This sounds interesting. Can I have a link to the algs for L5EPLL? (Sorry if posted earlier I havent seen these algs earlier.

 

[Pyjam]

Can I have a link to the algs for L5EPLL? (Sorry if posted earlier I havent seen these algs earlier.

I got them from Justin Taylor. Micki and him generated the biggest part of them. My contribution is minor.

 

[shadowslice e]

Ok. Btw I had to look up what 2GLL is so I just explained it quickly for others who read this post who dont know ^^

But I think in general for a new efficient method the best base to start with is ZZ. It has blockbuilding which is more efficient than F2L in CFOP for example. Because its 3-Gen (Edges already oriented) there are no cuberotations and I personally think that recognition is alot easier when edges are already oriented, than if they arent.

It really depends on the alg set in my experience. The main problem I have with ZZ is all the L moves which force regrips. It could be good but I find that the EoLine does too little and can often impede lookahead.

ZZ basically combines Roux (blockbuilding, no cube rotations) with CFOP (easy F2L) for the first to layers + EO which is a small step with huge impact.

I would be hesitant to say that ZZ combines the best aspects of Roux and ZZ because Roux benefits as it has very unrestricted free block building. It also has a harder F2L than CFOP. Instead of saying that it combines them I would say it walks a middle path on which it can't fully benefit from either aspect (not to say it couldn't be good but it isn't as straight forward as "it combines the best of Roux/CFOP".

I guess ZZ right now is the best method for the „future“ as it also allows more variants than Roux for example.

I would be very cautious in saying that more variants makes a method better. While you could make an argument that more variants=more areas to improve though at the same time a lot of the variants contradict each other so you can only use a handful at a time.

ZZ makes also 1LLL possible which may be the standard for future speedsolving. I guess we should focus on LS-techniques (phasing). However it looks like there basically cant be anything new about phasing so we need different approaches to find a more effective way for LL+F2L. ZZ-CT is a good example, I heard that Chris Tran once said „Think outside the box“. I guess thats a good example.

LS techniques consist a far larger array than simply phasing (though phasing can be an ok technique when transitioning to ZBLL). ZZ-CT is also not very good at all. In fact, I think the general consensus is that it is worse than COLL/EPLL (the misconception is mostly due to the fact that Chris Tran is very good at marketing- incidentally I would consider most of what he says suspect until I get proof of the things he says, also, CT predates his proposal by a fair bit).

Or maybe we should search for a completely different basemethod, Petrus also seems promising. Lars Petrus said on his website „A good Method does always something useful“. Maybe we should think about something different than solving a last-layer, Roux for example which solves LSE at the end. A last layer however always involves breaking something which gets us to long algorithms and while we do those it doesnt „always do something useful“.

Personally I think that this is probably the way to go. Incidentally you might want to have a look at
this thread I posted on how current methods seem to fall into 2 camps in general and why some have more variants than others

As I said ZZ seems promising, especially compared to ZZ but a completely new method „Thinking outside the box“ + „Does always something useful“ would be really interesting. I guess we should get away from our „LBL“ thinking for that, maybe even without blockbuilding like in petrus. This sound weird but I feel like that the „LBL“ approach limits us in certain ways

You might find a few more recent methods fairly interesting and see the variations that modern cubing has begun to cover (and a lot of them don't actually end in LL or use LBL) I would give Leor, SSC, PCMS, 2GR, M-CELL, ZB, 42 and LMCF a quite glance and maybe try to evaluate why they are good or perhaps not quite as viable.

I also made a thread which compiles quite a few different resources which method developers might want to take a look at. Harcs and cube explorer are also good for quick evaluation of basic methods.

Anyway, I hope this doesn't induce wall of text syndrome too much and I wish you all the best in your future explorations!