# Roux-breaker? The YruRU method

#### trangium

##### Member
This is a thought that I've been toying around with for a little bit, and it could end up being quite useful.
After the reduction to <R, Rw, U> and EO, if it takes a lot of moves to solve DF and DB, or if you want to utilize some blocks that would get destroyed after solving DF and DB, you can solve the right square (or even all of F2L) before solving DF and DB
Suppose you end up here -
Scramble: R2 U’ B2 R2 D’ F2 D B2 R2 D2 B F2 U L2 R U L’ R’ F2 D
Solution: z // inspection
R S R2 F’ U’ F // CP-line
u’ R u’ R U R u2 // 123
U2 R2 U R’ r U’ r // EO
R2 U' r U2 r' U2 r2 // 2-gen reduction
(the rest of this solve wasn't included)

DF+DB took 7 moves. That's 7 moves just to solve 2 pieces, not great. But what if you did this instead:
z // inspection
R S R2 F’ U’ F // CP-line
u’ R u’ R U R u2 // 123
U2 R2 U R’ r U’ r' // EO
U' R' U' // Easy square
r2 U' r' U2 r' // DF+DB (2-gen reduction)
R U R // F2L
U R U2 R' U' R U' R2 U2 R U R' U R U // 2GLL
Of course, you shouldn't do this every solve. But when there are easy blocks or a hard stripe, saving the stripe for after the square (or even after F2L is done) could be worthwhile.

• • CuberStache, Imam Alam, Devagio and 2 others

#### Owen Morrison

##### Member
This is a thought that I've been toying around with for a little bit, and it could end up being quite useful.
After the reduction to <R, Rw, U> and EO, if it takes a lot of moves to solve DF and DB, or if you want to utilize some blocks that would get destroyed after solving DF and DB, you can solve the right square (or even all of F2L) before solving DF and DB
(the rest of this solve wasn't included)

DF+DB took 7 moves. That's 7 moves just to solve 2 pieces, not great. But what if you did this instead:
z // inspection
R S R2 F’ U’ F // CP-line
u’ R u’ R U R u2 // 123
U2 R2 U R’ r U’ r' // EO
U' R' U' // Easy square
r2 U' r' U2 r' // DF+DB (2-gen reduction)
R U R // F2L
U R U2 R' U' R U' R2 U2 R U R' U R U // 2GLL
Of course, you shouldn't do this every solve. But when there are easy blocks or a hard stripe, saving the stripe for after the square (or even after F2L is done) could be worthwhile.
I agree that this is useful! Thanks for sharing.

#### Devagio

##### Member
This is a thought that I've been toying around with for a little bit, and it could end up being quite useful.
After the reduction to <R, Rw, U> and EO, if it takes a lot of moves to solve DF and DB, or if you want to utilize some blocks that would get destroyed after solving DF and DB, you can solve the right square (or even all of F2L) before solving DF and DB
(the rest of this solve wasn't included)

DF+DB took 7 moves. That's 7 moves just to solve 2 pieces, not great. But what if you did this instead:
z // inspection
R S R2 F’ U’ F // CP-line
u’ R u’ R U R u2 // 123
U2 R2 U R’ r U’ r' // EO
U' R' U' // Easy square
r2 U' r' U2 r' // DF+DB (2-gen reduction)
R U R // F2L
U R U2 R' U' R U' R2 U2 R U R' U R U // 2GLL
Of course, you shouldn't do this every solve. But when there are easy blocks or a hard stripe, saving the stripe for after the square (or even after F2L is done) could be worthwhile.
This is where the solve starts getting really flexible and your example perfectly shows how helpful this simple tweak can be.
As you mentioned, it may not be useful unless an easy block is able to draw your attention during BF, but this does happen quite often. Quite brilliant to point it out and be aware of it during solves.

#### trangium

##### Member
I've been working on some small optimizations for YruRU.

An improvement on one of the algorithmic pEO cases:
U R u2 type insert, FB edge in UB:
GGG: U R u2 U' r
GGB: U R u2 U' r
*GBG: (r’ u' R u' / U2 r u R' u) U r U’ R U r
GBB: U R u2 U2 r
BGG: U R u2 U' r
BGB: U R u2 r [or U r u2]
BBG: U R u2 r [or U r u2]
BBB: U R u2 r [or U r u2]
* What I consider better here is (r’ u’ R u’ U r2) or (U2 r u R’ u U r2). It is much lower movecount and ensures a good edge ends up in DB, but it increases the probability 6 bad edges. Also, once in 2048 solves, you will have an 8 bad edges EO case if you use this; which is why I did not list it up there.
For GBG, there is a better way:
For the U R u2 type insert, you can use this algorithm: r U' r' U r u2
For the U R' u2 type insert, you can use this algorithm: r U' r' U r' u2
These algorithms can be thought of as doing r U' r', then the normal insert with a wide r move. They're the same length as the alternative algorithm without increasing the probability of 6 bad edges, and they eliminate the possibility of an 8 bad edge EO. (These two algorithms orient two of the top edges compared to all three for the long 10-move standard alg, but that's OK and could even be considered a strength for the second alg since it guarantees that a bad edge ends up in DF. I might be misunderstanding something about pEO, so if I am, let me know.)

A small optimization for CP-line when DFL is solved:
A lot of the time, when DFL is solved, solving CP can be <F, U> gen or <F, R> gen, perhaps with wide versions of those moves to help solve DL. You could rotate to solve CP with R and U moves, but then you have to perform a time-consuming rotation after CP is done. Right? Wrong. You could replace an x or y rotation with an L or D move, respectively, which also happens to influence the centers.
For example, scramble the cube with R2 D2 F L2 R2 D' F2 U2 R2 U L2 U2 F2 U B U2 B L U2 R' D.
You could start off the solve like this:
z' // inspection
F' U' F S' // CP-line
z' y' // inspection
R' U' R2 r' y // CP-line
This is fine, but the y rotation is slow. What if you did this?
z' y' // inspection
R' U' R2 r' D' // CP-line
Changing the y into a D' seems like a worthwhile trade to me. In fact, this trick allows you to influence the positioning of the L center by choosing to rotate or use a D move. In this case, the D move puts the L center into an arguably better position, allowing us to continue like this:
R2 u2 R' u' // FB
U' r2 // good edge in DB
You shouldn't use this if it affects the centers or FB in an unfavorable way, or if the CP-line contains all three of R, U, and F moves.
This concept can be applied to final x rotations and L moves too, but it's not as useful since x rotations aren't as bad as y rotations.

A more efficient way of doing nightmare cases, where DFL is twisted in place:
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 doesn't seem to work, and it's really inefficient. For the case where DFL needs to twist counterclockwise, put a swap pair in UBL and UBR and do F2 R' F. If CP is solved, do F2 R' F2 R2 F'. If DFL needs to twist clockwise, put a swap pair in UFL and UFR and do F2 U F'. If CP is solved, do F2 U F2 U2 F. Again, I might be misunderstanding something, so if I am, let me know.

As an example, scramble the cube with D2 F U2 L2 U B2 U2 B R F' U F2 U' R2 U' B2 D R2 D B2 L2.
Inspection: x' y'
U' // put a swap pair in UFL and UFR
F2 U F' // 4 move CP-line in the nightmare case!

Some people, including me at one point, reasoned that you have to do unergonomic moves at some point, and CP-line just moves those unergonomic moves to the start of the solve. However, two things changed my mind. First, every method's first step includes unergonomic moves for OH; it's just unavoidable. CP-line just makes it so that those intital unergonomic moves eliminate the need to use unergonomic moves later in the solve. Second, CP-line can be solved with only one F move if DFL is unsolved, and CP-line can often be solved with only one D or L move if you use the optimization above. (Or one rotation if you don't use the optimization)

• • CuberStache, Devagio, Imam Alam and 2 others

#### Devagio

##### Member
I've been working on some small optimizations for YruRU.

An improvement on one of the algorithmic pEO cases:
For GBG, there is a better way:
For the U R u2 type insert, you can use this algorithm: r U' r' U r u2
For the U R' u2 type insert, you can use this algorithm: r U' r' U r' u2
These algorithms can be thought of as doing r U' r', then the normal insert with a wide r move. They're the same length as the alternative algorithm without increasing the probability of 6 bad edges, and they eliminate the possibility of an 8 bad edge EO. (These two algorithms orient two of the top edges compared to all three for the long 10-move standard alg, but that's OK and could even be considered a strength for the second alg since it guarantees that a bad edge ends up in DF. I might be misunderstanding something about pEO, so if I am, let me know.)

A small optimization for CP-line when DFL is solved:
A lot of the time, when DFL is solved, solving CP can be <F, U> gen or <F, R> gen, perhaps with wide versions of those moves to help solve DL. You could rotate to solve CP with R and U moves, but then you have to perform a time-consuming rotation after CP is done. Right? Wrong. You could replace an x or y rotation with an L or D move, respectively, which also happens to influence the centers.
For example, scramble the cube with R2 D2 F L2 R2 D' F2 U2 R2 U L2 U2 F2 U B U2 B L U2 R' D.
You could start off the solve like this:
z' // inspection
F' U' F S' // CP-line
z' y' // inspection
R' U' R2 r' y // CP-line
This is fine, but the y rotation is slow. What if you did this?
z' y' // inspection
R' U' R2 r' D' // CP-line
Changing the y into a D' seems like a worthwhile trade to me. In fact, this trick allows you to influence the positioning of the L center by choosing to rotate or use a D move. In this case, the D move puts the L center into an arguably better position, allowing us to continue like this:
R2 u2 R' u' // FB
U' r2 // good edge in DB
You shouldn't use this if it affects the centers or FB in an unfavorable way, or if the CP-line contains all three of R, U, and F moves.
This concept can be applied to final x rotations and L moves too, but it's not as useful since x rotations aren't as bad as y rotations.

A more efficient way of doing nightmare cases, where DFL is twisted in place:
This doesn't seem to work, and it's really inefficient. For the case where DFL needs to twist counterclockwise, put a swap pair in UBL and UBR and do F2 R' F. If CP is solved, do F2 R' F2 R2 F'. If DFL needs to twist clockwise, put a swap pair in UFL and UFR and do F2 U F'. If CP is solved, do F2 U F2 U2 F. Again, I might be misunderstanding something, so if I am, let me know.

As an example, scramble the cube with D2 F U2 L2 U B2 U2 B R F' U F2 U' R2 U' B2 D R2 D B2 L2.
Inspection: x' y'
U' // put a swap pair in UFL and UFR
F2 U F' // 4 move CP-line in the nightmare case!

Some people, including me at one point, reasoned that you have to do unergonomic moves at some point, and CP-line just moves those unergonomic moves to the start of the solve. However, two things changed my mind. First, every method's first step includes unergonomic moves for OH; it's just unavoidable. CP-line just makes it so that those intital unergonomic moves eliminate the need to use unergonomic moves later in the solve. Second, CP-line can be solved with only one F move if DFL is unsolved, and CP-line can often be solved with only one D or L move if you use the optimization above. (Or one rotation if you don't use the optimization)
Really love the nightmare case trigger; truly makes this one of the best cases now. Definitely implementing it right away in my solves!
Not sure if the D/L move instead of a rotation is such a good idea, it seems to be more work than a rotation to me given the next step is going to involve u/r moves so you’ll have to completely change your grip anyway. But if it works for some, it works.
Also that algorithmic pEO alg is quite creative. I believe intuitive pEO will be better in the long run, but I’m unable to “package” all ideas like we do in intuitive F2L by saying split-pair-insert. Maybe you’ll be able to come up with something there.
every method's first step includes unergonomic moves for OH; it's just unavoidable. CP-line just makes it so that those intital unergonomic moves eliminate the need to use unergonomic moves later in the solve.
If I may add something to this reasoning; putting the entire unergonomic part of the solve towards one of the ends enables us to flow through the steps with much more confidence. An F2L novice will find F2L much more comfortable to do on EO-cross than on regular cross because of being safe in the knowledge that come what may, there will be no rotations; thus rotationless F2L on a normal cross which occurs 1/16 of the time will still be slower than F2L on EO-cross.
That was my reasoning at least.
I've been working on some small optimizations for YruRU.
This is beautiful stuff, keep it coming!

#### ProStar

##### Member
I'm still working on sub-1 4x4 #### trangium

##### Member
Here's an intermediate 2GLL method that decreases the average LL movecount from 21.046 to 16.904 (excluding AUFs) with only 7-8 new algorithms.

The first step is to use a Sune/Antisune/Backsune/Backantisune to reduce a T, U, L, H, or Pi case to one of eight anti-phased Antisune cases. (If you have a Sune, phased Antisune, or O case, use the beginner approach.)
The second step is to do one of 8 Antisune algorithms to finish the cube.

Here are the five recognition cases for step 1:
U case: Put the headlights in the front.
T case: Put the misoriented corners in the left.
L case: Put the unsolved pieces in UFL and UBR, with the yellow stickers facing towards you.
Pi case: Put the headlights on the left.
H case: Put the headlights in the front.
As it turns out, the required pre-AUF matches the pre-AUF for normal OLL in all 5 cases.

If there are two misoriented corners (U, T, and L), do a Sune. If there are four misoriented corners (H and Pi), do an Antisune.

Anti-phasing during step 1 is actually really simple. If you need to do a Sune (R U R' U R U2 R'), check the UF and UR edges (or the UL and UB edges). If they're opposite, do a back antisune (U' R' U2 R U R' U R). If not, simply do a Sune. If you need to do an Antisune (R U2 R' U' R U' R'), check the UF and UL edges (or the UB and UR edges). If they're opposite, do a back sune (U' R' U' R U' R' U2 R). If not, simply do an Antisune.

If you want to determine the anti-phasing case before pre-AUF, that's also really easy. If the pre-AUF is a U2, anti-phasing recognition is exactly the same: UF and UR for Sune; UF and UL for Antisune. If the pre-AUF is a U or U', the recognition is reversed: Check the edges in UF and UL (before the pre-AUF) for Sune,; UF and UR for Antisune.

Why go through the trouble of anti-phasing? First, it decreases the number of cases from 12 to 8. Second, the 8 anti-phased cases that remain have an average movecount of 11 moves, with two 7-movers and no cases longer than 13 moves. The 4 phased cases, however, take an average of 14 moves, with the worst case, the pure 3-twist, needing 17 moves to solve! Third, it does not cost any moves to anti-phase, due to being able to switch between Antisune and Backsune; and Sune and Backantisune. Fourth, anti-phasing is really easy to recognize: you just see if two stickers are opposites or not. Basically, anti-phasing saves moves at no cost. That being said, if anti-phasing is not for you, you can skip it and learn all 12 of the Antisune cases.

Examples:
1. R2 U' R U' R U R' U R U R' U' R' U R2
This is an L case. The pre-AUF is already correct. Since there are two misoriented corners, we need to do a Sune, so we check UF and UR. They're opposite, so we do a back antisune instead.
U' R' U2 R U R' U R // Step 1
U2 R U2 R2 U2 R2 U R2 U R2 U' R' U // Step 2 + AUF

2. U2 R U R2 U' R2 U' R2 U2 R U' R U' R' U
This is a U case. We are a U' away from the regular U orientation, so that's are pre-AUF. Since there are two misoriented corners, we need to do a Sune, so we check UF and UR. They're adjacent, so we proceed with a Sune.
U' // pre-AUF
R U R' U R U2 R' // Step 1
R U2 R2 U2 R2 U R2 U R2 U' R' U2 // Step 2 + AUF

3. U R U2 R' U' R' U' R' U' R U R' U' R2 U2 R U2
This is a Pi case. We are a U2 away from the regular Pi orientation, so that's our pre-AUF. Since there are four misoriented corners, we need to do an Antisune, so we check UF and UL. They are opposite, so we do a Back sune instead.
U2 // pre-AUF
U' R' U' R U' R' U2 R // Step 1
R2 U' R U R U R' U2 R U R2 U R2 U' // Step 2 + AUF

4. R U2 R2 U2 R' U2 R U2 R' U2 R2 U2 R U
This is an H case. We are a U' away from the regular H orientation, so that's our pre-AUF. Since there are four misoriented corners, we need to do an Antisune, so we check UF and UL. They are adjacent, so we proceed with an Antisune.
U' // pre-AUF
R U2 R' U' R U' R' // Step 1
U' R' U' R U' R' U2 R // Step 2

5. U R2 U R U R2 U' R' U' R2 U' R U' R' U2
This is a Sune case, so we should use the beginner way to solve LL.
U2 // pre-AUF
R U R' U R U2 R' // OLL
U' R2 U' R' U' R U R U R U' R // PLL

6. U R' U' R U' R U R' U' R U R2 U R2 U' R' U R U' R'
This is an Antisune case. If this happens to be anti-phased, we already know this alg. Since we recognize this case as one that we know, it is anti-phased, and we can do this in one look!
// Step 1 skip
R2 U' R' U R U R' U2 R' U R2 U R2 U' // Step 2 + AUF

The eight anti-phased Antisune cases (these algorithms are from the website, except for #5 and #8):
R' U' R2 U R2 U R2 U2 R2 U2 R  - Pseudo-Backsune (Anti-Benny)
(U) R U2 R' U' R U' R'  - Antisune
R U2 R2 U2 R2 U R2 U R2 U' R'  - Pseudo-Antisune (Back-Benny)
R' U' R U' R' U2 R  - Backsune
(U) R2 U' R' U R U R' U2 R' U R2 U R2  - Adj-Adj Square + no blocks
(U) R2 U' R U R U R' U2 R U R2 U R2  - Trapped Block
(U) R2 U R2 U R U2 R' U R U R U' R2  - Free Block
(U) R2 U R2 U R' U2 R' U R U R' U' R2  - Adj-Opp Square + no-blocks

Last edited:

#### Exotic Butters

##### Member
If we were to solve the two corners in the bottom left (disregarding CP), what would the probability of having CP already complete be? is it also 1/6 just like last layer?

• Owen Morrison

#### mukerflap

##### Member
If we were to solve the two corners in the bottom left (disregarding CP), what would the probability of having CP already complete be? is it also 1/6 just like last layer?
there are only 6 possible CP cases always so yeah 1/6

#### Exotic Butters

##### Member
there are only 6 possible CP cases always so yeah 1/6
Oh ok. Thanks for clarifying • Owen Morrison

#### trangium

##### Member
I generated some 2GLLs with Cube Explorer. Then I compiled a list of 2GLL algorithms that are/could be better than the ones on Devagio's website, which are in the table below. An algorithm is considered Tier 1 if nearly everyone would find it faster than the one on Devagio's website. An algorithm is considered Tier 2 if some people, including me, would find it faster, and considered Tier 3 if some people, excluding me, would find it faster. I operated under the assumption that R is faster than R', U' is faster than U, and U2 is faster than R2. I execute my R2s in one strong flick, meaning some R2-heavy algorithms still make it into Tier 2.

The naming of the alg is based on the OLL case and the ordering on Devagio's website. I didn't provide a starting AUF for any of the algs, but it should be easy to figure out.

Note that these are OH-optimized algs, and that many of these algs are trash for 2H.

 Alg Name Tier R' U' R U R U' R' U2 R' U2 R U' R U2 R' T1 2 R' U2 R2 U' R U' R U' R U' R' U2 R2 U R2 T2 2 R' U2 R U2 R U2 R' U' R U' R' U R' U R T5 3 R' U2 R U' R2 U R U' R U' R U' R U R' T6 3 R U' R U2 R U2 R' U R U2 R U' R' U' R2 T7 3 R U' R' U2 R' U2 R U' R U2 R' U2 R' U' R L1 2 R U2 R' U' R U R' U' R U R' U' R U' R' L2 1 R' U2 R U R' U R U' R U2 R' U' R U' R' L5 1 R U' R U2 R U' R' U R U' R2 U' R' U2 R' L6 2 R' U' R U' R' U2 R U' R U R' U R U2 R' L7 1 R2 U' R U R U' R' U' R U' R' U R' U R2 L9 2 R2 U R' U R' U' R U' R' U' R U R U' R2 L11 2 R' U2 R U' R U2 R' U2 R' U' R U R U' R' U1 2 R U R' U R' U' R U' R' U2 R U2 R U2 R' U5 3 R2 U' R' U' R U2 R U R' U2 R U2 R U' R U12 2 R' U R' U' R' U R U R' U2 R U2 R U' R U12 2 R2 U R U' R U2 R U' R U2 R U' R U R2 S1 1 R' U' R U' R U R' U R U2 R' U' R' U R S5 3 R' U2 R2 U2 R2 U' R2 U' R2 U R S8 2 R' U' R2 U R U R' U' R U R2 U2 R' S10 3 R U R' U' R' U2 R U R' U R U' R U' R' S11 3 R' U' R U R U2 R' U' R' U R U' R U' R' A3 3 R U2 R2 U' R' U' R' U R U R2 U' R' A4 2 R U R' U' R' U' R U R U' R' U' R' U R A4 1 R U R2 U' R' U' R U R' U' R2 U2 R A5 3 R U2 R2 U' R' U R U' R' U' R2 U R A7 3 R2 U R U' R2 U' R2 U2 R2 U' R U' R2 A9 2 R2 U' R' U R U R' U2 R' U R2 U R2 A9 2 R U' R U R U R' U' R' U' R2 U' R U' R' A9 2 R' U' R' U R' U2 R' U' R U' R U' R U R A10 3 R2 U' R U' R2 U2 R2 U' R2 U' R U R2 A11 2 R2 U R2 U R' U2 R' U R U R' U' R2 A11 2 R' U' R U' R2 U' R' U' R' U R U R U' R A11 2 R U R U' R U' R U' R' U2 R' U R' U' R' A12 3 R U R2 U' R2 U' R2 U2 R2 U' R' U R U2 R' P1 2 R U2 R' U' R U R2 U' R U' R' U2 R U2 R U2 R' P1 2 R U2 R' U' R U' R' U' R U2 R' U' R U' R' P2 1 R' U' R U R U2 R' U' R U' R2 U2 R P3 1 R U2 R2 U' R U' R' U2 R U R U' R' P4 1 R U R' U R U2 R2 U2 R U R' U R P10 1 R U2 R2 U' R' U R U' R' U' R' U' R' U2 R P11 2 R U' R' U R2 U2 R' U' R U' R2 U R U' R' P12 2 R' U' R U' R' U R U' R2 U' R' U' R' U R U R U' R H1 1 R U R2 U' R2 U' R U2 R U2 R U' R2 U' R2 U R H1 2 R' U' R U' R' U2 R U R U2 R' U' R U' R' H2 2 R' U2 R2 U2 R U2 R' U2 R U2 R2 U2 R' H3 3 R U2 R2 U2 R' U2 R U2 R' U2 R2 U2 R H4 3

• • ##### Member
I finally got around to try the method , my CPLine was very inefficient but I don't think it's that hard to do it, what the hardest step for me to do tho is the pEO extension, I got a bit confused on that part, I would say this is a fast method method for OH and I will try to use it more.

Last edited:

#### Devagio

##### Member
I finally got around to try the method , my CPLine was very inefficient but I don't think it's that hard to do it, what the hardest step for me to do tho is the pEO extension, I got a bit confused on that part, I would say this is a fast method method for OH and I will try to use it more.
That’s awesome!
pEO is indeed the trickiest step for most people I’ve talked to. If you’re going for the intuitive approach, I guess just look at a lot of examples; else the path for algorithmic way to do it is clear enough. Best of luck!
I generated some 2GLLs with Cube Explorer. Then I compiled a list of 2GLL algorithms that are/could be better than the ones on Devagio's website, which are in the table below. An algorithm is considered Tier 1 if nearly everyone would find it faster than the one on Devagio's website. An algorithm is considered Tier 2 if some people, including me, would find it faster, and considered Tier 3 if some people, excluding me, would find it faster. I operated under the assumption that R is faster than R', U' is faster than U, and U2 is faster than R2. I execute my R2s in one strong flick, meaning some R2-heavy algorithms still make it into Tier 2.

The naming of the alg is based on the OLL case and the ordering on Devagio's website. I didn't provide a starting AUF for any of the algs, but it should be easy to figure out.

Note that these are OH-optimized algs, and that many of these algs are trash for 2H.

 Alg Name Tier R' U' R U R U' R' U2 R' U2 R U' R U2 R' T1 2 R' U2 R2 U' R U' R U' R U' R' U2 R2 U R2 T2 2 R' U2 R U2 R U2 R' U' R U' R' U R' U R T5 3 R' U2 R U' R2 U R U' R U' R U' R U R' T6 3 R U' R U2 R U2 R' U R U2 R U' R' U' R2 T7 3 R U' R' U2 R' U2 R U' R U2 R' U2 R' U' R L1 2 R U2 R' U' R U R' U' R U R' U' R U' R' L2 1 R' U2 R U R' U R U' R U2 R' U' R U' R' L5 1 R U' R U2 R U' R' U R U' R2 U' R' U2 R' L6 2 R' U' R U' R' U2 R U' R U R' U R U2 R' L7 1 R2 U' R U R U' R' U' R U' R' U R' U R2 L9 2 R2 U R' U R' U' R U' R' U' R U R U' R2 L11 2 R' U2 R U' R U2 R' U2 R' U' R U R U' R' U1 2 R U R' U R' U' R U' R' U2 R U2 R U2 R' U5 3 R2 U' R' U' R U2 R U R' U2 R U2 R U' R U12 2 R' U R' U' R' U R U R' U2 R U2 R U' R U12 2 R2 U R U' R U2 R U' R U2 R U' R U R2 S1 1 R' U' R U' R U R' U R U2 R' U' R' U R S5 3 R' U2 R2 U2 R2 U' R2 U' R2 U R S8 2 R' U' R2 U R U R' U' R U R2 U2 R' S10 3 R U R' U' R' U2 R U R' U R U' R U' R' S11 3 R' U' R U R U2 R' U' R' U R U' R U' R' A3 3 R U2 R2 U' R' U' R' U R U R2 U' R' A4 2 R U R' U' R' U' R U R U' R' U' R' U R A4 1 R U R2 U' R' U' R U R' U' R2 U2 R A5 3 R U2 R2 U' R' U R U' R' U' R2 U R A7 3 R2 U R U' R2 U' R2 U2 R2 U' R U' R2 A9 2 R2 U' R' U R U R' U2 R' U R2 U R2 A9 2 R U' R U R U R' U' R' U' R2 U' R U' R' A9 2 R' U' R' U R' U2 R' U' R U' R U' R U R A10 3 R2 U' R U' R2 U2 R2 U' R2 U' R U R2 A11 2 R2 U R2 U R' U2 R' U R U R' U' R2 A11 2 R' U' R U' R2 U' R' U' R' U R U R U' R A11 2 R U R U' R U' R U' R' U2 R' U R' U' R' A12 3 R U R2 U' R2 U' R2 U2 R2 U' R' U R U2 R' P1 2 R U2 R' U' R U R2 U' R U' R' U2 R U2 R U2 R' P1 2 R U2 R' U' R U' R' U' R U2 R' U' R U' R' P2 1 R' U' R U R U2 R' U' R U' R2 U2 R P3 1 R U2 R2 U' R U' R' U2 R U R U' R' P4 1 R U R' U R U2 R2 U2 R U R' U R P10 1 R U2 R2 U' R' U R U' R' U' R' U' R' U2 R P11 2 R U' R' U R2 U2 R' U' R U' R2 U R U' R' P12 2 R' U' R U' R' U R U' R2 U' R' U' R' U R U R U' R H1 1 R U R2 U' R2 U' R U2 R U2 R U' R2 U' R2 U R H1 2 R' U' R U' R' U2 R U R U2 R' U' R U' R' H2 2 R' U2 R2 U2 R U2 R' U2 R U2 R2 U2 R' H3 3 R U2 R2 U2 R' U2 R U2 R' U2 R2 U2 R H4 3
This is really helpful. I just looked at a couple of sheets I found online and compared the algs to the 2-gen move optimal (HTM optimised, sorted by QTM) algs that I genned, so there’s a good chance many of these are better algorithms.

Also I realised it’ll be a pain for a newcomer to try and search for the website, so I’ve added that to the OP.

#### I'm A Cuber

##### Member
Which lines can I make with x2 y2 neutrality?

#### CuberStache

##### Member
Which lines can I make with x2 y2 neutrality?
white/red, white/orange, yellow/red, yellow/orange

The point is that you always have white or yellow on top and green or blue in front so EO recognition is always the same

#### zzcuberman

##### Member
Videos of averages with this? Id like to see it in the works ya know?

#### Devagio

##### Member
I believe YruRU has been developed enough in general terms, I do not sense any huge changes coming; any more changes would either be on a case basis, or personal preference (basically add-ons).

While I am, along with a good number of people I know, pushing it by simply practicing with it as my main method and getting better times; I have decided to invest my time in a new idea which you can find on this thread. It is a much simpler idea than YruRU, but it does seem like a worthwhile pursuit so far. Check it out, it will get you interested for sure.

That said, this thread is obviously open incase anyone has ideas all of us missed, or otherwise.

• CuberStache and Owen Morrison

#### CuberStache

##### Member
A 16.88 ao12 with reconstructions, hopefully this can help bring some substance to the theories presented in this thread
• Only 3 solves were over 60 STM, two had mistakes and the third had the highest TPS of any solve in the ao12; it was an inefficient but fast way to solve the 2-gen state. This is counting things like U' U or R' R' as two moves, basically ETM but not counting rotations. And keep in mind that about half of those moves are 2-gen <R, U>
• I can easily inspect under 15 seconds and can even plan into the extension most solves
• I didn't keep track of my OH times with CFOP but this almost certainly would have beaten my CFOP OH PB ao12
I firmly believe that YruRU is at least a top contender as far as OH methods go.

• • ProStar, trangium, Devagio and 1 other person