The New Method / Substep / Concept Idea Thread

[Tony Fisher]

Wouldn't work for me because I use ZZ .

Actually it would work for you more than most since the idea is for learning a solution. It would be pointless for someone already using CFOP.

 

[Teoidus]

Theory meets practice. A random scramble from cstimer:

So it's reducing to <D,B>, with DLB piece at URF. RDF->RDB means that, if we first swap RDF with something to solve the DLF piece relative to the DLB piece, then we swap RDF with RDB, we'll get two-gen with respect to <D,B>. Let's try it!

The same position in alg.cubing.net (notice that i've circled the locations of DLF and DLB pieces, as predicted by the python script):

Now setting up the swaps as described. First an Old Pochmann alg to swap RDF with ULF to solve DLF piece relative to DLB, and then a Tperm conjugated by an R2 to swap DRF and DRB, as the script described.

And now here solving the remaining 6 corners entirely <D,B>-gen (of course in real solves you'd rotate and solve them <R,U>). Here's the whole solve on alg.cubing.net.

 

[Mastermind2368]

Actually it would work for you more than most since the idea is for learning a solution. It would be pointless for someone already using CFOP.

If I were to use it with CFOP, then that might work. But what I meant to say is I couldn't do it with the EO and all

 

[Neuro]

New LS technique: GLS (Garza Last Slot)

So this is something I've been working on for a while now, and I think that this could be very useful for most major speedsolving/FMC methods. It is a LS variant that-by using CO-allows you to correctly orient and permute all LL corners (COLLLS basically.) It also preserves EO.

You get ready to solve your LS (R U' R') and orient the U corner located where the LS corner should be and orient it so the U color is facing right (algs will be provided so if you're confused you can just do the inverse.) From here, you identify your case (looking at top corner orientation, 9 cases) and identify which corner is in UBL. Then, recognize the swap/cycle needed to permute the corners. There are 6 possible variants which are listed below.
CC- Counterclockwise: UFR->UBR->UFL
CW- Clockwise: UBR->UFR->UFL
DS- Diagonal Swap: UBR->UFL
FS- Front Swap: UFR->UFL
LS- Left Swap: UFR<->UBR (direct)
NS- No Swap: Easy to recognize, already permuted

The technique uses 54 algs and uses an average of 9.9 moves (NOT OPTIMIZED FOR SPEED) Here are the sets and algs. Let me know your thoughts and if you'd be interested in creating new algs or a better recognition method!

NEW ZZ VARIANT: ZZ-K (Kevin)

ZZ-K is a new variant of ZZ that uses concepts from ZZ-CT, but applies it to an edge rather than to a corner. Here is a general outline:

EO line
F2L-1 (in place of RD edge, you can use any U layer edge)
COLL or GLS
HKPLL+C- Edges only HKPLL

First you start off with your standard EO line, but while blockbuilding you can insert any U edge to the DR slot or use your standard DR edge. THen you use COLL to solve all U layer corners (GLS can be used, but it is a bit hard to recognize ATM and has more algs.) Move the top so that the edge that should be in DR is in UR. Finally, HKPLL+C is a subset of HKPLL that only deals with edges and has only 12 algs.

GLS VARIANT

GLS has an average movecount of 9.91 HTM, and HKPLL+C has an average movecount of 8.5 HTM, giving you a "LL skip" with an average of only 20.4 HTM (20 instead of 18 bc you usually need to turn the top to position edges correctly and correctly position LL after HKPLL+C.) This is much shorter than ZZ-CT, and would be incredibly easy to optimize. I will be providing example solves in the future.

NEW ZZ VARIANT: ZZ-M (Max)

ZZ-M is a new ZZ variant with a unique approach to EO line and LL that draws inspiration from Roux. Here is a general outline:

EO line U- Same as traditional EO line, but instead of using DF and DB edges, you can use either the UR/UL edges or the UF/UB edges
F2L-1
COLL or GLS
LSE

EO line is now freed somewhat, as you have more options as to which edges you can put into DF/DB. F2L can be solved as normal, and use COLL (GLS can be used, but it would require more algs and ATM recognition is a bit difficult.) LSE is even more efficient than normal Roux, as inserting 2 edges can be done in a minimum of 2 STM, and you don't have to worry about EO. I haven't had much time to generate stats, but I believe that this can be extremely fast, as EO line and LL have a decreased movecount from most other ZZ variants. I will provide example solves in the future.

 

[xyzzy]

(GLS) orient it so the U color is facing right

You're not accounting for the extra moves needed to do this. I think the majority of the cases require only one extra R U* R' kind of trigger to set up the corner, but some may require more. Either way, it's +3 moves two-thirds of the time unless you learn how to set up the pair while orienting the DFR corner as needed, which would then require more F2L algs.

(ZZ-K) HKPLL+C- Edges only HKPLL

Aka oriented L5E. Might be quite situational, because you usually don't save a lot of moves from not having to solve DR. On the other hand, it looks like oriented L5E with optimal algs is slightly shorter than EPLL (!!) so this might have some use for linear FMC. (But if you use speed-optimised algs, it completely loses this advantage.)

EO line U- Same as traditional EO line, but instead of using DF and DB edges, you can use either the UR/UL edges or the UF/UB edges

Been proposed at least thrice in this thread before. (The first mention is even on the first page of the thread!) Could work, but general opinion is that you could also just use <M,U> EPLL algs. Using the "wrong" edges for EOline also prevents you from using ZBLL and you'll never get an LL skip.

Edit: also, why are you taking a photo of a printout of a plain text document instead of just uploading the text files…

 

[Teoidus]

Hey, welcome to the forums!
On top of xyzzy's post I also suggest you look through shadowslice's post on method development. Don't be discouraged if your ideas have been invented before; methods are pretty well fleshed out currently.

 

[Neuro]

You're not accounting for the extra moves needed to do this. I think the majority of the cases require only one extra R U* R' kind of trigger to set up the corner, but some may require more. Either way, it's +3 moves two-thirds of the time unless you learn how to set up the pair while orienting the DFR corner as needed, which would then require more F2L algs.



Aka oriented L5E. Might be quite situational, because you usually don't save a lot of moves from not having to solve DR. On the other hand, it looks like oriented L5E with optimal algs is slightly shorter than EPLL (!!) so this might have some use for linear FMC. (But if you use speed-optimised algs, it completely loses this advantage.)



Been proposed at least thrice in this thread before. (The first mention is even on the first page of the thread!) Could work, but general opinion is that you could also just use <M,U> EPLL algs. Using the "wrong" edges for EOline also prevents you from using ZBLL and you'll never get an LL skip.

Edit: also, why are you taking a photo of a printout of a plain text document instead of just uploading the text files…

Thanks for all the feedback, helps a lot! TBH this was mostly to put out some ideas as well as get feedback/help me progress as a method designer. As for the pics of the algs, I will be replacing them with word/text docs, but I didn't generate the algs on my home computer and didn't think to make a copy in Google Drive or send them to myself. But I did have some printed versions, and I honestly couldn't be bothered to type it all out so I just made a copy of it lol.

When I developed GLS, I didnt consider the extra moves required but I definitely see the issue. As for GLS optimization, I am considering generating cases not based on CO, but the alg count would skyrocket so I'll probably just scrap GLS.

I may be wrong, but I believe that most/all of the HKPLL+C cases can be solved using 2 gen algs, so I think ZZ-K could still be useful in OH solves.

Completely understand the concerns with the EO wrong edges. I'll probably run some tests with the movecount but I'm not expecting any notable differences. May scrap this as well :/

But again, thank you for your reply and I'll definitely take this into consideration if/when I come up with other methods.

 

[Will_McC]

I recently learned the Friedrich method and its pretty fast. But then I learned the Roux method and decided to learn it too just to see which is faster. In doing so I thought of this: what if I combined them. It would look like this...

Steps 1 and 2- These would be the same first 2 steps to the Roux method (make adjacent 1x2x3 blocks)

Step 3- Put the final 2 white edges on the top to finish the first 2 layers.

Step 4- Solve the bottom using PLL and OLL just like in the Friedrich method

This method would take out F2L, the longest part of the Friedrich method and allow you to use the middle layer to make pairings. But there has to be a reason this isn't used already so can someone tell me why this isn't used by anyone?

 

[GenTheSnail]

I recently learned the Friedrich method and its pretty fast. But then I learned the Roux method and decided to learn it too just to see which is faster. In doing so I thought of this: what if I combined them. It would look like this...

Steps 1 and 2- These would be the same first 2 steps to the Roux method (make adjacent 1x2x3 blocks)

Step 3- Put the final 2 white edges on the top to finish the first 2 layers.

Step 4- Solve the bottom using PLL and OLL just like in the Friedrich method

This method would take out F2L, the longest part of the Friedrich method and allow you to use the middle layer to make pairings. But there has to be a reason this isn't used already so can someone tell me why this isn't used by anyone?

This variant has been proposed before as you suspected.
CMLL+LSE is faster/better than FD/BD+OLL+PLL, and with considerably less algorithms.

 

[Will_McC]

This variant has been proposed before as you suspected.
CMLL+LSE is faster/better than FD/BD+OLL+PLL, and with considerably less algorithms.

Is this after or slower than the Friedrich method

 

[GenTheSnail]

Is this after

???

Is this after or slower than the Friedrich method

It is basically bad roux, which is definitely slower than CFOP and Roux. Both methods are better in their pure state than when they are combined.

 

[Teoidus]

lol guys, originally I tried this out as a joke, but:

7 FB
5-6 <r,R,U> to solve 2x2x3
5 EO
12-13 F2L + phasing
14 ZZLL
= 43-45 STM

Here's the reddit post where I first pitch this to oyoat because I assume he'd be most familiar with how fast Petrus-related things can go. I also link to data I've collected to get these movecount estimates that I've given above.

This fixes the bad fingertricks/lookahead in the 2x2x3 step of Petrus (since it's <r,R,U> now and you can easily track where the two edges are going in inspection). Given that PDF is able to one-look FB + SBsquare pretty often, I wouldn't be surprised if people could be able to one-look the entire 2x2x3.

 

[shadowslice e]

lol guys, originally I tried this out as a joke, but:

7 FB
5-6 <r,R,U> to solve 2x2x3
5 EO
12-13 F2L + phasing
14 ZZLL
= 43-45 STM

Here's the reddit post where I first pitch this to oyoat because I assume he'd be most familiar with how fast Petrus-related things can go. I also link to data I've collected to get these movecount estimates that I've given above.

This fixes the bad fingertricks/lookahead in the 2x2x3 step of Petrus (since it's <r,R,U> now and you can easily track where the two edges are going in inspection). Given that PDF is able to one-look FB + SBsquare pretty often, I wouldn't be surprised if people could be able to one-look the entire 2x2x3.

I quite often use this when I do FreeFOP so I would say it's a perfectly viable alternative though EO may be better served as done in conjunction with the 2x2x3 (which is what I also sometimes do in FMC attempts at home(because I've never been to a comp))

 

[Sion]

Here is a dumb corners first method I used to help me get familliar with the M slice. it is almost entirely intuitive, and a big beginners variant of roux:

1: Solve D corners and DL and DR edges
2: CLL
After this point the whole solve is 4 gen
Using L, R, U, and M, solve the equator edges.
After this, do a lse variant and done.

I'm hoping this could help people get used to usage of the M layer as a vital tool in speedsolving and intuitive solving.

Any other thoughts on my beginners method? I'm trying to push it with people who want to learn how to solve a rubiks cube.

 

[Teoidus]

I think LSE might be confusing for people when they're just starting out

 

[Sion]

I think LSE might be confusing for people when they're just starting out

Two look ELL is a simple solution.

 

[Teoidus]

So: corners + DLDR, <L,R,U,M> for belt, place DFDB, EOLL, EPLL?

 

[Sion]

So: corners + DLDR, <L,R,U,M> for belt, place DFDB, EOLL, EPLL?

Exactly

 

[Teoidus]

Could be good. Main issue with beginners' methods is getting beginners to choose them over LBL

 

[Sion]

Here's an example solve:

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

First Corners: F2 D2 L' y2 D2 (R' D R D')3

COLL: x2 U' L' U' L U' L' U2 L

CPLL: U R' F R' B2 R F' R' B2 R2

DLDR:U2 M U2 M' R' U M' U2 M U R y

First Belt Edge: U M U' R' U M' U'

Second Belt Edge: R2 U' M' U r'

Third Belt Edge: M' L' U' M2 U L

Fourth Belt Edge: M' L U M U' L'

DFDB: M U' M2 U M' U' M U

EOLL R U R' U' M' U R U' r'

(EPLL Skip)