Hawaiian Kociemba 3x3x3 TUTORIAL - Method of Michael H.

Awesome! I think it's safe to say this is a great FMC method as well.

Hardly. Edge orientation strategies and block building have already been utilized in FMC for a while now, and saying that a method that restricts how you approach and balance these two ideas as being good for FMC is like saying running with one leg is effective.

Even if you take this from the perspective of leaving edge insertions rather than doing the last edges step, edge insertions are nowhere near as move efficient as corner insertions, so I feel doing a standard EO approach with solving all edges and leaving a corner skeleton is normally far better than this approach.
 
Hardly. Edge orientation strategies and block building have already been utilized in FMC for a while now, and saying that a method that restricts how you approach and balance these two ideas as being good for FMC is like saying running with one leg is effective.

Even if you take this from the perspective of leaving edge insertions rather than doing the last edges step, edge insertions are nowhere near as move efficient as corner insertions, so I feel doing a standard EO approach with solving all edges and leaving a corner skeleton is normally far better than this approach.
An interesting way to look at it. My argument:
1. Several variations, you are talking about pure HK. Other variations are better for certain things including FMC. I would say this is quite a free method, as there are many possibilities, and the boundaries are loose.
2. Just look at the example solves...
3. You can use commutators with CP+EO to make this very move efficient.
4. Balance between the two ideas of block building and EO? Like ZZ? And this one is more efficient? Then ZZ must really suck, if your are correct.
5. Um this method doesn't take advantage of edge insertions, it includes the RD edge in Algs and frees the R face for a little while, making this very move efficient.
6. Actually, back to 4, balancing between the 2 things that are being used in FMC sound very good to me, perhaps why EVERY SINGLE EXAMPLE SOLVE HERE (notice the caps) is 41 moves or less, making this a very ideal method for FMC.
(Please let this be a friendly argument :))
Also, even if it isn't good in FMC for whatever reason, at least it is good in Speedsolving.
 
An interesting way to look at it. My argument:
1. Several variations, you are talking about pure HK. Other variations are better for certain things including FMC. I would say this is quite a free method, as there are many possibilities, and the boundaries are loose.
It's still way more restricted than standard FMC approaches to solving the cube.

2. Just look at the example solves...
They're quite meh for FMC standards.

3. You can use commutators with CP+EO to make this very move efficient.
4. Balance between the two ideas of block building and EO? Like ZZ? And this one is more efficient? Then ZZ must really suck, if your are correct.
5. Um this method doesn't take advantage of edge insertions, it includes the RD edge in Algs and frees the R face for a little while, making this very move efficient.
6. Actually, back to 4, balancing between the 2 things that are being used in FMC sound very good to me, perhaps why EVERY SINGLE EXAMPLE SOLVE HERE (notice the caps) is 41 moves or less, making this a very ideal method for FMC.
(Please let this be a friendly argument :))
You completely misunderstood what Kit was trying to say. He's not saying that balancing EO and blockbuilding is a bad thing for FMC (that's actually the core of FMC). What he's saying is that this method brings nothing new to the table regarding EO/block building, it only restricts the way in which those two things are done, so it is not a good approach for FMC (the same can be said about ZZ, CFOP, and most speedsolving methods).
 
That CP+EO variation though... Has anyone tried speedsolving with it yet? I don't know enough about ZZ EO to do the first couple steps, but I really want to try it out.
 
the variant is this: instead of f2l eo at the start, petrus block, solve the 2 f2l pairs without the last cross edge, coll, m slices for eo, and then hawaiian l5e
Rip, I thought of this a couple months ago but I thought it was bad. Probably because I'm not very efficient and I can't blockbuild very well either :P
 
Again, that's pure HK, other variants are less restricted...
What makes you think I was talking about pure HK? FMC standard approaches at EO/blockbuilding are less restricted than any of the variations that have been discussed in this thread.

Those are speed solves...
Then why bring them up as evidence of this being a good method for FMC?
 
An interesting way to look at it. My argument:
1. Several variations, you are talking about pure HK. Other variations are better for certain things including FMC. I would say this is quite a free method, as there are many possibilities, and the boundaries are loose.
2. Just look at the example solves...
3. You can use commutators with CP+EO to make this very move efficient.
4. Balance between the two ideas of block building and EO? Like ZZ? And this one is more efficient? Then ZZ must really suck, if your are correct.
5. Um this method doesn't take advantage of edge insertions, it includes the RD edge in Algs and frees the R face for a little while, making this very move efficient.
6. Actually, back to 4, balancing between the 2 things that are being used in FMC sound very good to me, perhaps why EVERY SINGLE EXAMPLE SOLVE HERE (notice the caps) is 41 moves or less, making this a very ideal method for FMC.
(Please let this be a friendly argument :))
Also, even if it isn't good in FMC for whatever reason, at least it is good in Speedsolving.

As already stated, mid 30s are hardly proof for the method's utility in FMC. I've had a couple 30s before that essentially use CFOP, and could get a 41 or less using CFOP on just about any scramble. Still, I'd never argue for CFOP being an effective FMC method.

And yes, normally the goal of FMC is to effectively balance orienting edges with building blocks in an efficient manner. I don't mean to say that this method is taking a potentially poor approach to FMC, as in some cases it could very well be effective. It's just that this one tool is far too narrow to be used in FMC, and it lives in a much larger field of approaches that should be considered when doing FMC. ZZ is another example of a method that is too narrow to be efficiently used in FMC -- although simply adapting EOLine to just EO would be more in line with many top FMC solves now, so it's much closer.

I know the method does not take advantage of edge insertions itself, but since L5E is the last step, using this method as a skeleton for edge insertions is a viable argument for this being a method for FMC. I still don't think it's worthwhile, given the arguments I have already made.

Also, I hardly believe the burden of proof is provided for this being a viable speedsolving method. A (potentially joke/setup) video with a few solves and a list of solutions that were not found in a speedsolve setting is far from it. There's potential for it to be a competitive, but move efficiency does not always translate into speed. Otherwise, Petrus or Heise would be far more viable as speedsolving methods than they actually are.
 
Thanks to Alex Maass for creating this variant.
1. Make a 2x2x3 block.
2. Solve other 2 pairs, not RD.
3. COLL or CLL.
4. L5E, or orient edges as you would in FreeFOP or Roux then do EHKPLL.

Technically if we're solving edges in the last step, we might as well leave LD for this step as well, so we don't spend extra (wasted) moves solving it in step 1. Probably don't have to solve the centers on the S slice, either.
1. Make a 2x2x3 block, but with any edge/center on LD/D face
2. Solve two pairs
3. CLL, y rotation
4. Now we have two fully solved 1x2x3 blocks +corners, so we can solve the last 6 edges with <M,U>
:P

The CP+EO variation seems interesting though, albeit insane to inspect for. But I'm not understanding how CP is solved given the process you've described. Could you explain how it works?

As far as practicality goes, I think the best variant is likely the orient all edges/COLL/HKEPLL (can we have better names for these, by the way? PLL = Permute last layer, which is certainly incorrect here) approach, since the solve would go eoline, RUL 2x2x3+pairs, COLL, 2gen finish, which sounds quite nice (and avoids having to learn all >100 algs).
 
Last edited:
Technically if we're solving edges in the last step, we might as well leave LD for this step as well, so we don't spend extra (wasted) moves solving it in step 1. Probably don't have to solve the centers on the S slice, either.
1. Make a 2x2x3 block, but with any edge/center on LD/D face
2. Solve two pairs
3. CLL, y rotation
4. Now we have two fully solved 1x2x3 blocks +corners, so we can solve the last 6 edges with <M,U>
:P

The CP+EO variation seems interesting though, albeit insane to inspect for. But I'm not understanding how CP is solved given the process you've described. Could you explain how it works?

As far as practicality goes, I think the best variant is likely the orient all edges/COLL/HKEPLL (can we have better names for these, by the way? PLL = Permute last layer, which is certainly incorrect here) approach, since the solve would go eoline, RUL 2x2x3+pairs, COLL, 2gen finish, which sounds quite nice (and avoids having to learn all >100 algs).

can i see an example solve of the proposed variant?

also i dont think it would make much difference doing either eo of all edges or eo of only f2l edges
 
Technically if we're solving edges in the last step, we might as well leave LD for this step as well, so we don't spend extra (wasted) moves solving it in step 1. Probably don't have to solve the centers on the S slice, either.
1. Make a 2x2x3 block, but with any edge/center on LD/D face
2. Solve two pairs
3. CLL, y rotation
4. Now we have two fully solved 1x2x3 blocks +corners, so we can solve the last 6 edges with <M,U>
:P

The CP+EO variation seems interesting though, albeit insane to inspect for. But I'm not understanding how CP is solved given the process you've described. Could you explain how it works?

As far as practicality goes, I think the best variant is likely the orient all edges/COLL/HKEPLL (can we have better names for these, by the way? PLL = Permute last layer, which is certainly incorrect here) approach, since the solve would go eoline, RUL 2x2x3+pairs, COLL, 2gen finish, which sounds quite nice (and avoids having to learn all >100 algs).
Yeah when I learned CP I must have missed something because I can't do CP in anything anymore, I'll fix that soon.
And regarding the names of algorithm sets, it's just for now so they can be called something and not "that other alg set".
 
Back
Top