The New Method / Substep / Concept Idea Thread

[Neuro]

Hey everyone,

For a long time, I and many others have wanted to see an FB-first method that ends with easy-to-recognize, face-turning algorithms. This is evidenced by the developments of ZBRoux and LEOR, as well as the numerous proposals of RouxFOP. However, each of these methods have flaws:

• Recognition - ZBRoux and LEOR offend on this front. Both end in ZBLL, and LEOR's EOdM requires the user to look at too many things. One has to ID where the DFDB pieces are, the center locations, and EO - all mid-solve.
• Awkward transitions - ZBRoux and RouxFOP have odd switches between face-turning and MU-turning. See, ending a solve in MU is alright because it only involves one dedicated regrip in the solve - from neutral to MU grip. However, when one introduces MU mid-solve, you switch grip twice - neutral to MU to neutral again. This is physically awkward and changes the way you recognize pieces mid-solve.
• Alg count - ZBRoux and LEOR end in ZBLL, which has a staggering alg count that most people are unwilling to learn.

I believe that I have discovered a method that fixes these issues:

1. FB - Solve a 1x2x3 on the left side of the cube
2. F2L-1c- Solve F2L, but only worry about solving one of the remaining D corners. This is done in two phases:
   1. Square - Solve a 1x2x2 on R
   2. Edges - Solve the remaining 3 F2L edges
3. TOLS - Orient the remaining nine pieces
4. TTLL - Permute the remaining nine pieces

This method boasts Roux's RrUM-heavy nature, the recognition and face-turning aspects of CFOP, and the flexibility of ZZ's LSLL.

FB - ~9 moves​

This is the same as Roux's first step. When paired with x2y neutrality, it is efficient and easy to plan during inspection. Typically, F2L-1c is easier when one influences DR, so this is included in the movecount.​

​

F2L-1c - ~14 moves (?)​

As noted above, this should be done in two phases: square, then edges. This makes the step flexible, allowing the user to leave either DBR or DFR unsolved. Also, the edges phase does not require many MU moves if done well. The movecount and use of MU moves are only slightly higher than that of Roux's SB. Note: I have not done extensive research on movecount for this step or its phases, so 14 moves is my best guess based on solves I have done.​

​

TOLS - ~11 moves, 173 algs​

TOLS comes from the Ribbon Method. It involves OLL-style recognition and, if desired, can be done RrUM-gen. The average movecount of 10 comes from RrUMF-gen, speed-optimized algs, though. This step only works if the unsolved F2L corner slot is in DFR, meaning one must rotate or do a D'/d' when DBR is unsolved. D'/d' is usually better for OH, and this approach is comparable to how ZZ-solvers handle TTLL.​

​

TTLL - ~12 moves, 93 algs​

TTLL comes from the ZZ-CT method. It has PLL-style recognition and can be done with many movegroups depending on the solver's preferences.​

​

TOTAL: ~46 moves, 266 algs. Movecounts are based on what speedsolvers do, not on optimal efficiency.​

​

​

The most difficult step of this method is F2L-1c, as it has somewhat awkward recognition and use of MU when solving edges. However, one should note that this is only one approach to F2L-1c. Better methods may exist. Also, the number of edge cases can be reduced by solving to an L2E state, and algs can be learned for tricky cases. If anyone has suggestions for improvements to F2L-1c, please reply to this message and give me your suggestions.


In short, this method has OLL/PLL style recognition, is RrUM and face-turning heavy, does not require rotations, and is quite flexible. Of course, the tradeoff is alg-count, but 266 is more agreeable than the 493 ZBLL algs.


Below are some example solves. Feel free to suggest names for this method.

Spoiler: Solve 1

 Twizzle link 

 Setup 

B2 U' R2 U' F2 D' B2 L2 F2 L2 D2 L' U L2 R' U' R2 B2 F U2 F

 Moves 

y2 D2 r' D' B F2 //FB (5)
r' U' R U' r U' R2' r' U' M U' r R2' //F2L-1c (13)
U2 r U' r' U r U r' U R U2 R' //TOLS  (12)
R U2' r' F R' F' r U2 R U R' U2 R U2' R' U' //TTLL (16)

Spoiler: Solve 2

 Twizzle link 

 Setup 

D2 B2 F2 U F2 R2 F2 D' F2 R2 D' R2 B' R' F' L U F' R' F' L' D

 Moves 

y' D2 F r2 D' U' F //FB+DR Influencing (6)
U' R2' U' R2 U2 r' U R2 r U2 r U M //F2L-1c (13)
y R U2' R' U2 R U2' R2' F R F' //TOLS (10)
R U' R F2' R2' U R U2 R' U' R U R F2' R2' //TTLL (15)

Spoiler: Solve 3

 Twizzle link 

 Setup 

D2 R D2 F' U F2 D' R U2 F2 D2 R D2 R2 F2 R2 F U L

 Moves 

U' r' U r2 x' U2 r B' //FB (7)
U2 R U' R' U2 R2 U' M U' r' R2 U' M' //F2L-1c (13)
y U2 r U' R' U2 M U' r U' R' U2 M //TOLS (12)
U S R2' S' U' R2 U' R2' U R2 U2 //TTLL (11)

 

[DuckubingCuber347]

Hey everyone,

For a long time, I and many others have wanted to see an FB-first method that ends with easy-to-recognize, face-turning algorithms. This is evidenced by the developments of ZBRoux and LEOR, as well as the numerous proposals of RouxFOP. However, each of these methods have flaws:

• Recognition - ZBRoux and LEOR offend on this front. Both end in ZBLL, and LEOR's EOdM requires the user to look at too many things. One has to ID where the DFDB pieces are, the center locations, and EO - all mid-solve.
• Awkward transitions - ZBRoux and RouxFOP have odd switches between face-turning and MU-turning. See, ending a solve in MU is alright because it only involves one dedicated regrip in the solve - from neutral to MU grip. However, when one introduces MU mid-solve, you switch grip twice - neutral to MU to neutral again. This is physically awkward and changes the way you recognize pieces mid-solve.
• Alg count - ZBRoux and LEOR end in ZBLL, which has a staggering alg count that most people are unwilling to learn.

I believe that I have discovered a method that fixes these issues:

1. FB - Solve a 1x2x3 on the left side of the cube
2. F2L-1c- Solve F2L, but only worry about solving one of the remaining D corners. This is done in two phases:
   1. Square - Solve a 1x2x2 on R
   2. Edges - Solve the remaining 3 F2L edges
3. TOLS - Orient the remaining nine pieces
4. TTLL - Permute the remaining nine pieces

This method boasts Roux's RrUM-heavy nature, the recognition and face-turning aspects of CFOP, and the flexibility of ZZ's LSLL.

FB - ~9 moves​

This is the same as Roux's first step. When paired with x2y neutrality, it is efficient and easy to plan during inspection. Typically, F2L-1c is easier when one influences DR, so this is included in the movecount.​

​

F2L-1c - ~14 moves (?)​

As noted above, this should be done in two phases: square, then edges. This makes the step flexible, allowing the user to leave either DBR or DFR unsolved. Also, the edges phase does not require many MU moves if done well. The movecount and use of MU moves are only slightly higher than that of Roux's SB. Note: I have not done extensive research on movecount for this step or its phases, so 14 moves is my best guess based on solves I have done.​

​

TOLS - ~11 moves, 173 algs​

TOLS comes from the Ribbon Method. It involves OLL-style recognition and, if desired, can be done RrUM-gen. The average movecount of 10 comes from RrUMF-gen, speed-optimized algs, though. This step only works if the unsolved F2L corner slot is in DFR, meaning one must rotate or do a D'/d' when DBR is unsolved. D'/d' is usually better for OH, and this approach is comparable to how ZZ-solvers handle TTLL.​

​

TTLL - ~12 moves, 93 algs​

TTLL comes from the ZZ-CT method. It has PLL-style recognition and can be done with many movegroups depending on the solver's preferences.​

​

TOTAL: ~46 moves, 266 algs. Movecounts are based on what speedsolvers do, not on optimal efficiency.​

​

​

The most difficult step of this method is F2L-1c, as it has somewhat awkward recognition and use of MU when solving edges. However, one should note that this is only one approach to F2L-1c. Better methods may exist. Also, the number of edge cases can be reduced by solving to an L2E state, and algs can be learned for tricky cases. If anyone has suggestions for improvements to F2L-1c, please reply to this message and give me your suggestions.


In short, this method has OLL/PLL style recognition, is RrUM and face-turning heavy, does not require rotations, and is quite flexible. Of course, the tradeoff is alg-count, but 266 is more agreeable than the 493 ZBLL algs.


Below are some example solves. Feel free to suggest names for this method.

Spoiler: Solve 1

 Twizzle link 

 Setup 

B2 U' R2 U' F2 D' B2 L2 F2 L2 D2 L' U L2 R' U' R2 B2 F U2 F

 Moves 

y2 D2 r' D' B F2 //FB (5)
r' U' R U' r U' R2' r' U' M U' r R2' //F2L-1c (13)
U2 r U' r' U r U r' U R U2 R' //TOLS  (12)
R U2' r' F R' F' r U2 R U R' U2 R U2' R' U' //TTLL (16)

Spoiler: Solve 2

 Twizzle link 

 Setup 

D2 B2 F2 U F2 R2 F2 D' F2 R2 D' R2 B' R' F' L U F' R' F' L' D

 Moves 

y' D2 F r2 D' U' F //FB+DR Influencing (6)
U' R2' U' R2 U2 r' U R2 r U2 r U M //F2L-1c (13)
y R U2' R' U2 R U2' R2' F R F' //TOLS (10)
R U' R F2' R2' U R U2 R' U' R U R F2' R2' //TTLL (15)

Spoiler: Solve 3

 Twizzle link 

 Setup 

D2 R D2 F' U F2 D' R U2 F2 D2 R D2 R2 F2 R2 F U L

 Moves 

U' r' U r2 x' U2 r B' //FB (7)
U2 R U' R' U2 R2 U' M U' r' R2 U' M' //F2L-1c (13)
y U2 r U' R' U2 M U' r U' R' U2 M //TOLS (12)
U S R2' S' U' R2 U' R2' U R2 U2 //TTLL (11)

Very nice method. I will definitely be playing around with it. It seems to be very similar to Nautilus-EOLE but arranged differently.

I have just one suggestion. Would not Twisty TTLL be better as a last step?

A link to an up to date TTLL sheet would be appreciated.

 

[Neuro]

Would not Twisty TTLL be better as a last step?

No, and I don't think Twisty TTLL would be worth learning for a user of this method. Here's why:

Twisty TTLL, as far as I understand it, only allows the DFR to be twisted along with whatever corner is in the DFR slot. Also, all current algs only work when the DFR corner is in the U layer. To force a current Twisty TTLL alg, one must ID the location and orientation of the DFR corner during TOLS. This increases recognition time and algcount. Also, this would likely introduce algs worse than current TOLS ones, as they must force DFR into U. Now, this new form of TOLS would be better if one could solve DFR into either U or its correct slot. However, this would introduce a Twisty PLL algset, increasing algcount.

Forcing Twisty TTLL or Twisty PLL requires making both TOLS and TTLL worse. Both increase in algcount significantly and TOLS recog will be made harder. For those reasons, it is worse to end the solve with Twisty TTLL.

I also don't think it is worth it to learn Twisty TTLL or Twisty PLL. FB and F2L-1c do not influence EO or CO, making the likelihood of ending up in a Twisty TTLL/PLL state extremely low.

 

[ruffleduck]

Hey everyone,

For a long time, I and many others have wanted to see an FB-first method that ends with easy-to-recognize, face-turning algorithms. This is evidenced by the developments of ZBRoux and LEOR, as well as the numerous proposals of RouxFOP. However, each of these methods have flaws:

• Recognition - ZBRoux and LEOR offend on this front. Both end in ZBLL, and LEOR's EOdM requires the user to look at too many things. One has to ID where the DFDB pieces are, the center locations, and EO - all mid-solve.
• Awkward transitions - ZBRoux and RouxFOP have odd switches between face-turning and MU-turning. See, ending a solve in MU is alright because it only involves one dedicated regrip in the solve - from neutral to MU grip. However, when one introduces MU mid-solve, you switch grip twice - neutral to MU to neutral again. This is physically awkward and changes the way you recognize pieces mid-solve.
• Alg count - ZBRoux and LEOR end in ZBLL, which has a staggering alg count that most people are unwilling to learn.

I believe that I have discovered a method that fixes these issues:

1. FB - Solve a 1x2x3 on the left side of the cube
2. F2L-1c- Solve F2L, but only worry about solving one of the remaining D corners. This is done in two phases:
   1. Square - Solve a 1x2x2 on R
   2. Edges - Solve the remaining 3 F2L edges
3. TOLS - Orient the remaining nine pieces
4. TTLL - Permute the remaining nine pieces

This method boasts Roux's RrUM-heavy nature, the recognition and face-turning aspects of CFOP, and the flexibility of ZZ's LSLL.

My primary issue with methods of this nature (Roux-type methods with (LS)LL finish) is that it only highlights the dominance of Roux. As a ZZ solver, I view Roux as the most effective method by a margin. However, I recognize that Roux requires a very specific skill set and may not be ideal for everyone. So, methods like these have no practicality from my view, because they demand the skill sets of Roux (solving pieces in FB-solved states <R, Rw, U, M>, recognizing pieces in said states in the Rw portion, etc) while being strictly worse than Roux. Why is Roux better? Let's take the intermediate state of what you call "F2L-1c": FB solved and 122 solved on R, for this is where your method and Roux diverge. Roux requires at this stage to 1) solve FR slot to complete SB 2) CMLL 3) LSE. Your method's approach is 1) solve remaining 3 edges of F2L 2) TOLS 3) TTLL. Roux is better in each of those steps. Solving FR slot is significantly better than the solving 3 remaining edges step, I hope is evident. CMLL is a compact and heavily optimized alg set and is better than the significantly denser TOLS set. (I will concede that with some work, TOLS may be able to be developed to be only a smidge worse theoretically than CMLL, judging from the movecount average, but the practical challenge of learning, maintaining, and recalling 173 algorithms compared to the simple CMLL remains.) Lastly, LSE against TTLL is hardly a fair comparison. LSE is nearly comparable to PLL in terms of speed, while TTLL's average alg quality is borderline as bad as the worst ZBLL's.

I appreciate that--unlike most--you introduced some fresh concepts in the context of RouxFOP type methods. I have never considered the concept of TOLS before (as a ZZ solver, I have the luxury of never worrying about edges not being oriented haha) and I had to research its algs. However, I don't think this method has much practical application, as all those who are lucky enough to have Roux skills use Roux, while stragglers like me use <R,U,F,L> F2L type methods.

 

[Neuro]

My primary issue with methods of this nature (Roux-type methods with (LS)LL finish) is that it only highlights the dominance of Roux. As a ZZ solver, I view Roux as the most effective method by a margin. However, I recognize that Roux requires a very specific skill set and may not be ideal for everyone. So, methods like these have no practicality from my view, because they demand the skill sets of Roux (solving pieces in FB-solved states <R, Rw, U, M>, recognizing pieces in said states in the Rw portion, etc) while being strictly worse than Roux. Why is Roux better? Let's take the intermediate state of what you call "F2L-1c": FB solved and 122 solved on R, for this is where your method and Roux diverge. Roux requires at this stage to 1) solve FR slot to complete SB 2) CMLL 3) LSE. Your method's approach is 1) solve remaining 3 edges of F2L 2) TOLS 3) TTLL. Roux is better in each of those steps. Solving FR slot is significantly better than the solving 3 remaining edges step, I hope is evident. CMLL is a compact and heavily optimized alg set and is better than the significantly denser TOLS set. (I will concede that with some work, TOLS may be able to be developed to be only a smidge worse theoretically than CMLL, judging from the movecount average, but the practical challenge of learning, maintaining, and recalling 173 algorithms compared to the simple CMLL remains.) Lastly, LSE against TTLL is hardly a fair comparison. LSE is nearly comparable to PLL in terms of speed, while TTLL's average alg quality is borderline as bad as the worst ZBLL's.

I appreciate that--unlike most--you introduced some fresh concepts in the context of RouxFOP type methods. I have never considered the concept of TOLS before (as a ZZ solver, I have the luxury of never worrying about edges not being oriented haha) and I had to research its algs. However, I don't think this method has much practical application, as all those who are lucky enough to have Roux skills use Roux, while stragglers like me use <R,U,F,L> F2L type methods.

Thank you for the response. I think these are solid critiques, though overstated. Here's why:


"Roux requires a very specific skillset...[FB-first face-turning methods] demand the skill sets of Roux...[RrUM movegroup turning and recognition]...while being strictly worse than Roux."

This is probably true for most people, but there is a case for FB-first face-turning methods. Some solvers, myself included, find RrUM-gen turning ergonomic and easy to recognize but struggle with LSE, whether OH or 2H. This makes face-turning endings an appealing choice. If one is good enough at RrUM+face-turning, I think this method could be quite competitive. It would probably be comparable, though not faster than, Roux for OH/2H, but it has an advantage for big cubes. Granted, this is just an opinion, though it is substantiated by things brought up later in this post.​

​

​

"[F2L-1c vs Roux SB]...Solving [last slot] is significantly better than the solving 3 remaining edges step..."

Solving LS is better than 3 remaining edges, but it isn't quite as big a difference as it seems. The movecount and ergonomics are only slightly worse, and recognition is not terribly difficult when a structured approach is used. See, most of my solutions begin with solving either DF or DB. This results in an L2E state, which is easy to recognize and has only a handful of non-obvious cases. This is now comparable to Roux LS.​

​

Note how the example solves handle L3E: Solve one solves DF while influencing L2E, then solved that Solve two solved DB while influencing L2E, then solved that. Solve three solved DF while influencing L2E, then solved that.​

​

Perhaps an improvement to L3E is this: Solve a dM edge, then do L2E algorithms. This approach would be less efficient, but easier to recognize and execute. Further, L2E influencing during dM edge could be done by experts. Is this as good as LS in SB? No, but it's close.​

​

"CMLL...is better than...TOLS..."

​

This is true. CMLL is among the best-optimized alg sets we have. However, I don't think that TOLS is substantially worse, and it makes the rest of the solve simpler.​

​

TOLS is a large algset, but it's not outrageous. It's essentially extended OLL, making recog and recall easy. Also, the algs are already quite good, even though they haven't been extensively developed. For those reasons, I believe the algset could be comparable to OLL recognition and execution times.​

​

TOLS -> TTLL is a bit easier than CMLL -> LSE. See, CMLL -> LSE at the highest level requires one to know how CMLL affects EO and edge location. This is how top Roux solvers have such fluid L10P, and it's a fair amount to learn and remember mid-solve. TOLS -> TTLL does not require this knowledge or recollection, allowing for easy recognition of two alg cases. For this reason, it could be easier to solve F2L-1C -> TOLS -> TTLL than it is to solve SB -> CMLL -> LSE. It may even be faster on big cubes and in the hands of people with absurd face-turning TPS.​

​

​

"LSE against TTLL is hardly a fair comparison. LSE is nearly comparable to PLL in terms of speed, while TTLL's average alg quality is borderline as bad as the worst ZBLL's."

​

LSE is comparable to PLL, yes, but only for the absolute fastest solvers in the world. A huge number of non-elite CFOPers can sub-1 all PLLS, but only a tiny percentage of Roux solvers average below 1.5 second LSE. This isn't bad by any stretch, but it only makes it comparable to TTLL.​

​

Current TTLL algs are quite a bit better than old ones. According to the ZMS-CT spreadsheet, which contains the most current TTLL algorithms, all their algs can be done sub-1.5 consistently. In theory, this makes TTLL better than LSE for the average person.​

​

​

Basically, this method is at least close to viable. This is because RrUM+face-turning can be quite fast, especially on big cubes; L3E is only slightly worse than SB last slot; TOLS is a fast algset; F2L-1c -> TOLS -> TTLL has easy recog, recall and no LSE regrip; and TTLL is comparable to LSE for the vast majority of people.


In theory, here's how I think this method compares to Roux for 2H 3x3x3 in terms of splits:

FB = ~.9 FB = ~.9​

SB = ~2.25 F2L-1c = ~2.6​

CMLL = ~.9 TOLS = ~.9​

LSE = ~1.5 TTLL = ~1.25​

​

Roux = ~5.55 secs New Method = ~5.65 secs​

In spite of all this, I'm still skeptical because of F2L-1c. It is certainly not the worst step ever devised, but it is worse than SB, and the gap between those steps can't be known without evidence from speedsolves. I hope to develop resources for F2L-1c, practice it, and come back with results in a few weeks. I'll only have confidence in this method as a "Big X" contender if F2L-1c can compete with SB.


Again, thank you for the critiques. They made me more deeply consider the method and its pros/cons. Please let me know if I didn't address something adequately or if new concerns have come to your mind.

 

[PapaSmurf]

I've come up with the idea of EObelt since 2021 but followed in a different route, since CO's gonna be an extremely large alg set.
I like EOline but it is difficult to follow the F2L pieces after it. CO is much easier to recognise,
especially when it's 2-look, where there's no need for looking at all the corners once.
My method (ECSCE? Perhaps):
1 EOBelt. Usually starts with an EOLine on the left. The two remaining edges are often easy to find with looking at the L F and R face.
2 2look-CO. Each alg orients 4 or less corners.
3 Separation. Separate white pieces with yellow. (No need for any permutations)
4 CP. 8 algs required.
5 EP. 60 algs required.

I found that only the 3rd step required to look at the D face, which made the recognition easier.
It's obviously available to adjust the final steps so that it'd be possible to use PBL.
Most of the algs are supposed to be RUD-gen.(at least right-handed)

Check out SSC. It has all this but maybe slightly better. The problem with these types of methods have always been the post-orientation steps because efficient solutions have bad ergonomics and high TPS solutions have terrible movecount. It would be good to have a solution to this.

 

[Twisted101]

i have an idea to create an interesting method, it will be like one-word story but for a 3x3 method. So I will say a step and the first person to reply makes the second step and second person makes the third step, etc.
Step 1:
EO222 in dbl

 

[Jorian Meeuse]

i have an idea to create an interesting method, it will be like one-word story but for a 3x3 method. So I will say a step and the first person to reply makes the second step and second person makes the third step, etc.
Step 1:
EO222 in dbl

Step 2: RUF-gen finish

 

[ProStar]

Step 2: RUF-gen finish

Step 3: stop timer

 

[sDLfj]

Step 3: stop timer

Step 4: Complain about how slow the solve was

 

[ProStar]

Step 4: Complain about how slow the solve was

Step 5: change the time the judge wrote down while they aren’t looking

 

[Thom S.]

Step 6: go to the forum and write a lenghty post about how this method is just not good but not after writing an even lenghtier post about how this method i still better than ZZ/Roux/CFOP (change depending on which method you have the most radical feelings about)

 

[ProStar]

Step 6: go to the forum and write a lenghty post about how this method is just not good but not after writing an even lenghtier post about how this method i still better than ZZ/Roux/CFOP (change depending on which method you have the most radical feelings about)

Step 7: dislike spam everyone who disagrees with you

 

[DuckubingCuber347]

Step 7: dislike spam everyone who disagrees with you

Step 8: Repeat Step 6.

 

[ProStar]

Step 8: Repeat Step 6.

Step 9: get fed up with the backlash and make an over dramatic post about how you’re quitting the forums and ask for your account to be deleted

 

[Twisted101]

I just came back to this being the steps

 

[trangium]

No, and I don't think Twisty TTLL would be worth learning for a user of this method. Here's why:

Twisty TTLL, as far as I understand it, only allows the DFR to be twisted along with whatever corner is in the DFR slot. Also, all current algs only work when the DFR corner is in the U layer. To force a current Twisty TTLL alg, one must ID the location and orientation of the DFR corner during TOLS. This increases recognition time and algcount. Also, this would likely introduce algs worse than current TOLS ones, as they must force DFR into U. Now, this new form of TOLS would be better if one could solve DFR into either U or its correct slot. However, this would introduce a Twisty PLL algset, increasing algcount.

Forcing Twisty TTLL or Twisty PLL requires making both TOLS and TTLL worse. Both increase in algcount significantly and TOLS recog will be made harder. For those reasons, it is worse to end the solve with Twisty TTLL.

I also don't think it is worth it to learn Twisty TTLL or Twisty PLL. FB and F2L-1c do not influence EO or CO, making the likelihood of ending up in a Twisty TTLL/PLL state extremely low.

I have a way to force either twisty TTLL or normal PLL with the same algorithm count and quality as forcing normal TTLL. The only drawback is recognition, but the quality of Twisty TTLL makes up for it.

 

[Twisted101]

I have a new idea for a method:

1. 2x2x3 on left
2. CP+EO (from RUP)
3. F2L-1pair
4. perform an algorithm out of 486 algorithms to make and solve the last pair while doing corner orientation
5. EPLL

 

[edward_9x]

I have a new idea for a method:

1. 2x2x3 on left
2. CP+EO (from RUP)
3. F2L-1pair
4. perform an algorithm out of 486 algorithms to make and solve the last pair while doing corner orientation
5. EPLL

I think you need both corner orientation and also permutation to get EPLL, not just orientation, so that would require more algs (maybe it was a typo?)

But this sounds very interesting

 

[Twisted101]

I think you need both corner orientation and also permutation to get EPLL, not just orientation, so that would require more algs (maybe it was a typo?)

But this sounds very interesting

No cuz you solve Corner permutation and edge orientation at same time in second step