Welcome to the Speedsolving.com, home of the web's largest puzzle community! You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

Isn't this 'improved' version just Keyhole followed by L5C/L5E? Solving the last F2L pair normally and following it with last layer is probably better, or maybe MGLS.

It is just improved keyhole. It is definitely better to do L5C->L5E, as one less look and less moves by a long way. Also, L5E algs are out there and are good.

Maybe not using EOLS properly, but influencing F2L pairs is already a very common trick. Using full Eols wouldn't be very useful most of the time as inserting the pair and dealing with the next one would be better than rotationless

I don't think Conjugated OLL would be a bad idea, but it would always require a corner and an edge directly to its right being oriented – this is super common though so not a big deal.
Same with conjugated PLL – you would always need an edge directly to the right of a corner to be solved, but again I don't think this is uncommon.
Of course if you mirror algs so that neither of these are issues.

Yeah, I realized how some cases don't work, so mirroring the slot to get other blocks is a good idea, but the whole method might not work frequently enough.

Yeah, I realized how some cases don't work, so mirroring the slot to get other blocks is a good idea, but the whole method might not work frequently enough.

You could do conjugated oll relatively frequently, then you could do conjugated ttll relative to an edge. If you can recog it. Or one look orientated last slot. It's less algs than zbll.

I propose the name ACE (Attempting to Conjugate Everything).

This method is looking pretty good. It's probably worse than OLL/PLL in terms of averages, but can probably get better singles.

Sometimes it is not possible to conjugate, so you have to do a sledgehammer or something, but when it is possible recognition isn't too bad for orientation (I have been practicing). I don't know TTLL, so I can't say anything about that.

This is pretty much my first good method/subset idea, but I have been reading this thread for a while. I am excited to work on this idea and learn the algs for this method.

An alternative to conjugating OLL could be placing an oriented corner in the slot, and recognizing the case just like a non-conjugated normal OLL. The orientation of the edge in the slot doesn't matter because you can rotate. This doesn't work if the slot edge is in place but twisted, but this is a rare case.

This seems pretty interesting to me!
Recently I’ve been thinking about nothing but LSLL ideas, and I posted in this thread about one idea called ILSLL but realized it was garbage, due to having a bad EO step and having high movecount for such non-ergonomic steps (I have thought of better LS ideas since).

I think the idea in your most recent post should only be used if the corner in the slot is already oriented and slot edge isn’t in slot, and this happens 4 in 15 solved. 27% is high enough that this is worth it, but a different method should be used if the corner in the slot is not oriented.
For the orienting algorithm, there would be 57 cases just like normal OLL, correct? These orienting algorithms could be faster than normal OLL because F2L doesn’t have to be preserved. Just a simple example that comes to my mind is headlights / U can be solved with R U R’ U’ R U R’ U’ R U R’ which is faster than the 9 move RUD algs most people use. If you want to develop this then you could make better OLL algs, (only 57 so wouldn’t take too long) but really only if you want to.

You were suggesting conjugated TTLL and I don’t think that would work, because for any conjugate to work the pieces that are hidden would have to be a solved block because they aren’t affected by the algorithm. Example- In R2 [ Ga perm ] R2, the UR prices have to be solved relative to each other because they won’t be affected, and I’m simply not seeing how you will have at least 2 pieces solved relative to each other after you do the orienting phase (whatever you call it) done for you all the time.

If I am completely misunderstanding something, please tell me so then I’m not dumb anymore xd

An approach for the permuting phase that’s is probably not worth it is to use a total of 24 algorithms to permute in two steps, CP and EP.
CP would have 8 cases, 2 PLL and 6 TTLL, and EP would have 16 cases, 4 EPLL and 12 “L5EP” algs. Edge Permutation can be done entirely 2-gen which is cool I guess lol.

Just some random fact- orienting w/ out conjugates, rotations, setup moves, etc. would be ~350 algs (a ton) and permution would be ~450 (a ton).

Hopefully you can find good stuff from exploring this kind of last slot method!

New Idea: ZZ-Belt-Guimond-WhoKnows-IdkWhatToCallIt - It's called 'Woowy's Method' for now
3x3 Method Steps-

EO-quator: Solves Edge Orientation just like ZZ. But instead of solving DF + DB like in ZZ, you put E layer edges in the equator, but they DO NOT have to be solved. (not a belt) I would assume this step has a very similar movecount to EO-line. CO: Orients the 8 corners on the cube. This is best if you do this in two steps, perhaps: Orient D layer corners, 23 algorithms. Not 7 because you'll have "twisty" oll's like in TCLL. Then you orient the U layer corners, using 7 of the 23 algs. Seperation: Intuitively sorts U/D colors. For example, if you solve white bottom, then after this step you will have a full white side and yellow side. This is intuitive, although simple cases can help you with your efficiency. If you just have to sort one corner, then you can apply R2 U R2 U' R2 to solve Seperation. If you only have to sort one edge, then you can use R2 F2 R2 or M' U2 M. CP: Permutes all the corners. This is just like PBL on 2x2. There are 5-6 algorithms for this. Example: Double Adjacent swap algorithm is R2 U' B2 U2 R2 U' R2. EP Parity: This is kind of a substep of just EP, you make U and D free of parity, so that you could complete each side with normal EPLL's, no W perms or O perms. There are four cases: Solved, Double parity (M2 U2 M2), Top Parity (R2 U2 R2 U2 R2), and Bottom Parity (R2 D2 R2 D2 R2). This is a very simple step, basically just to reduce # of EP cases. Finish EP: You can now solve top and bottom EPLL in one algorithm. There are 24 cases. (5*5-1, U and D are independent)
Example algorithm- Double H Perm can be R2 F2 M2 Fw2 R2 or R2 F2 R2 L2 F2 L2 Finish Equator: This step is identical of Roux LSE 4C step. You simply solve the middle layer, and since all of the edges are oriented, it can be done with just [M,U2] moveset and usually only requires around 4.5 moves.

Stats: // Algorithms- up to 56 | Learnability- about as EZ as ZZ | Average moves- around 42-48 moves
-Planning EO-quator isn't difficult, easier than Roux FB
-Seperation is probably the worst step, maybe there's a better way
-There may be a better way to permute 12 edges at the end (permute D layer, permute equator + U layer?)
-Low # of algs, 56 at max.

This is not really like SSC, it’s like comparing Roux and Waterman, they’re not the same.
I looked at some methods and found the first 2 steps of this is the same Human Thistlewaite method, solve EO + place E layer without solving it, then CO in some way.
So this is similar to HTA.

Edit- PapaSmurf I feel like my posts have been sort of mean to you, I'm sorry

Well, however similar or otherwise it is to SSC, you could use the OL5C step from SSC, because the way it reaches coeo belt is pretty good.

So something like this:
1: non matching eoedge (7)
2: OL5C (12)
3: CP (10?)
4: EP (inc. belt, 2 sub steps). That gives 20 moves for EP for it to be a sub 50 move method. But again, my biggest concern is with the ergonomics.

Hi guys, I am new to the speedsolving forums, but I have made up a method for 3x3 that works similarly like roux. Step 1: make 2 opposite first layer edge pieces.

This is easy, just put in 2 OPPOSITE white edges which must be permuted and oriented. Step 2: Finish making 2 2x2x3 blocks.

As I said, this is very similar to roux. You can do this a variety of ways, i like to use f2l to insert them, but if you have an edge in the empty white edge slots you can use M moves to bring them up into the top layer. Step 3: Corner orientation.
Once you've finished the blocks, you want to orient the corners. You can do this by just looking at the corners and using the cross OLL's to orient the corners.

Step 4: White edge inserting.
Once you're finished corner orientation, you want to put in the last 2 white edges. To do this i have 3 algorithms for this
1. if the white on the edge is facing UP, you want to do; M U2 M'
2. if the white on the edge is facing TOWARDS YOU, you want to do; U' M U M'
3. If the edge is in the slot but FLIPPED, you want to do; (M U M') U (M U2 M')
Step 5: Finishing OLL.
Once the last 2 whites are inserted, you will have 1 of 3 OLLs.
1.

2.

3.

1.
(r U R' U') M2 (U R U' R') U' M'
2.
(R U R' U') r R' (U R U' r')
3.
(r U R' U') r' R (U R U' R')

No no no no. I'm sorry that you have to be told this, but it's a bad method and plenty of people have proposed this previously.

The whole point of doing roux blocks is for efficiency, and the whole point of leaving the M slice open is because l6e is fast. By inserting the DF/DB edges, you defeat the point of leaving the M slice open. You just end up with F2L solved, which would be faster if you just used cross/F2L. Sure some CxLL algs are better than the COLL algs, but not by much and it's certainly not worth sacrificing everything that would need to be sacrificed to use this method.

If you read through the New method/substep/concept idea thread, you'll probably find this mentioned mentioned in some form several times.
It's not good.

Anyway, it's good that you're trying to help out the community by coming up with new methods! However, most ideas have been thought of before and, in general, methods are better in their pure form. If you have any more ideas, try searching the wiki for it or posting in that thread so that other people can critique it first.

I FEEL LIKE A GENIUS AAAA!!! I have a new idea, and its similar to a method I posted in this thread a couple weeks ago, ZZ-Guimond-Woowy-whatever. Basically I found a method that's infinitely better than that.

I've done a bit of looking around, and this is similar in some way to Human Thistlewaite, SSC, Kociemba, and Orient First.

I’ll call this Isom’s Kociemba. You can pick a name if you want. Here's the steps:
------------------------- -Edge Orientation (Edit: EO DL is better)-
Just like ZZ EOline, except without the line. Very easy to plan during inspection, about 5 moves average.
The reason this step comes first is because if you solve CO -> EO, than the EO becomes much harder, but if you do EO -> CO, then Corner Orientation is barely affected. -Corner Orientation (2-gen if you do EO DL)-
Just like 2x2 Guimond, except EO must be preserved, so instead of moveset [R,L,U,D,F,B,] you will have [R,L,U,D,F2,B2]. Not much difference.
For 2x2, average optimal movecount for CO is 3.779 moves, so I will give a realistic number for this step, 5 moves average.
The reason you would want to do CO before E-slice placing is because CO gets actually terrible when the E-slice is solved.
Look at SSC or the method I propose a couple weeks ago on this thread. CO is bad. In this, CO is good.
Resource: Lucas Garron Sortega -Chuck E-layer peices in E-layer-
R E2 R'. Enough said -Seperate Corners-
Very intuitive and simple step. There's like only 6 distinct cases, so you will get used to them very quickly. This could be combined with the next step to make a more efficient solve, but its a bad idea as there would be 100s of cases and recognition would be poor so it wouldn't be any faster. "God's number" for this step is 5 moves.
I just did a quick ao12 and average time was 0.96 and average movecount was 3.75. -Permute Corners-
Just like 2x2 Ortega PBL, except on 3x3. There are 5 algs minimum, 8 algorithms recommended (to prevent x2 rotations and stuff) Diag Top- F R U' R' U' R U R' F' R U R' U' R' F R F' Diag Bottom- R D' R2 U2 R' U R U2 R U2 R D R' Adj. Top- l' U R' D2 R U' R' D2 R2 Adj. Bottom- R' D R' F2 R D' R' F2 R2* Double Adjacent- R2 U' B2 U2 R2 U' R2* Double Diagonal- R2 F2 R2* Adj. Top / Diag Bottom- R U' R F2 R' U R'* Diag Top / Adj. Bottom- R' D R' F2 R D' R*
*same as 2x2 algs.

This is how move calculations are done, probabilty and preAUF's and all- (0*1/36)+(17*1/36)+(13*1/36)+((9+0.75)*4/36)+((9+0.75)*4/36)+((7+1.5**)*16/36)+(3*1/36)+((7+0.75)*4/36)+((7+0.75)*4/36) = 9.027
**Both U and D have to be AUF'ed for double bars case. Also, solved and diag cases doesn't require preAUF.

The reason I permute in this way is because it is crystal clear that CP then EP is so much better than PLL then PLL. Everyone would agree. -UL/UR + DL/DR-
Basically L/R from Roux LSE, except its double. Pretty easy to see what you're doing, and you don't need to know any difficult concepts whatsoever. Most of the time I would solve DL/DR then UL/UR, but you can think of this step however you want.
If you've ever tried Roux, then this step is pretty straight foward.
By the way, you can use non-matching L/R trick to enhance efficiency. For example, you solve DL/DR red/orange, but UL/UR green/blue.
This might make 4c recog slightly worse, but this is usually worth it.

The reason that L/R -> 4c is better than Seperation -> EPLL is the same reason that vanilla Roux doesn't do Solve D edges -> EPLL.
Its simply less efficient with no ergonomic tradeoff, so L/R -> 4c is better. - 4c + 4c -
The edges have been simplified so much that now M layer is just like Roux 4c and E layer is just like 4c. M and E are independent, besides the fact that you can have "parity", for example, the M layer couldn't be solved with just [M,U2] moveset. You can use R2 U2 R2 U2 R2 to fix this "parity". You tell me the movecount and ergonomics for this step
--------------------------

EXAMPLE SOLVE:
Scramble: U R2 D2 L2 F' D2 B D2 L2 R2 B2 F' D' F' D' L B' F' U' F2
y2 // inspection
R2 L2 B' // EO
R' U2 R U' R U2 R' // CO
U' R E2 R u2 U R E2 R' // E-layer placement. There's probably a more efficient way.
U' R2 U R2 // Corner Seperation
D' R' D R' F2 R D' R // Corner Permutation
M2 u2 M2 D' U2 M U2 M U // L/R
M U2 M R2 E2 R2 u2 // 4c
48 STM

Spoiler: More example solves-

Scramble: D L' F2 U F L D' F2 R2 B U2 D2 L2 F' D2 B D2 F' U2 R'
y z2 // inspection
U L D' F // EO
R D' R' U R' // CO
F2 D U L E2 L' // E-layer
D' R2 // Corner Seperation
y R2 U' B2 U2 R2 U' R2 // Corner Permutation
D' M' U2 M' U M U2 M' // L/R
z2 U' F' U2 M2 U2 F U2 // 4c
39 STM

Scramble: B2 R D2 B2 R2 B2 L2 D' U' L2 U' B' L' R' F2 D F2 U' R
B L2 U L B // EO
L' R' U R' U2 // CO
E2 R L2 B2 E' F E2 F // E-layer
U2 L2 // Corner Seperation
D R' D R' F2 R D' R' F2 R2 // Corner Permutation
y M2 U M' U2 M' u2 M2 D M2 U2 M2 // L/R
L2 D2 L2 D2 L2 U M U2 M' U // 4c
51 STM

Scramble: L D R2 B2 L2 F2 D R2 D' B2 D2 R U2 B D L B2 F' D2
y // inspection
R U L' F // EO
R U2 R U' R D2 L // CO
D2 U' R E2 R' // E-layer
U D R2 y' R2 D R2 D' R2 // CS+CP
U' S U2 S' U' M' U2 M' // L/R
U M2 U2 M' U2 M u' R2 D2 R2 D2 R2 D' // 4c
45 STM

Average movecount under 50. Nearly no algorithms to memorize, only 8 CP algs. There also aren’t many dificult concepts. CO and CP are very ergonomic. It's just a lot of intuitive parts that has tons of room for improvement because you will get more efficient and faster once you learn better algs to do certain cases and get used to these intuitive cases, especially CO and E-layer. (soon, I will try to make a resource that basically includes all possible cases for Edge Orientation, Corner Orientation, E-layer placement, and 4c + 4c, to help with ergonomics and efficiency)
This means you won’t be instantly fast with this method, so I guess you would say there is a learning curve to this?
I honestly think this is like the best thing ever. Okay, not best method, I know CFOP and Roux are the best, but this is the best method I have come up with. Everything makes sense and there isn't one step that is horribly inefficent. Everything is just so nice.

What suggestions do you have for this method to improve it?

Nice idea, not new new, but nice. It's (as you said) similar to SSC for a worse belt but better co. Also, for CP it's just squan algs. And ZZ is also the best! (Better than CFOP, but that's another discussion).

The main problem I see with this method is the L/R step. I'd rather solve DL/DR then L6EP (96 algs), but it's a load more algs.
I'm going to write a HARCS file to compare this and SSC. I'll come back with results soon-ish.

EDIT
I'm either bad at HARCS, or HARCS doesn't like me, but from what I can gather, 5+5+8+9.5+5+10=42.5 should be about right, which is quite good. The question then becomes one about ergonomics more than movecount.