The New Method / Substep / Concept Idea Thread

[xyzzy]

This would reduces the number of ZBLL cases but phasing is an easier way to reach the same goal.

Having three pieces pre-solved (either a line (2c1e) or a square (1c2e)) reduces the number of cases far more than phasing does, which essentially is just having two pieces pre-solved.

Also, this idea was proposed before (see somewhere around page 110), and indeed nobody uses it because setting up the line is too hard for too little gain.

 

[Pyjam]

Let's consider ZZ-Tripod. I have a question:
When the blocks are made and the FR edge is solved with sexy moves, how many cases are there for the last 2 edges and last 4 corners (if we want to solve them 1-look) ?

A sample here. I'd like to merge the last 2 steps in 1.
Thanks.

EDIT: There are likely more cases than ZBLL because some symetries are broken.

But after FR is solved there could be a good 2LLL to develop (if not already done).

 

[Pyjam]

ZZ-Tripod with solved edges in FR :

I think the number of algs required to solve the LL 2-look is ridiculously low.
If the last 2 edges are swapped then solve them and 1 corner with one of these 9 algs:

PLL V (if the FRU corner is already solved)
PLL Ja (if the BRU corner is already solved)
PLL Jb (if the FLU corner is already solved)
U2 R2' D' r U2 r' D R U2 R U'
U R' U2 R' D' r U2 r' D R2 U2
U R U' R' U2 R L U' R' U L' U
U2 R U2 R D r' U2 r D' R2' U'
U R2 D r' U2 r D' R' U2 R' U2
U2 R' U R U2' R' L' U R U' L

…then solve the L3C.

Bad cases are: White corner in its slot with bad orientation (Solved by 3x Sexy Moves). Others?

If the last 2 edges aren't swapped, it's even easier to solve the cube.

I suppose all this is already known since… 1982 ?

 

[xyzzy]

When the blocks are made and the FR edge is solved with sexy moves, how many cases are there for the last 2 edges and last 4 corners (if we want to solve them 1-look) ?

12 (corner permutation) × 27 (corner orientation) = 324 cases. Less than ZBLL, but not by much.

E: This is assuming you're not counting the L4C cases; that would increase the case count a bit. The L4C cases can have the following CP: solved, two 2-cycles, 3-cycle clockwise, 3-cycle anticlockwise. For the first category, there are 7 cases; for the other three categories, there are 27 cases each. In total, this would be 88 L4C cases, or 412 in total.

 

[Pyjam]

I've found that indeed but I doubled it because there are 2 cases for the last 2 edges (so it allows for a permutation of the last 2 corners). I am wrong?

I wonder if it is possible to solve one more corner just by doing cycles of sexy moves...

EDIT: If I remember well, I'v read somewhere that it's possible to solve the cube with sexy moves only.

 

[Shiv3r]

Joking about ZZ Magic !?!?! ITS BEAUTIFUL!!!!!!

We all know ZZ Magic right? the forced LL skip by solving the LR Faces??? Well.... Here's a new way to make it viable!!!

While putting in your LS, solve a 1x1x3 bar on U.... Then... use one of 17 algs to solve the other bar and BOOM. LL DONE!!!

All jokes aside, if you solve a 1x1x3 bar on the U layer, you reduce ZBLL sets to just T and U ZBLL each of which have only 6 algs, and PLL which has 5. I wouldn't ever use this because finding a bar can be hard as well as inefficient. Some people might find it interesting. Oh and it removes the magic aspect b/c you so an LL alg to get an LL skip

I already did this "ZZ-magic" thing with Jtwong71 about a year ago. but we did it this way, which is pretty inefficient but is very alg-light(about as many as full PLL TOTAL):
-ZZF2L-1
-build a U layer corner-edge pair and an F2L pair.
-place the U-layer pair in the F2L slot and AUF the F2L pair to ULB, then use one of 9? algs to place the F2L pair and solve the line(algs here)(note, I think there's one alg missing here idk why)
-Solve the LL with EO and the Line solved. 12 cases, here are algs

 

[xyzzy]

I've found that indeed but I doubled it because there are 2 cases for the last 2 edges (so it allows for a permutation of the last 2 corners). I am wrong?

You're right; I missed that. I edited my earlier post to include that.

EDIT: If I remember well, I'v read somewhere that it's possible to solve the cube with sexy moves only.

Do you mean something like the sexy method (or 8355 or another of its close relatives)? Or do you mean four-move triggers like sledgehammer that preserve the three 2×2 blocks on the U, R and F faces?

 

[Pyjam]

Thank you.

It was thinking about the sexy method.

 

[Shiv3r]

Anyway, I have been using Squan LBL, aka Jason Baum method aka "whatever the F**k that nub Helmer Ewert does"(quoted verbatim from a conversation I had a few months ago), and have been trying(and failing) To learn Lin.

I just want to talk a little about these methods and would like to ask if anyone wants to help me try to develop these.

quick recap of what the LBL-style method is:
1.Cubeshape/CSP
2.roux F2B
3.Insert DF and DB edges
4.PLL(I do 2look, corners-edges)

and Lin:
-steps 1&2 of "LBL"
-insert either D layer edge then use one of 6 CP+Df algs to insert the final edge and solve CP
-EPLL
I am x2 y with the first method, and if I learned Lin I would be x2 y with it as well. that seems weird, but it's actually pretty easy. if you solve the blocks that actually go on U when you're doing Roux blocks, you just cancel your PLL into /(6,6)/ at the end.
So anyway, Lin method has less algs(it's what Robert Yau uses, there are only 6 cases), but I think the LBL-esque method seems just as good, if more alg-intensive.
In fact, the Lin method is MORE efficient than the first one, due to the fact that all the CP+DF algs are the same length, which means that you force EPLL in the same amount of slices as the first method takes to get to PLL. I don't know the PLL vs. EPLL movecounts(inc. parity) but I do know that the only problem with Lin is that recognition for DFDB can be a little complicated. However, Helmer Ewert Had the squan WR single for a week or two with the first method, so it is decent.
Any thoughts/suggestions on improvements?

 

[Teoidus]

@Sue Doenim mentioned a pretty good improvement to this a while back, which was something along the lines of:

Cubeshape
F2B + DB edge
HKPLL

 

[Neuro]

What I'd do is this

1: Cubeshape
2: F2B
3: Insert 1 DB edge while doing CP (you can do preexisting Lin algs but this may be more efficient)
4: L5EP (not sure about alg #, probably >100 including parity stuff)

HKPLL on squan would have an insane # of algs unless you did CSP

 

[Teoidus]

That requires 1 additional step, which I'm not sure is needed. HKPLL with CSP is ~128 algs, so wouldn't HKPLL without CSP be ~256 algs? That's a lot, but it doesn't seem insane to me.

 

[Neuro]

Ok so something similar exists to my proposed one called Yau-1 that does the following

1: Cubeshape
2: 3/4 D layer (1 edge and 1 corner missing)
3: L5C
4: L5E

Also, found an algsheet for this method. There aren't any case images but it's still easy to follow. Here's the link. It has 33 L5E algs on it, so either L5EP has much less algs than I thought or it's incomplete. I suspect the prior though, as L5EP on 3x3 has 16 algs so w/parity should give you 32 or so. Assuming the algcount of 33 is correct, for both Yau 1 and my method you only need 39 algs in comparison to 256.

I know that 256 is doable, but I'm thinking of the overall recognition. I'm probably just skeptical but it seems like with that many cases you get a lot of cases that look very similar and thus confusion ensues. Most people don't know PLL on Squan for much the same reason. It's probably more efficient, but not worth it IMO.

 

[Sue Doenim]

Ok so something similar exists to my proposed one called Yau-1 that does the following

1: Cubeshape
2: 3/4 D layer (1 edge and 1 corner missing)
3: L5C
4: L5E

Also, found an algsheet for this method. There aren't any case images but it's still easy to follow. Here's the link. It has 33 L5E algs on it, so either L5EP has much less algs than I thought or it's incomplete. I suspect the prior though, as L5EP on 3x3 has 16 algs so w/parity should give you 32 or so. Assuming the algcount of 33 is correct, for both Yau 1 and my method you only need 39 algs in comparison to 256.

I know that 256 is doable, but I'm thinking of the overall recognition. I'm probably just skeptical but it seems like with that many cases you get a lot of cases that look very similar and thus confusion ensues. Most people don't know PLL on Squan for much the same reason. It's probably more efficient, but not worth it IMO.

First off, I agree that my method is not good unless you want to be fast. My original post on it was talking about how the latest WR is a fluke, and how we can get similar movecounts. It is really designed for use with cubeshape parity, as it's point is to try and minimize movecount as greatly as possible, so it would only have ~128 algs.
I feel like recognition would actually be really quite good, better than TTLL even. Since CP is detectable from any angle on the U layer, all that's left to determine is EP. The D layer edge is always easy to identify, as it will always be visible or solved. Then you only need to determine the permutation of 2 more edges, since the lack of parity will lock in the position of the other 2. Basically, it should be like TTLL, but easier. 2-sided recognition could even work.

I feel like the Briggs2 method (CP during FB in Roux) should be used more, although not necessarily with BLS. There are so many possibilities with it. Pseudo-2Gen 57 algorithm OLLCP sounds pretty nice, doesn't it? Pinkie Pie could become the norm, as opposed to the exception. And having pre-permuted corners would really help with NMCLL recognition. It could be as fast as CMLL recognition. CP, doubtlessly, is where people are turned away. Is Teoidus' new form of recognition going to work with it, or is what Shadowslice explained still better?

 

[Teoidus]

My CP system works fine and will yield more efficient CP solutions, but I'm not sure CPFB worth it. It's hard to justify when normal Roux is already so efficient with few algs

 

[Neuro]

I think that CP Roux could be good if used correctly. I think that making FB with <F,f,U,u,R,r> would be very difficult to plan in inspection. What I would suggest is place one or both of the SB corners into either slot (no worries about permutation/orientation) and use 1 alg to do full CP. From there just SB, CMLL (or OLLCP stuff) and LSE.

Probably not terribly useful for 2H b/c of CMLL+EOLR speed and the efficiency is practically the same, but OH could benefit if CP recog and lookahead to SB gets fast enough

R2 U R2 U2 R2 F2 D B2 L2 R2 D' L' B' U' L' R' B2 U' F2 L2 R'

y' B' R' D' r2 F D2//FB (6/6)
U R//CP Setup, recognize case (2/8)
U2 R F R F'//CP Alg (5/13)
r' U' R' U R2 U2 R2 U R' U' r'//FB (11/24)
U M' U M' U' R U R' U R U2 R'//PP Setup+OLLCP (12/36)
U2 M2 U//LSE (3/39)

If anyone is interested here are some first draft CP algs. Enjoy *Because CE is CE it solves the SB corners into their slots, hence this is a very rough 1st set*

I use DBR as buffer corner. Swap means SB D corners swap (i.e. DRF DRB swap, 1 corner DRF in DRB)

If one corner in place, put other corner in UBL. Names are based on case apperance rather than actual swaps (TTLL for reference)

1 corner solved
Front Swap- CP done, continue
Right Swap- F' U2 F
Diag Swap- U2 R' F R F'
No Swap- U R U' R' F' U F
Front Solid- U' F R F' R2
Right Solid- U R2 F R' F'

1 corner swapped
Front Swap- F' U F
Right Swap- U2 R F R F'
Diag Swap- U2 R2 F' U' F
No Swap- R U' F R2 F'
Front Solid- CP done, continue
Right Solid- U F R F2 U' F

2 corners solved
No Swap- CP done, continue
Front Swap- R U' R' F' U' F
Diag Swap- R U F R' F' R'

2 corners swapped
No Swap- R2 U' F' U2 F R'
Front Swap- R F R' F'
Diag Swap- CP done, continue

 

[xyzzy]

Silly LSLL idea:

Do something like ZZ-blah, but instead of orienting the U/D colours away from the U face, we orient the L/R colours (or the F/B colours) away from the U face, then one-look the last layer with PLL + 184 more ZBLL algs. Example:

Scramble: R2 F' R2 F' R2 F2 R2 U2 L F R' F2 L' R F'
R U R' // set up pair
U R U' R' // insert and orient LR away from U
U F' U2 R' U' R U' F U' R' U R U R' U R // ZBLL

Compared to the original ZZ-blah, efficiency is only marginally better (the pi and H sets have slightly longer algs than the others on average), and this comes at the cost of almost doubling the number of LL algs required. Compared to ZZ-b, efficiency is probably worse and it also uses more LL algs.

 

[Sue Doenim]

I just thought of a very simple seeming LS method for reduction to 2GLL: Just have 6 algs for each F2L case, one for each CP. It is meant for use with pre-EO methods. 116 algs, so quite a bit, but quite feasible.

 

[Neuro]

I actually came up with this a while back but never posted it. Could be a good CP style. What I'd probably do is something similar to my Roux CP style simply for the efficiency though. Does yours orient edges also or just bring it to a <RrUM> 2GLL? Orientation would give you more LS algs but full 2G 1LLL would have a ridiculous amount of algs and would have crappy recog. Of course ZZ/Petrus don't have this issue, but it seems like your aiming to CFOP OH.

 

[shadowslice e]

I just thought of a very simple seeming LS method for reduction to 2GLL: Just have 6 algs for each F2L case, one for each CP. It is meant for use with pre-EO methods. 116 algs, so quite a bit, but quite feasible.

That's more or less zz-porky, zz-rainbow or zz-orbit (I can't remember exactly which one it is)