# The New Method / Substep / Concept Idea Thread

#### Rnewms

##### Member
It would be nice if you changed i to ' and the solution does not work during Corner+Edge.

#### applemobile

##### Member
Inb4 or you could use petrus.

#### CubeRoots

##### Member
so you are basically orienting the edges during the last half of F2L? I think it's a decent-ish idea but you didn't really explain it very well :/

#### Kirjava

##### Colourful
It's really hard to understand what's going on here, but I think you say that you have to do things multiple times without actually explaining how to do them.

#### Tyjet66

##### Member
Interesting metod. What's you best time with this?

#### Qthulu

##### Member
Inb4 or you could use petrus.
Or you could use Petrus.

However, I quite didn't understand the method. Is it a Petrus-Keyhole hybrid with a touch of ZZ?

#### MatejMuzatko

##### Member
L6E with AUF

I found out that Roux users solve UL and UR edges first and then do L4E... Isn't it more logical to solve ANY 2 edges first (depends on bottom edges), recognise L6E case (or EP case if you solved DB and DF edges) and then do AUF?

I am not Roux user and I don't know if some of Roux users use it, but it's worth to think about....

Aka. Pseudo

#### CubezUBR

##### Member
its not 100% complete and i need comfermation that it dosent allready exist. basically you:
1: solve a 2x2x3 block in the bottom left
2: orient all the remaining corners (6)
3: put ul and dr edges in ul and dr
4: solve the 5 remaining edges like roux i think (im not sure)
i dont know how fast it is or if it allready made and is a known method so sorry and delete this post if you have a problem with it admins

#### AHornbaker

##### Member
2-Gen Solves

Hello Everyone.

For a long time I've wanted to be able to do a 2-gen solve. As a novice cuber, I thought by just making a 2x2x3 I could finish the cube 2-gen. (For those of you who don't know, 2-gen is using only 2 sides) I quickly figured out that this wasn't possible, actually most of the time. Lars says it's only possible about 1/6 of the time. It has to do with the corners. When solving 2-gen (assuming edges are already oriented) you can solve the cube to the point where there is 1.) Nothing needed, the cube is solved 2.) An adjacent corner swap is needed 3.) An opposite corner swap is needed.

To get the cube in a state where you can do a 2-gen finish, you must "fix" the corners so that you can do a 2-gen solve. The problem with this is that by just looking at the cube, you cannot tell which corners need to be switched. My quick solution to this is to put the last two corners on the bottom in the correct spot (a.k.a. permutation) after solving the 2x2x3, then assessing the corner permutation on the top layer. As the corners do not need to be oriented at this point, recognition may be a little tricky at first. Then, you can determine whether there needs to be an adjacent or opposite corner swap, or none at all. My simple fix to this is the algorithm R U R'.

If the 2x2x3 is on BD and two adjacent swapped corners are on UR, this alg will swap the corners, allowing you to do y' and solve with U and R. To avoid having to reassess twice for an opposite corner swap, I have come up with the easy opposite swap alg R U R' F' R' F' R. The same applies for this algorithm; you must have the 2x2x3 on BR and the two bottom corners in the right spots. Using these two algs, you can solve the cube 2-gen after the 2x2x3 step. These extra setup moves may or may not prove to be valuable in a solve.

I want to keep this short and not spell it all out so that it allows you to think about ways to use this, and also because I don't have the drive to develop this method if it gets shot down, or if my idea isn't the best way to apply this concept. It's hard for me to believe that I'm the first person to come across this, but I haven't seen this anywhere else. I will make a brief video if it is requested to show how this is used. Give me your best ideas!

Enjoy!

My original idea was just to add onto the Petrus method and make the EO stage coupled with this corner fixing. A small taste of how this would work is using the adjacent swap alg but putting the swapped corners on UB instead of UR. This will allow you to change the orientation of the FR and UB edges but not fix the edges, so that two corners still must be swapped. This allows you to do both steps at the same time as both EO and corner "fixing" conflict with each other. Clearly there would need to be one set of algs for all this, and probably setup moves to lower the number of algs.

Then, there would have to be some way to solve the cube 2-gen efficiently making the most of 2-gen. Again, more new algs. Personally, I think that 2-gen and more moves is way better than regular algs. I found this out when learning WV. See my page on WV: http://www.speedsolving.com/forum/attachment.php?attachmentid=2853&d=1368391115 Algs would be way faster to execute, no grip changes, faster to learn, and possibly easier to recognize, but I don't have anything definite on that. This stage could be done a couple ways:
1.) solve bottom two layers like Petrus, then one set of LL algs for 6 CO cases and 4 edge perm cases (Petrus users would probably find this fastest)
2.) One huge set of algs (very unfeasible considering the 81 corner orientation cases with edge perms, however if the bottom two corners are solved, that means no corner perms, only 6 CO algs times a couple edge perm algs.
3.) Solve 2x2x3, then 2x2x1 on FR leaving the last slot on FL. Then place last corner (starting to look like Pikas**t) assess, flip corners and EO somehow preserving the 2x2x1 on FR, then y' and 2-gen finish the last 5 corners and 5 edges using one set of algs.
4.) Solve 2x2x3, place bottom corners and assess, fix corners, orient corners (essentially permuting if bottom corners are right), then use F, U, and M moves to orient and permute edges.

I'm sure there are other ways to split it up, and many other applications of this find.

One of my biggest concerns is my idea being shot down because of the existing CLL algs that permute and orient the corners, which would be the most efficient use of the corner assessment. My argument is that these algs are long and hard, and your work would be in vain when you went to permute edges 2-gen. Which of course you would not do. You would probably use U and M moves (plus some well-timed F moves for FR and FL edges, or maybe these would be done before CLL leaving permutation of L5E) Solving this way is almost definitely better than the way I proposed for #4, but that wouldn't be an application of the corner fixing.

Sorry for the rambling. These ideas weren't well-developed.

For more thoughts on this concept, here's my most recent email to Lars (not sure if he has read it yet):
Here's an update on what I've been figuring out so far. I've included headers for reference because this was longer than I intended.

Slight Modifications:
I figured out it's easier to place the last two bottom corners in the right spots, and then assess the permutation of the top layer rather than to place three corners and try and analyze the remaining three. Not a big difference from what I previously explained, but I found it is much quicker and easier on the mind. I'm sure this step will be easy for Pertrus users who do CLL already.

Another thing that will lower the move count is placing the last two bottom corners even if they are swapped. By doing this, you can still easily assess the permutation of the top layer, then factor in for the adjacent corner swap on the bottom corners later.

I have figured out a basic adjacent corner swap (as shown in the video I attached in an earlier email). If the adjacent corners that must be swapped are on the UB intersection, you may do <B U B'> to "swap" the corners. The same concept applies to the other side (UF) and the moves <F' U' F>. However, I have not been able to figure out two things:

1.) How to do an opposite corner swap (maybe you can be of assistance?). I know that doing an adjacent swap alg will "swap" two specific corners, but in the case of an opposite swap, doing this will turn it into an adjacent swap case while leaving me clueless as to the next two corners that need to be swapped. Then, I must "reset" by placing the two bottom corners again, looking at the top layer, then doing the adjacent swap once I have determined the two corners that need to be swapped. To make these two steps into one algorithm, I have been attempting to find a solution by working backwards, so far with no success. Apparently I am not creative enough trying random combinations of moves to induce an opposite corner swap from a solved cube. (As a side note, obviously this can be done with a PLL alg, however I want to keep the move count low and am not particularly interested in the edges at the stage. I have been trying things on a 2x2 cube to simplify and speed up my "testing" of sorts.)

2.) How to orient edges while putting corners in the correct permutation. The main concern for this is if the edges are correctly oriented, but a corner swap needs to be performed (if this is even possible, assuming EO and edge swaps are unrelated). Clearly, I still don't full understand how an F move changes the permutation of the corners from one [of the three categories correct, adjacent, or opposite swap] to another. I know that an adjacent swap alg will flip the orientation of two edges and swap two adjacent corners. I don't know how to do one without the other. It may be possible to some sort of adjacent swap that results in an adjacent swap, in the same way that doing a 3-corner cycle PLL when the U face is turned the wrong way will turn into the same 3-corner cycle case. Also, E (slice) and U moves can be used to change the orientation of edges without changing the permutation of corners. If it is ever understood how F moves interact with the corners, the rest of this will become a lot easier.

EO + Corner Perm Stage:
Coupling the EO of Petrus with this corner "permutation" in one stage will probably require a new list of algorithms. The number of EO cases (I think around six?) times the three categories will be the least number of algorithms needed, not accounting for flipped algs, or where the position of the corners makes the EO case from one into 2 or 4 (not sure if this makes sense). This may occur in the same way that there are # EO cases like there are 21 PLLs instead of 84 PLLs for each U face rotation. When something else is superimposed on something like PLL, for example, the number may rise from 21 to account for more unique cases.

Also, while on the the subject of new algorithms, when the cube is reduced to a 2-gen solve, the 7 OLL cases for all edges oriented (including the solved case) are combined with the 5 PLL cases for correct corner permutation (including the solved case) it would total to 34 total algs (minus the solved case). However this is only for the last layer, and the number of algs for the last two layers (R and U) would be significantly higher and would make recognition very hard. To do this, you would on a very simple level just orient the corners and permute the edges. A more practical approach might be making OCLL or WV algs for 6 corners and using existing Roux alg sets (I think Roux solves the last 6 edges, excuse my ignorance. I will read up on Roux shortly).

*As a note, the difficulty with these corner permutation categories (correct, adjacent and opposite swap) is that they are transferrable between corners. Unlike edges, the "orientation" of corners is not specific to a certain corner. That is why the setup moves of placing the last two bottom edges is necesary, to limit the corner swap case to the four corners on the U layer and therefore reduce the number of cases to be recognized. Also, it is difficult to talk about these categories without calling them permutations. They are not permutations, but three subsets of all the cases [of 6 corner permutations] that will determine the PLL(s) if the case is solved 2-gen.

Related Thoughts:
Keep in mind that all these algs would be 2-gen, very fast to learn, very fast to execute. Although the alg counts/length may be disouraging, it still may be a very viable method. Because there are only 6 moves that can be done (R, R', R2, U, U', U2), then three after that (as each move would alternate faces), it might make sense to rewrite algs using a condensed notation.

One idea I have for a condensed notation is to represent an R or U move with 1, R2 or U2 move with 2, and R' or U' move with a 3. Because each move alternates faces, the sequence would start out with R or U, indicating which face the first move would be on, then proceed with a string of numbers. This might make it faster to learn, execute, and recall, etc., and make it easier to spot pattens between algs. Algs would definitely be shorter in text.

An idea popped into my head that maybe Petrus isn't the right method to apply a 2-gen finish to. I love Petrus and the concepts it was made with, but there's always room for improvement. Clearly, the 2x2x3 step is essential to a 2-gen solve, but maybe there are better, more systematic ways of making this that makes the rest of the solve easier. Maybe something along the lines of x-cross or ZB/ZZ (can't remember right now if either is the right acronym) would solve EO at the same time. Any way, I think if this method turns out to be viable, it may have valuable applications to a new method, 2x2 solves, and probably fewest movest competitions.

I've been playing around with a new 2x2 method where during inspection you could figure out how to separate the yellow and white, for example, on the top and bottom layers as well as get the "correct permutation", then AUF and Orient Both Layers and AUF for a finish. This would need a new set of OBL algs (unless they already exist) and new concepts to learn for inspection. I think this is easily a viable method with a smart inspection, and 48 OBL algs (7 OCLL cases multiplied for both layers, minus the solved case).

Closing:
Hopefully this information was not difficult to follow as I made an effort to express my ideas explicitly. I think this email just about sums up every developed thought I've had about 2-gen solves. I can't imagine that I am the first to come across this concept, as it doesn't seem very complicated. Hopefully it might make the Pertus method faster, lay the groundwork for a new method, or at the very least spark some interesting discussion on the forums. Let me know what you think of all this. If some ideas don't make sense in writing, I can make some mediocre videos illistrating these concepts.

-Austin

##### Member
R U R' F' R' F' R
Nope, that alg flips the edges, leading to a non 2-gen solve

Also assuming that edges are oriented is wrong because after building a 2x2x3 block you have one of 4 edge orientation "cases" (amount of misoriented edges)

#### Renslay

##### Member
Noah's CP method solves the 2x2x3 part in a way that the remaining parts can be finished with 2-gen. It fixes the corner-problem (as well as the edge orientation) in an early step; so when you finish the 2x2x3, the cube is already in <R,U>.
It's not a speed method, but it is fun and one of my favorite methods.
CP1 is Petrus-like, CP2 is Roux-like.

#### Kirjava

##### Colourful
it's weird how people think 2 gen is some holy grail for solving

#### mDiPalma

##### Member
ZZ-Porky incorporates the same basic solving approach with accurate algs and a good recognition system.

it's weird how people think 2 gen is some holy grail for solving
It's a really easy way for a 1LLL, assuming you know the alg set.

#### Kirjava

##### Colourful
It's a really easy way for a 1LLL, assuming you know the alg set.
Sure, 2GLL is a great step. Unfortunately, every method that incorporates it seems to have trouble getting to that step efficiently. (CPEOLL -> 2GLL might be a decent LL method though).

A notable nuance of 2GLL is that the <R,U> solution isn't even always the best solution for the 2GLL case.

#### AHornbaker

##### Member
Sure, 2GLL is a great step. Unfortunately, every method that incorporates it seems to have trouble getting to that step efficiently. (CPEOLL -> 2GLL might be a decent LL method though).

A notable nuance of 2GLL is that the <R,U> solution isn't even always the best solution for the 2GLL case.
True. I've been pretty fascinated by the idea of CP fixing lately. I've spent a lot of time reading up on Noah's CP and the CPLS and F2LL pages on the wiki. One of a couple ideas i've been playing with lately goes like this:

-1x2x3 (FLD)
-2x2x2 (BRD) using R, r, and U
-EO and FD edge
-CP/LS
-CO/EP

I'm pretty hooked on it. Roux block during recognition, super fast 2x2x2 using U, R, and r (the only reason I uses these moves is because another idea I'm playing with does CP before the 2x2x2 block), then EO using the same moves (I'm a total noob here, any help/pages would be appreciated) recognize CP, fix it and restore EO, last slot, (look-ahead for LL) 2-gen corner orient, 2-gen edge perm. The way I do it now is very slow because I don't know any of the algs, but if it looks good to everyone i'll learn the algs. The alg sets this method needs are: CPLS and F2LL, but CPLS still confuses me for the alg sets I'd use and none of the F2LL links work but the BOCA alg database. Still trying to figure out where and how to do CP, but I really like the idea of an CO/EP alg set. Thoughts?

#### elrog

##### Member
I was thinking about doing CP method, but doing CP later in a solve is inefficient (not necessarily because of move count). So I got the idea of doing it during inspection, but I have not found a way to do it. Also, even if I did manage to find a extremely efficient and easy way to do it, the method would be no better than CFOP or Roux.

I've been looking for ways to solve the last layer along with something else while still using only 2 algorithms. I've looked at a lot of last slot + last layer options, but they have too many algorithms to be proficient with and to recall quickly.

So here's what I've come up with. During F2L, you do not need to worry about the permutation of the E layer edges, only the orientation. This can easily be done by treating opposite colors as the same. You will be able to find better F2L cases more often and have a lower chance of not seeing a pair to make due to pieces being hidden. You will then solve corner orientation or the top layer while permuting the E layer edges. You would then do PLL and EO of the last layer all in one step.

Solving corner orientation with E layer permutation would take 71 algorithms while PLL + EO would take 76 (not including PLL and mirrors). Using Partial edge control would lower the 76 to 62. Recognition for both would be good as with many LL methods.

Pros
- Better F2L cases
- Find pairs easier.

Cons
- more algorithms and all the disadvantages that come with it such as recall and mastering every alg.
- Algs for corner orientation + E layer permutation wouldn't be quick to preform.

I don't think that recall should be much of a problem because neither alg set it overly huge. It would be extremely difficult or maybe impossible to master every one of the algs though. Do you think the better F2L is worth it?

You could also solve edge orientation throughout F2L and have the first alg set preserve edge orientation leaving you with normal PLL.

#### stoic

solve corner orientation or the top layer while permuting the E layer edges
Wouldn't recognition for these edges be awful?

#### rainymood

##### Member
Hi all!

So I have been reading into zz and fooling around with it. Being the total plebian that I am I found the 12 edges too hard to keep track of. Therefore I totally disregarded the 4 yellow edges in the EOline step, creating essentially an easier version of EOline at the expense of the yellow cross.

Has this intermediate step between learning full EOline already been discussed at length?