The New Method / Substep / Concept Idea Thread

[wir3sandfir3s]

There is also http://lar5.com/cube/xMain.html, but I don't think they are good algorithms.

Also http://docslide.us/documents/2gll-speedcubing-algorithms.html

Thanks

 

[Shiv3r]

Wait guys, let's not discount this completely. I think it may have some OH potential.

I would still alter this slightly though.

1) 2x2x2 block in BDL,
2) EO ZZ style
3) Form 2x2x1 block in FUR and do a U2 to finish the 2x2x3 *
4) 2nd half of ZZF2L
5) LL however you would like (I like WV/ PLL)

I like the steps 2-4 as they are easier to get used to than the Eoline and (for the most part) only use R and U moves so the a lot of the ZZF2L L moves (in the first half) are eliminated leading to a mostly 2-gen mid-solve that could go straight into PLL

*an experienced solver could probably do steps 2&3 in 1 step.

What faces would you do EO for, R&F or R&U, what?
Im a OH petrus solver, but i dabble in ZZ. heck, 2H I dabble in all methods.
but this may be the big break for petrus as a OH method

 

[gyroninja]

Alright so I am going to try to fix my recently posted ideas and present a new one, as well as trying to be more organized. They all involve CP so I recommend reading Noah's CP Blocks 2.0 (at least the CP part) before reading this.
FreeFOP Meets CP Blocks
This method has a 2LLL with a grand total of 11 algorithms, as well as a fast 2-gen (mostly) F2L.
1. Solve 2 adjacent D edge pieces. I find it easiest to do the front and left ones.
2. Solve the 2 (left) pairs. Since I solved the front and left D edges, I would do the left pairs.
3. CP. Basically the same as you would do it in Noah's CP Blocks 2.0.
4. Finish F2L-1 edge using only 2-gen and M slice for EO.
5. Orient edges as you would normally do for FreeFOP while inserting the last D edge.
6. Finish LL with either a 2-gen corner OLL or a corner OLL that doesn't affect corner permutation. Then do an EPLL and your done.

Fast and Easy F2L and LL
1. Solve a 2x2x3 block and leave exactly 2 edges disoriented.
2. Solve CP like Noah's CP Blocks 2.0, and while doing the F' U F algorithm, orient the disoriented edges. I can explain into further detail if needed.
3. Solve the last D edge and use my L2S technique to finish F2L and LL. The PLL pair insertion will have reduced Algs thanks to CP.

Easy Everything
This is my favorite because it has a 77 alg 1LLL, which is 1 less alg than OLL and PLL (lol). It also is (hypothetically) pretty move efficient.
1. Solve the left Roux block. EZ
2. Solve CP as you would in Noah's CP Blocks 2.0.
3. Solve right Roux Block.
4. Solve EO and the rest of F2L. You can do this as you normally do in Roux, but my favorite way to do this is to solve FD, then orient the remaining edges and insert the last F2L edge as you would in FreeFOP.
5. 1LLL.
I tried hemming the Algs, and I genned about 250k to be reduced so I for sure get 77, but I got 35 because Cube Explorer decided to think that a solved cube is unsolved and genned Algs for that... (Which made up 70-90% of the Algs)
So if someone else can gen these Algs, that would be awesome . Edges are oriented and corners are permuted, 11 EPLLs (1 H perm, 2 Z perm, 8 U perm) multiplied by 7 corner orientations = 77.

Are you taking about 2gll for the 1lll?

 

[wir3sandfir3s]

Are you taking about 2gll for the 1lll?

I believe so.
Also, for the second one where your orient the edges while doing CP, you can finish F2L completely 2-gen and for the last slot you can phase, so you get either a z or h perm for 2gll, which only requires 21 Algs for 1LLL (2 Z perms + 1 H perm = 3 multiples by 7 corner orientations = 21). This is the same amount of Algs as PLL.

 

[Shiv3r]

Yes, check out my Roux L6E in 1-Look thread:
https://www.speedsolving.com/forum/showthread.php?60468-Roux-L6E-in-1-look

Eric Fattah
Vancouver, BC

the problem is the high alg count. for example, I just want an alg set that permutes the corners(2nd look of 2-look corners) and orients the edges

 

[gyroninja]

I believe so.
Also, for the second one where your orient the edges while doing CP, you can finish F2L completely 2-gen and for the last slot you can phase, so you get either a z or h perm for 2gll, which only requires 21 Algs for 1LLL (2 Z perms + 1 H perm = 3 multiples by 7 corner orientations = 21). This is the same amount of Algs as PLL.

Actually I believe it's 30 algs. Your method is also really close to zz-f. Although you have a different approach at cp.

 

[wir3sandfir3s]

Actually I believe it's 30 algs. Your method is also really close to zz-f. Although you have a different approach at cp.

Still less than the other. I'll check out ZZ-f

 

[xyzzy]

I briefly experimented with ZZ-f a while ago (before I learnt that someone else already came up with it and called it ZZ-f!) and I don't think it's really worth it unless you absolutely want to keep the number of algs to learn low. By phasing, you triple the probability of getting a pure corner twist case and you eliminate most of the super-fast 2GLL cases (Sune, double Sune, Bruno, U perm).

 

[wir3sandfir3s]

I briefly experimented with ZZ-f a while ago (before I learnt that someone else already came up with it and called it ZZ-f!) and I don't think it's really worth it unless you absolutely want to keep the number of algs to learn low. By phasing, you triple the probability of getting a pure corner twist case and you eliminate most of the super-fast 2GLL cases (Sune, double Sune, Bruno, U perm).

Well, it's good to get used to some 2GLL cases while your learning the rest.

 

[2180161]

What about:
EOFB
Separate U/D edges
Orient corners
Finish F2L
PLL

No idea on move-count, but I think it would be fairly efficient. Don't know how many algs either. U/D edges is intuitive, so 21 PLL+x Corner orientation algs.

Thoughts?

EDIT: 21 PLL + 27 WV for alg count. Create pseudo pairs for separate U/D, and use a WV alg.

 

[Teoidus]

I briefly experimented with ZZ-f a while ago (before I learnt that someone else already came up with it and called it ZZ-f!) and I don't think it's really worth it unless you absolutely want to keep the number of algs to learn low. By phasing, you triple the probability of getting a pure corner twist case and you eliminate most of the super-fast 2GLL cases (Sune, double Sune, Bruno, U perm).

Perhaps then it'd be better to do a sort of "anti-phasing" where you instead ensure that opposite color edges are never opposite each other?

What about:
EOFB
Separate U/D edges
Orient corners
Finish F2L
PLL

No idea on move-count, but I think it would be fairly efficient. Don't know how many algs either. U/D edges is intuitive, so 21 PLL+x Corner orientation algs.

Thoughts?

EDIT: 21 PLL + 27 WV for alg count. Create pseudo pairs for separate U/D, and use a WV alg.

I actually generated algs for something like this a while back. Dunno how it is, but I'm thinking after learning more of Roux that it might not be worth the trouble to get F2L solved.

 

[2180161]

Perhaps then it'd be better to do a sort of "anti-phasing" where you instead ensure that opposite color edges are never opposite each other?



I actually generated algs for something like this a while back. Dunno how it is, but I'm thinking after learning more of Roux that it might not be worth the trouble to get F2L solved.

You could solve your SB using [R2,U,M2], then solve the M-slice portion of the F2L, allowing for look-ahead into PLL, because you can see the permutation of the corners. i.e: Opp swap means you will have one of the following PLLs-Na,Nb,V, or Y.

 

[Teoidus]

But <R2,U,M2> imo is more awkward than <R,U,M>. The M slice can already very easily change the orientation of edges, so I don't see the need for doing EO that early. FB is tougher to plan, you have an extra step of solving the rest of F2L, and PLL isn't amazingly fast (I think just CMLL + LSE, or OLLCP+LSE if you can would be fine if not better).

I think Roux and CFOP are just two methods that can't really be hybridized in a way that produces something that somehow captures the strengths of both

Edit: Actually, if you're doing EO, it wouldn't be <R2,U,M2> unless the E slice edges have been placed. <R,U,M2> is okay, but I still feel that the method is a bit inconsistent--one of the strengths of Roux is the ability to quickly orient edges with M since you keep it open, but now you are orienting everything first.

 

[2180161]

But <R2,U,M2> imo is more awkward than <R,U,M>. The M slice can already very easily change the orientation of edges, so I don't see the need for doing EO that early. FB is tougher to plan, you have an extra step of solving the rest of F2L, and PLL isn't amazingly fast (I think just CMLL + LSE, or OLLCP+LSE if you can would be fine if not better).

I think Roux and CFOP are just two methods that can't really be hybridized in a way that produces something that somehow captures the strengths of both

Edit: Actually, if you're doing EO, it wouldn't be <R2,U,M2> unless the E slice edges have been placed. <R,U,M2> is okay, but I still feel that the method is a bit inconsistent--one of the strengths of Roux is the ability to quickly orient edges with M since you keep it open, but now you are orienting everything first.

In what way was this a hybrid of Roux and CFOP? If anything, its a combination of Roux and HTA. My apologies it is <R,U,M2> until the E-slice edges are placed. I can do an example if you like.

EDIT: Here is an example:

Spoiler

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


D' F R' B' U' R U' R2 L' U L U2 M' r L U' L'// EOFB (I'm not efficient at all, but someone else could definitely do better)

M2 U R' U R' U' R L' U' L U' L' U2 L//Separate U/D and orient corners

R2 U M2 U R2 U2 R2// SB

U M2 U M' U2 M// Finish F2L

R2 u R' U R' U' R u' R2 y' R' U R//PLL

56 STM. I think that the EOFB movecount could be reduced significantly if done properly, as well as the separate U/D +WV when done with actual WV. Still was the same move-count as an average CFOP solve, and this could easily be reduced.

 

[Teoidus]

I think I see what you mean with Roux + HTA, but I don't think it's comparble. You finish by essentially solving the F2L and performing a PLL alg--that's why it's a CFOP hybrid. You're taking ~8-10 moves to solve F2L and orient corners, but that could just as well have been used to solve CP with CMLL, or even orient edges as well with OLLCP--you don't save moves by reducing to F2L + PLL.

56STM is average for CFOP, but not good for a Roux movecount. In CFOP, you might not be as efficient, but ergonomics are great (2gen pairs), which allow you to get high tps; here, you're sacrificing visibility (M slice not solved), ergonomics (<R,U,M2> is not going to be as fast as <R,U> or <L,U>), and not getting much in exchange.

EO could also be troublesome for color neutrality, as you'd inherit problems from ZZ with edge detection being complex and hard to do on multiple fronts; without that neutrality, you'll be restricted in terms of FB choice and becuase you're trying to orient edges at the same time, can't really blockbuild as effectively. imo the tradeoff just isn't worth it; maybe better would be solving CP, kind of like Noah's CP blocks.

 

[shadowslice e]

What about:
EOFB
Separate U/D edges
Orient corners
Finish F2L
PLL

No idea on move-count, but I think it would be fairly efficient. Don't know how many algs either. U/D edges is intuitive, so 21 PLL+x Corner orientation algs.

Thoughts?

EDIT: 21 PLL + 27 WV for alg count. Create pseudo pairs for separate U/D, and use a WV alg.

Why not go with a variant of SSC where you do the edges like in ECE-EZD? I'm pretty sure that would be more efficient.

 

[2180161]

3x3 Solving Method: JAM

The JAM method. It stands for Just Another Method. Original, right?*

Anyway, the steps of the method are as follows-

EOFB- Exactly as it sounds. Orient all edges, and then solve your first block as in the Roux method. Projected Average moves- 15

E-slice+Orient Corners- Again, same as it sounds. Place the E-slice edges and orient corners. I like to do this by creating pseudo pairs with the E-slice edges and inserting the last pair with WV. Projected Average Moves- 14, Number of Algorithms-27

SB- The same as the second step of Roux, however, your moveset is now restricted to <R2,U,M2> Projected average moves-7


Finish F2L- Using <M,U>, solve your F2L, while keeping EO solved. Projected average moves-5

PLL- Final step in CFOP,ZZ,and this method. Average moves-12


Total projected move-count:53**


Pros:

Spoiler

Fairly Efficient
Low Alg count
No extremely difficult concepts to master
<R2,U,M2> is a wonderful subset

Cons:

Spoiler

Not the most efficient
EO can take some getting used to
psuedo-pairs can be a pain to make a habit of.

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


D' F R' B' U' R U' R2 L' U L U2 M' r L U' L'// EOFB
M2 U R' U R' U' R L' U' L U' L' U2 L//E-slice+Orient Corners
R2 U M2 U R2 U2 R2// SB
U M2 U M' U2 M// Finish F2L
R2 u R' U R' U' R u' R2 y' R' U R//PLL

I did not use WV in this solve, as I did not know the algorithm, and it ended up being anti-sune anyway. That solve was 54 moves, and things could have been more efficient. Someone else want to give it a try?

*sarcasm
**Not a certainty

 

[TDM]

Perhaps then it'd be better to do a sort of "anti-phasing" where you instead ensure that opposite color edges are never opposite each other?

Yeah, since posting the method ages ago I changed my mind and decided this would be better. Although there are no skips (though you could probably see those anyway,, so you could get them if you wanted) the LL would be much nicer. Yes it's almost double the algs, so actually you might as well be doing full ZZ-d, but it's faster than what I originally suggested.

 

[gyroninja]

I think I see what you mean with Roux + HTA, but I don't think it's comparble. You finish by essentially solving the F2L and performing a PLL alg--that's why it's a CFOP hybrid. You're taking ~8-10 moves to solve F2L and orient corners, but that could just as well have been used to solve CP with CMLL, or even orient edges as well with OLLCP--you don't save moves by reducing to F2L + PLL.

56STM is average for CFOP, but not good for a Roux movecount. In CFOP, you might not be as efficient, but ergonomics are great (2gen pairs), which allow you to get high tps; here, you're sacrificing visibility (M slice not solved), ergonomics (<R,U,M2> is not going to be as fast as <R,U> or <L,U>), and not getting much in exchange.

EO could also be troublesome for color neutrality, as you'd inherit problems from ZZ with edge detection being complex and hard to do on multiple fronts; without that neutrality, you'll be restricted in terms of FB choice and becuase you're trying to orient edges at the same time, can't really blockbuild as effectively. imo the tradeoff just isn't worth it; maybe better would be solving CP, kind of like Noah's CP blocks.

I think most CN roux solvers are x2 y. I'm x2 y with ZZ and have no trouble with the eo detection during inspection.

 

[Teoidus]

I think most CN roux solvers are x2 y. I'm x2 y with ZZ and have no trouble with the eo detection during inspection.

But can you see a FB at the same time? It seems like quite a lot to manage in one step, and EO doesn't seem worth it--changing where the centers are on the cube is pretty common during FB, since you're using wide turns and slice turns to pair things up, and it just seems like you'd want that freedom, which is a lot harder to manage if you're also trying to orient edges at the same time. If you're really that good with making use of inspection time and planning out 6 FB pieces + all of your bad edges, you'd probably just be better off seeing even more of your F2B.