I guess now the only thing missing is when all corner pairs are twisted
Forgot to mention this one
I haven’t updated that post that I said I will “in a while”.
You could do normal tracing, put a swap pair in UFL and DFR (this will take 0 or 1 move 94% of the time) then do one of the following 2gen triggers based on the orientation of the twist: F2 R’ F R’ F R’ F or F2 U F’ U F’ U F. Will give you an 8 move 2gen CP-line; probably bearable.
This step seems inefficient
Yeah, working on pEO-extension. I’m getting a feeling it’s not that difficult an issue to resolve, but haven’t really found a great way to do it. I’ll put up the little trick I’ve been using; though my plan is to write a code to generate say 100 scrambles and solve pEO optimally; and see what patterns I can find.
I still usually pause briefly to recognize the EO case.
I’m not sure if that’s something that’ll go away completely; at least not with the current pEO approach. I feel it’s something like OLL recognition, like how after F2L you somewhat know which OLL is coming up, but usually sort of need to pause just a little to exactly know which one.
Also, use the algs on the website. They’re organised in a much better way, plus I think the visual representation helps.
I love this method
Yay!
Stuff I just realised: there’s 3 past posts that I said I will update but haven’t; the inspection post (though I don’t need to anymore, the rest of the stuff I just put up here), the 500 alg method post, and the of course the pEO trick post. Let me just make those right here.
pEO Trick:
If done right, you usually will not have to use Rw moves during the pEO extension step. You may have to use it “before” the step to set up the centres, and “after” the step to put in DB; but during the step, due to the lack of Rw moves, the DB and DF edges do not move. So during the step (or maybe even during inspection or CP line) check out the orientation of the DF edge. Half the time, you will get off simply by doing and Rw’ after extension. If you want to do more pEO, you can put a good edge in UL before doing the Rw’. Just an awesome idea to play with till further development; basically gives hope that there will probably be such a simple General way to do this step.
~500 alg method:
Not sure whether this method is worth it; though it certainly is much more efficient than YruRU can ever hope to be.
The general idea is pretty obvious:
1. Make CP line
2. Somehow solve F2L
3. Solve LL in 1 alg
Since CP is already done, the LL cases will be reduced, much like ZBLL; but it’s better here because all the algorithms will be [r, R, U]-gen which is a great moveset for OH, the alg length will be about the same, and the recognition is better than ZBLL (ZBLL has 1 orientation and 2 permutations to recognise, this thing here has 2 orientations and 1 permutation to recognise, orientations are easier to recognise than permutations, for eg OLLCP is easier to recognise than ZBLL).
Once we figure out how to do CP (YruRU CP takes care of that, and CP-line here will be more efficient than YruRU since we don’t care about EO at any point during the solve, so x2 y neutrality will be the way to go) the only non-trivial part is to figure out the best way to solve F2L (Unlike ZZ where it’s pretty obvious we gotta do LB and RB).
I have a couple of candidates on how to do F2L, none of them particularly great; though I can totally see this method averaging around 45 movecount in brain dead speedsolves; the last 15 moves of which will be an ergonomic algorithm, the first 5 moves will be planned, and the middle 25 moves will have [r, u, R, U] moveset.
The reason I do not expect much out of this method is mainly the fact that I do not like high alg count methods, and that I feel methods with asymmetries are just bad (the F2L part will most likely have some asymmetrical component). Though from an objective point of view, it’s probably worth a try.
If someone is interested in taking up developing this, I’ll be happy to assist if required.
