I was thinking for Hawaii 4-O if it would be efficient to pair all the dedges, and then fix the last two centers of the 4x4 using an orientation preserving alg.
Can you provide an example solve? I'm guessing you'd do centres using commutators (as in the cage method), which isn't too bad on its own, but combining this with an awkward edge pairing stage would suck.
In fact, it looks like you're practically forced to have awkward stages of some sort once you have 3×3×4+columns solved. Dealing with edges is pretty weird when you're this restricted. You have nice stuff like a seven-move parity fix (destroys centres), but it's also hard to intuitively solve edges regardless of whether you have to preserve centres because the "M' U M"-like triggers are all 5-cycles. Solving centres is very easy and fast if you don't have to preserve edges, but if you do, it becomes a lot slower.
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.
What about HF-beginner? It would be a really nice for beginners to not just transition over to CFOP. because of the L5EO stage, you get the basic LSE 4a step down, and learn some basic EOline.Could be good. Main issue with beginners' methods is getting beginners to choose them over LBL
Yeah, but for a rotationless petrus it isn't too bad.Yeah, I saw your post on that while back. It's less efficient to do EO that way though. Overall the EO step in petrus just seems a little awkward and I think ZZ had the right idea moving it to the front of the solve
If you want to decrease the alg count, you could do CP during last pair, which would be 6 cases for the last pair and then only 7 for CMLL
I think what most people do (at least what I do) is sort of a simplification of pinkie pie where you have a few (usually 2 though I don't think there are many who actually learn them on purpose but rather just have picked them up over the years) algs for each CMLL which flip or exchange different pieces each time and that can be used to influence EO so that you always get a reasonably nice case and never get any of the really horrible ones like 6-flips. It's nice because you don't have to make sure you have certain pieces in D or anywhere really and it is the same speed as normal CMLL (more or less depending on your lookahead. With my lookahead (which I consider to be reasonable to bad for where I should be), you take no extra time and save a few moves in LSE most of the time).I was looking into the B2 method and I really liked it. I do however realize that CPFB is not, and may never be, feasible for speedsolving. Still, I like the idea of forcing an arrow case for EO. I've thought of a couple different ways to do it, which will be called A and B method. Starting at F2B-1, the steps are:
A
1) Make sure 1 D layer edge is oriented and one is not.
2) Use a 0-flip or 4-flip VHLS case.
3) Solve corners with COLL.
B
1) Make sure 1 D layer edge is oriented and one is not.
2) Insert final F2L pair
3) Use a COLL or CLLEF case to force arrow case.
Both of these could work; B is probably better than A.
So we only need to simulate 3 swaps? Im game, I just tried it and it works! Waaay easier than the other way you proposed, thanks!Wait guys, you don't have to BLD trace
Let's just assume we've got a permutation of corners on R and U faces. We can of course solve DRF and DRB <R,U> leaving a permutation of LL corners on U that we could use to detect a CP fix (aka what people do with COLL or porky style recog), but we can also simulate this solving in inspection with swaps. If we solve DRF and DRB with pure swaps, there's at most 1 extra "correction" swap that we have to do s.t. the 3 swaps performed together form a valid 2-gen permutation (essentially using the property of 2gen group to simulate the <R,U> moves needed to solve DRF and DRB while shortcutting all the tracking you'd need to do so). Then we can much more quickly figure out where our LL pieces would be w.r.t each other than if we had directly tracked what the LL would look like by imagining DRF and DRB solved w/ <R,U>.
So given any permutation of 6 corners we can imagine what the LL would look like if we 2gen solved DRF and DRB by imagining these swaps being done. And then looking at the resulting permutation of LL corners to figure out the key swap
Now this is easy to generalize to 7 corners--whenever we hit the DLF piece, we just pretend it's whatever piece is current at DLF (simulating a swap to solve DLF). Now without any BLD tracing we can extract a key swap, and we can easily express this key swap in a standard form that lets it be easily tracked.
OLL skip or VLS and OLL with EG on skewb would be helpful.
Instead of just EG, you can do EG and orient all top side at once. (EGOLL) This will get rid of L5C and first layer helpful.
If OLL skip is possible for skewb, it will get rid of advanced sarah cases and L5C. It will leave off L4C or L3C. (VLS)
downside is that i cant work on my ksolve program, my stupid command prompt is too advanced and frustrating