The New Method / Substep / Concept Idea Thread

[Shiv3r]

I'm not sure there's an easy silver bullet to attract peopel to roux. There's just too much CFOP content

Then just get more roux content out there to match it. Same with ZZ.

 

[Teoidus]

It's not that easy. Lots of CFOP content generates more CFOP solvers that make more CFOP content.

I'm fairly convinced that method popularity is mostly determined by whether or not there's someone sub-8 or 9 with it. Having someone to worship always seems to work better than content

 

[mDiPalma]

perhaps a superior alternative to speed-heise (to force a commutator case for LL):

consider EOF2L-1 with last slot at FR (24 moves)
place FR edge while phasing LL edges (opposite swap or solved) and ensure final F2L corner in LL (~5 moves based off a small sample) (if ur corner is stuck and u a novice u can just conjugate with [R y])
AUF F2L corner to URF (.75 moves)
apply alg to solve edges, F2L corner, and corner at DFR (72 cases, 48 without mirrors [30 algs, 18 commutators] ~10 moves based off a small sample)
L3C (~10 moves)
AUF (.75 moves)
=26 moves LS & LL

notes
-same movecount as speed-heise

pros
-same case count, but less algs than speed-heise (many comms)
-easier setup than speed-heise
-*can actually put in wrong corner-edge pair during blockbuilding (during 2x2x2, 3x2x2, etc) like EJF2L, to vastly improve blockbuilding efficiency and capitalize on lucky situations - also can help push inspection look ahead much further into solve

Spoiler: *

* this is an extremely strong advantage and is likely the main strongpoint of this variant. if u do this the only constraint on the rest of your solve is you will need to insert your last F2L pair with phasing (1.2 move penalty on the insert according to our old friend pyjam)

last slot = 6.7
phasing penalty = 1.2
auf = .75
this variant = ~10
l3c = ~10
auf = .75
=29.5 moves

meaning that if you can save >=4 moves incorporating a U-layer corner during blockbuilding like EJF2L (not unreasonable) then this variant is more efficient than speed-heise with the same amount of looks and less than half the algs (30 vs 72).

 

[xyzzy]

instead of simultaneously solving u and D corners and then solving U and D edges with waaay too many algorithms, perhaps solving the bottom corners while solving the top edges and then solving the top corners and bottom edges may make for better algs.
lemme check the alg count quick: 9 EPLL's*3 corner cases = 27 algs.

If you interchange the roles of U corners with the U edges, then it should be clear why this has the same number of cases as CP/EP (or EP/CP, for that matter): 9 cases for the first look, 100 cases for the second. (Or 6 for the first and 55 for the second if you allow flipping the whole cube over.)

Semirelatedly, there's this for a squan PBL method with relatively low case count.

 

[Shiv3r]

If you interchange the roles of U corners with the U edges, then it should be clear why this has the same number of cases as CP/EP (or EP/CP, for that matter): 9 cases for the first look, 100 cases for the second. (Or 6 for the first and 55 for the second if you allow flipping the whole cube over.)

Semirelatedly, there's this for a squan PBL method with relatively low case count.

Ah, I wasn't factoring relative permutation of edges/corners to the other pieces on the same layer. thanks for checking that.
still, maybe an orientation then cubeshape method may be in order...

 

[Shiv3r]

minor Bump.
Hey guys, for you ZZ solvers that are stuck doing methods like Yau or Hoya on 4x4, here is a new ZZ 4x4 method I proposed. It is pretty much the same Idea as Yau or Meyer, but for ZZ, and instead of 3-2-3, EOpairing is used. And as a byproduct of extending EPLL, There is no seperate PLL parity and(with some manipulation) no seperate OLL parity. I call it ZZ-4(not to be confused with Z4). So ZZ solvers, what do you think?

 

[genericcuber666]

Just like people said on Reddit the only thing missing here is viable eopairing until that happens the 5 seconds I lose from doing cfop f2l+ll won't matter to me

 

[Shiv3r]

Just like people said on Reddit the only thing missing here is viable eopairing until that happens the 5 seconds I lose from doing cfop f2l+ll won't matter to me

This was made for ZZ solvers, and one thing I like about this method is that with a few tricks, you can skip OLL parity about 3/4 of the time and PLL parity 100% of the time. two extra steps for parity really messed me up. And if you don't like EOpairing as much just pairing edges and them placing them oriented can work as a substitute. Thanks for your input though!

 

[AlphaSheep]

minor Bump.
Hey guys, for you ZZ solvers that are stuck doing methods like Yau or Hoya on 4x4, here is a new ZZ 4x4 method I proposed. It is pretty much the same Idea as Yau or Meyer, but for ZZ, and instead of 3-2-3, EOpairing is used. And as a byproduct of extending EPLL, There is no seperate PLL parity and(with some manipulation) no seperate OLL parity. I call it ZZ-4(not to be confused with Z4). So ZZ solvers, what do you think?

The method itself looks quite decent and is actually very similar to something I have played around with before. One thing I didn't like was the heavy reliance on inner slice moves during centres and edge pairing. This may not be a big issue for some, but for me it's a deal breaker.

This was made for ZZ solvers, and one thing I like about this method is that with a few tricks, you can skip OLL parity about 3/4 of the time and PLL parity 100% of the time. two extra steps for parity really messed me up. And if you don't like EOpairing as much just pairing edges and them placing them oriented can work as a substitute. Thanks for your input though!

You will not skip OLL parity. EOPairing doesn't change the parity state - whether or not you have OLL parity is determined as soon as you finish pairing centres, and there is a 50% chance, just like in Yau. All EOPairing will do is let you spot it earlier, but you will still need to do an OLL parity alg to fix it.

Also, you don't really skip PLL parity. Of the parity EPLLs, only the O perms have algs that are worth learning. The fastest way to solve the W perm is opposite swap cancelled into a U perm, and the adjacent swap is just a setup to the opposite swap.

Regarding EOPairing, it sucks seriously. Pairing then orienting is actually fewer moves. Just like when solving EO in normal ZZ, it's most efficient to orient edges in groups of four, it's the same with 4x4. With EOPairing, you are spending extra moves on 50% of your pairs to orient one edge pair at a time, and sacrificing the ability to do chain pairing (and the easy look ahead it brings) , which is the biggest strength of Yau and Hoya.

Also, you're a Roux user so don't ignore the power of M' U M for EO after pairing.

 

[Shiv3r]

You will not skip OLL parity. EOPairing doesn't change the parity state - whether or not you have OLL parity is determined as soon as you finish pairing centres, and there is a 50% chance, just like in Yau. All EOPairing will do is let you spot it earlier, but you will still need to do an OLL parity alg to fix it.

One of the things with the EOpairing is that when you have the 2 edges swap left, you can fix OLL parity with these 2 algs:

Final 4 edges - oriented (dedge in UL flipped)

r' F R2 U' R' F' U r

r' F U' R' F' R2 U r

Final 4 edges - flipped (dedge in UL flipped)

r' U' F R' U F' r F U2 R' F'

r' F U' R F' U r R' B L' U2 B'

I use these a lot and its great.

And if you don't like using inner slice moves you can solve the 2 opposite centers on U/D place the EOline edges correctly instad of a D move off and place the 2 oriented paired edges where the other 2 cross pieces go and then do E slice pairing. This is just a basic Idea for a Yau/Meyer-style ZZ method. I am open to Ideas. I just think that ZZ needs to be expanded to more puzzles than 3x3/OH. For example, I main ZZ-spike on megaminx.
Thanks for your help, I was mostly just finding a way to make Z4 more competitive

 

[AlphaSheep]

One of the things with the EOpairing is that when you have the 2 edges swap left, you can fix OLL parity with these 2 algs:

Final 4 edges - oriented (dedge in UL flipped)

r' F R2 U' R' F' U r

r' F U' R' F' R2 U r

Final 4 edges - flipped (dedge in UL flipped)

r' U' F R' U F' r F U2 R' F'

r' F U' R F' U r R' B L' U2 B'

I use these a lot and its great.

None of these cases are actually OLL parity cases. But I'll get to that. This is a very long post, but hopefully you'll be able to make sense of it.

In summary

• Before pairing is finished, recognising OLL parity is not as simple as counting flipped edges.
• Edge orientation on 4x4 is weirder than you think.

First, it is absolutely essential to realise that there is no such thing as edge orientation on a 4x4. To prove it, take a single edge piece (physically pop it out of the cube) and try put it back in the wrong orientation. You'll see it only goes in one way. Only dedges have "orientation", which can be changed by swapping the two edges that make up that dedge. Once you understand that, it's obvious that OLL parity has to be connected to the swapping of individual edge pieces.

And that's exactly how OLL parity is defined. OLL parity is where an odd number of edges need to be swapped to solve the edges. If an even number of edge swaps occur, then it's by definition not OLL parity. It therefore follows that OLL parity cannot be solved by an even number of slice moves (count them here - every single OLL parity alg has an odd number of slice moves), since slice moves cycle 4 edges (An odd number of swaps: 1&2, 2&3, 3&4).

Before edge pairing is finished, it can be really hard to recognise OLL parity without actually tracing the cycles (have a look at how parity avoidance works - it's a really cool technique if you can handle it - but even if you can't use it in speed solves (I definitely can't), it will help you understand parity a lot better).

Let's look a the first case you give as an example - the one solved by r' F R2 U' R' F' U r

I this case, you can pair and orient the edges with two swaps: swap both orange-blue edges, and swap the back yellow-blue edge with the front yellow-green edge. Because it's an even number of swaps, it's not an OLL parity case. That means any edge pairing alg involving slice, do something, slice back (ie - the natural and most move efficient way) won't change parity.

Here's another case that demonstrates what I'm talking about - it's just a three cycle of edges. Do it three times, and you should get back to the solved cube.
r' R U' R U F R2' F' R' r F R2' F' U' R' U
Do the alg once on a solved cube and you should get this case:

Again, this is not an OLL parity case, even though it looks like it is. If you look at the yellow-blue edge on the front face, it looks flipped. Perform the alg again, and you should get this case

You can see that the two blue-yellow edges look flipped. Do the alg a third time, and you get back to the solved cube.

If the alg actually did change the OLL parity state, then doing it three times would be - solved (no parity) - parity - no parity - solved (parity), and since there's obviously no parity on a solved cube, there's an obvious contradiction here. The alg does not affect OLL parity.

So, none of the cases you gave are parity cases, and the algs do not avoid OLL parity. OLL parity will still occur in 50% of your solves.


Anyway, on to the most important implication - if individual edge pieces don't have orientation, then how does EOpairing work for Z4? Good question. You're recognising the EO of the dedges that will be produced by the pairing, not the orientation of the individual edge pieces. The key to EOpairing is knowing how your EO algs affect EO of dedges. For that to be useful, you also have to look not only at the edges you're pairing, but also at the edges in the places that will be flipped. I find that's a pain and really interferes with lookahead. I can do it early on in the edge pairing, when I don't really care about edges I haven't paired yet, but later on, when I've got to worry about making sure I don't accidentally flip an edge that's already paired and oriented, it's just more hassle than it's worth.

I think a far far better strategy is to prioritise chain pairing (preferably 3-2-3 like in Yau) over EO. It is so simple to fix edge orientation after pairing - almost always 5 moves or less - whereas if you break the chain pairing just once, it's a guaranteed 5 extra moves at least. OLL parity doesn't count here, because as you've hopefully realised from earlier, you can't recognise OLL parity using standard ZZ EO recognition on individual edges until edge pairing is almost complete.


Anyway, I think you're on the right track. I love ZZ - it's why I've also spent so much time trying to get it working. Of the 4x4 ZZ variants I've seen I'm convinced Hoya+ZZ has the most potential. Keep thinking out of the box

 

[GenTheSnail]

Megaminx LL, complementary too ZZ-Spike.
This is a very rough idea so it still needs work.
Also, I haven't checked to see if someone already came up with it.
Possibly influenced by @bobthegiraffemonkey . I wasn't thinking of that LL method when I came up with this, but I had read the post.

Steps:
0. Get to LS + EO
1. Build a 1x2x2 in the LL (1 corner and 2 surrounding edges)
2. Create your last pair and insert it
3. OCLL on the last 4 corners and the last 3 edges (112 algs I think)
4. CPLL

Pros:
Recognition for Step 3 is arguably better than PLL (recognition/alg count)
Lower alg count than plain OCLL -> PLL
CPLL doesn't have 5-cycles

Cons:
Requires EO
Still a fairly large number of algs
Step 2 can be really inefficient and hard to get used to
Recognition for Step 3 is sorta weird


If you use ZZ-Spike, then you end up with the same face each time. The block I build is always in the back, so EPLL recognition is really fast, as you are only looking at one edge to determine the cycle direction.
Also, you could just do OCLL (without breaking the block) and wind up with (I think) Mushroom PLL. I'm pretty sure that would be less algs too, and it would only need a few different OCLLs.

Did this make sense, and do you have any constructive thoughts?

 

[xyzzy]

Anyway, on to the most important implication - if individual edge pieces don't have orientation, then how does EOpairing work for Z4? Good question. You're recognising the EO of the dedges that will be produced by the pairing, not the orientation of the individual edge pieces.

Actually, you can define EO on wing pieces like this, though it's kind of weird and it's "orientation" in the same way squan CO/EO steps are "orientation"; it's more like separating the wings into two subsets.

I did a few solves where I did parity avoidance and oriented all the wings after the centres were done, then did edge pairing. The solves were very inefficient because this is so different from normal edge pairing and I had no idea what I was doing, but maybe this can be done quickly if people generate algs and develop the idea.

For what it's worth, this is very similar to how the 4x4x4 random state scrambler in csTimer/TNoodle/etc. works, and I used this in my move count upper bound for the 5x5x5 (see sig).

 

[bobthegiraffemonkey]

Possibly influenced by @bobthegiraffemonkey . I wasn't thinking of that LL method when I came up with this, but I had read the post.

I'm actually confused lol. Can't remember what mega ideas I've posted and which one you would be talking about. I think the last one I posted (and used) was:

0) Get to LS with EO done (I oriented during last 2 faces because I think ZZ on mega is bad)
1) LS + 2 adjacent LL edges
2) OCLL while preserving step 1
3) PLL (EPLL or mushroom)

Is that what you're referring to? They have some stuff in common, but they're definitely different.

I'm not sure how good building a 2x2 block is though, it's something I've considered and never used. I think my method above has some nice ideas but can be improved too, I was going try to do it recently but I've not had the time, and that won't change any time soon. Maybe someone else will come up with something better and cool in the meantime? I'm really starting to think that EO before LL isn't worth it, no matter how fun it might seem.

 

[xyzzy]

The solves were very inefficient because this is so different from normal edge pairing and I had no idea what I was doing, but maybe this can be done quickly if people generate algs and develop the idea.

Follow-up: I just did 12 solves with this "method", and it's not very nice.

Spoiler: times

Generated By csTimer on 2016-11-24
avg of 12: 4:20.01

Time List:
1. (7:23.90) R2 D2 U L2 B2 U L2 F2 D B' L D R' U2 F' U L2 D' B2 Uw2 B' Uw2 Fw2 D' B2 R2 U2 R2 D' F' Uw2 Rw' F U F' B' Uw Rw2 Fw U' F' D2 Fw' D
2. 5:18.81 L' B' L' U B' U2 R2 F L' U2 L2 D' B2 U' L2 U F2 R2 Uw2 F2 L' F2 Rw2 D' Fw2 Uw2 R' D' L2 U2 R Fw B2 R' L' Uw2 F Uw L' Fw' R' U L2
3. 4:52.34 B R' L2 F' B2 L U' R' F' B' L2 B D2 F L2 B D2 B D2 Fw2 D2 L' Fw2 U R' Uw2 Fw2 R U2 B2 F' R' Uw2 Fw' Uw2 Fw B D2 B' Rw F2 Rw2 Uw' L2
4. 4:24.16 L2 B2 U2 R2 F' L2 B' R2 B' U2 R2 D U2 F' D F' D2 L' U R Fw2 Rw2 L' U2 Rw2 D R2 D' F2 Rw2 B2 U Fw Rw2 B L' Fw F Rw D' F U2 Fw F Uw'
5. 3:17.01 B2 R2 F2 D R2 U' B2 L2 R2 U R' U L' F' R2 B' D2 L F2 U' R2 Rw2 Fw2 D' L2 B Uw2 D B' U R2 U2 R' D' Rw Uw2 Fw F' D R' Fw' Uw' Rw2 B2
6. 3:45.02 U B2 L2 F2 D' L2 U2 L2 U' F2 U' R' D' B' L R' U' R D' L' B Uw2 L U2 Fw2 F L' Fw2 B R2 Fw2 Rw2 L2 Uw F' Rw2 Uw2 B2 Fw' Uw Rw2 Fw2 U' F' Rw
7. 4:07.05 F2 B2 R F L U2 D' B R' F2 L2 U F2 B2 U R2 U2 B2 L2 F2 Rw2 Uw2 L2 Uw2 D Fw2 F D B D U' Rw Fw2 F2 D2 L' Fw' U2 D L Fw' Uw Fw B2
8. 3:37.97 F' R' U2 L' F2 R U2 B2 R' B2 D2 R2 D L' F' D L2 R2 U' B R Rw2 Fw2 D' F' D' U' Fw2 F' Uw2 Rw2 F' U' B' R D2 Rw' R2 D2 R Fw Uw' Rw' Uw' R Uw2 Rw2
9. 3:25.90 D L2 F2 R2 B2 D2 F2 R2 F2 L' F' R' U' F2 U' B F' L B2 Uw2 Fw2 R' B F' L Fw2 R U2 Rw2 B D2 Fw2 Uw' U' R2 B' R2 U' Rw B' U' Rw Uw2 Fw Uw2 R
10. 4:34.43 L B2 U2 L' D2 F2 L2 D2 R' F2 R2 D' B2 F' R' F' U' R U' B' U Rw2 F' Uw2 F' D' Rw2 L2 B2 F D F' Rw' U' B' R Uw2 L2 U2 Fw' Uw' Fw2 Rw Uw2 U'
11. (3:07.73) B2 F2 D2 L2 F2 U L2 U' B2 U2 L2 R B L F2 R2 D2 B2 U' F2 R' Rw2 F Uw2 B' D' Fw2 D' Rw2 Uw2 U F Rw2 B2 Rw' R2 B' F R Fw Uw F Uw D2 Rw L'
12. 5:57.33 R' L2 D2 U' B2 U L2 D' B2 R2 U' R2 F' L2 B F2 D' U' F' L' B Uw2 B' Uw2 Rw2 Fw2 U' B U D2 Fw2 U B' Rw B' D' L' U2 Rw2 Fw' Uw' R2 F R B2

Spoiler

I cheated and counted the number of wide turns in the scrambles rather than tracing cycles, because it takes me way too long to trace cycles. Coincidentally, none of these 12 solves ended with PLL parity, though it does show up with 50% probability as usual.

The move count is high but not ridiculously so, but doing EO is ridiculously difficult because there's no inspection and unlike 3x3x3 ZZ, there are now 24 edge pieces moving around and you have to keep track of all their orientations. The general strategy I tried was to orient as many as possible using only F and B moves, then take care of whatever's left using something like F 2U2 2R2 2U2 F', but there must be a better way to do this.

I mostly did edge pairing 4-at-a-time by setting up two pieces and doing a Rw2, which would be pretty efficient if only I didn't suck at lookahead. You could also use Uw2 if you prefer E-slice pairing over M-slice pairing, of course. Note that edge pairing can be done with <U,L,R,Uw2/Rw2> (D moves are also occasionally useful), so it's quite ergonomic too.

 

[Shiv3r]

Follow-up: I just did 12 solves with this "method", and it's not very nice.

Spoiler: times

Generated By csTimer on 2016-11-24
avg of 12: 4:20.01

Time List:
1. (7:23.90) R2 D2 U L2 B2 U L2 F2 D B' L D R' U2 F' U L2 D' B2 Uw2 B' Uw2 Fw2 D' B2 R2 U2 R2 D' F' Uw2 Rw' F U F' B' Uw Rw2 Fw U' F' D2 Fw' D
2. 5:18.81 L' B' L' U B' U2 R2 F L' U2 L2 D' B2 U' L2 U F2 R2 Uw2 F2 L' F2 Rw2 D' Fw2 Uw2 R' D' L2 U2 R Fw B2 R' L' Uw2 F Uw L' Fw' R' U L2
3. 4:52.34 B R' L2 F' B2 L U' R' F' B' L2 B D2 F L2 B D2 B D2 Fw2 D2 L' Fw2 U R' Uw2 Fw2 R U2 B2 F' R' Uw2 Fw' Uw2 Fw B D2 B' Rw F2 Rw2 Uw' L2
4. 4:24.16 L2 B2 U2 R2 F' L2 B' R2 B' U2 R2 D U2 F' D F' D2 L' U R Fw2 Rw2 L' U2 Rw2 D R2 D' F2 Rw2 B2 U Fw Rw2 B L' Fw F Rw D' F U2 Fw F Uw'
5. 3:17.01 B2 R2 F2 D R2 U' B2 L2 R2 U R' U L' F' R2 B' D2 L F2 U' R2 Rw2 Fw2 D' L2 B Uw2 D B' U R2 U2 R' D' Rw Uw2 Fw F' D R' Fw' Uw' Rw2 B2
6. 3:45.02 U B2 L2 F2 D' L2 U2 L2 U' F2 U' R' D' B' L R' U' R D' L' B Uw2 L U2 Fw2 F L' Fw2 B R2 Fw2 Rw2 L2 Uw F' Rw2 Uw2 B2 Fw' Uw Rw2 Fw2 U' F' Rw
7. 4:07.05 F2 B2 R F L U2 D' B R' F2 L2 U F2 B2 U R2 U2 B2 L2 F2 Rw2 Uw2 L2 Uw2 D Fw2 F D B D U' Rw Fw2 F2 D2 L' Fw' U2 D L Fw' Uw Fw B2
8. 3:37.97 F' R' U2 L' F2 R U2 B2 R' B2 D2 R2 D L' F' D L2 R2 U' B R Rw2 Fw2 D' F' D' U' Fw2 F' Uw2 Rw2 F' U' B' R D2 Rw' R2 D2 R Fw Uw' Rw' Uw' R Uw2 Rw2
9. 3:25.90 D L2 F2 R2 B2 D2 F2 R2 F2 L' F' R' U' F2 U' B F' L B2 Uw2 Fw2 R' B F' L Fw2 R U2 Rw2 B D2 Fw2 Uw' U' R2 B' R2 U' Rw B' U' Rw Uw2 Fw Uw2 R
10. 4:34.43 L B2 U2 L' D2 F2 L2 D2 R' F2 R2 D' B2 F' R' F' U' R U' B' U Rw2 F' Uw2 F' D' Rw2 L2 B2 F D F' Rw' U' B' R Uw2 L2 U2 Fw' Uw' Fw2 Rw Uw2 U'
11. (3:07.73) B2 F2 D2 L2 F2 U L2 U' B2 U2 L2 R B L F2 R2 D2 B2 U' F2 R' Rw2 F Uw2 B' D' Fw2 D' Rw2 Uw2 U F Rw2 B2 Rw' R2 B' F R Fw Uw F Uw D2 Rw L'
12. 5:57.33 R' L2 D2 U' B2 U L2 D' B2 R2 U' R2 F' L2 B F2 D' U' F' L' B Uw2 B' Uw2 Rw2 Fw2 U' B U D2 Fw2 U B' Rw B' D' L' U2 Rw2 Fw' Uw' R2 F R B2

Spoiler

I cheated and counted the number of wide turns in the scrambles rather than tracing cycles, because it takes me way too long to trace cycles. Coincidentally, none of these 12 solves ended with PLL parity, though it does show up with 50% probability as usual.

The move count is high but not ridiculously so, but doing EO is ridiculously difficult because there's no inspection and unlike 3x3x3 ZZ, there are now 24 edge pieces moving around and you have to keep track of all their orientations. The general strategy I tried was to orient as many as possible using only F and B moves, then take care of whatever's left using something like F 2U2 2R2 2U2 F', but there must be a better way to do this.

I mostly did edge pairing 4-at-a-time by setting up two pieces and doing a Rw2, which would be pretty efficient if only I didn't suck at lookahead. You could also use Uw2 if you prefer E-slice pairing over M-slice pairing, of course. Note that edge pairing can be done with <U,L,R,Uw2/Rw2> (D moves are also occasionally useful), so it's quite ergonomic too.

A fairly simple way to do EOpairing is by doing 2-at-a-time and placing them oriented, and then also using the EOpairing algs. you end up with almost all edges oriented, and the rest are easy(if any). One thing I found was that even though EOpairing took slightly longer the 3x3 stage was faster even than my main Meyer 3x3 stage (I actually timed them). EOpairing just needs a slight getting used to, and it really is just deciding which way to slice so you get the most oriented edges, and orienting the misoriented ones by placing them oriented. With a little practice, you can even do 3-2-3 edge pairing in an eopairing style.

 

[Shiv3r]

Megaminx LL, complementary too ZZ-Spike.
This is a very rough idea so it still needs work.
Also, I haven't checked to see if someone already came up with it.
Possibly influenced by @bobthegiraffemonkey . I wasn't thinking of that LL method when I came up with this, but I had read the post.

Steps:
0. Get to LS + EO
1. Build a 1x2x2 in the LL (1 corner and 2 surrounding edges)
2. Create your last pair and insert it
3. OCLL on the last 4 corners and the last 3 edges (112 algs I think)
4. CPLL

Pros:
Recognition for Step 3 is arguably better than PLL (recognition/alg count)
Lower alg count than plain OCLL -> PLL
CPLL doesn't have 5-cycles

Cons:
Requires EO
Still a fairly large number of algs
Step 2 can be really inefficient and hard to get used to
Recognition for Step 3 is sorta weird


If you use ZZ-Spike, then you end up with the same face each time. The block I build is always in the back, so EPLL recognition is really fast, as you are only looking at one edge to determine the cycle direction.
Also, you could just do OCLL (without breaking the block) and wind up with (I think) Mushroom PLL. I'm pretty sure that would be less algs too, and it would only need a few different OCLLs.

Did this make sense, and do you have any constructive thoughts?

so it's like Tripod on Megaminx? The one problem I have with it is the high alg count. Alg counts alone are the reason I never learned full OLL, ZZ-CT, or even mega 4LLL

 

[JTWong71]

A fairly simple way to do EOpairing is by doing 2-at-a-time and placing them oriented, and then also using the EOpairing algs. you end up with almost all edges oriented, and the rest are easy(if any). One thing I found was that even though EOpairing took slightly longer the 3x3 stage was faster even than my main Meyer 3x3 stage (I actually timed them). EOpairing just needs a slight getting used to, and it really is just deciding which way to slice so you get the most oriented edges, and orienting the misoriented ones by placing them oriented. With a little practice, you can even do 3-2-3 edge pairing in an eopairing style.

The main thing when comparing ZZ-4 with Yao is the amount of regripping and rotations used in line with movecount and recognition during the reduction phase of a solve. Right now methods that do not require much thinking are the fastest, as recognition is quick, but in this case, rotations on cubes bigger than 3x3's will typically require more time than desired. I think that ZZ-4 should be experimented with more to understand its pros and cons more thoroughly, as things like recognition can be improved upon, and so can movecount, if algorithms and steps are optimized.

 

[xyzzy]

A fairly simple way to do EOpairing is by doing 2-at-a-time and placing them oriented, and then also using the EOpairing algs.

Oh, no, I didn't mean EOpairing as in Z4, I meant you actually orient everything first, then do edge pairing, like this. EOpairing is probably better for speedsolving than this, though.

 

[Shiv3r]

Oh, no, I didn't mean EOpairing as in Z4, I meant you actually orient everything first, then do edge pairing, like this. EOpairing is probably better for speedsolving than this, though.

Which one is better for speedsolving, the one you were talking about, or the Z4 EOpairing? ZZ-4 is an attempt to optimize Z4 kinda like Yau optimized redux/roux, so of course I kept the EOpairing concepts from it.