• Welcome to SpeedSolving.com — the world’s largest puzzle community!

    You’re currently browsing as a guest, which means you have limited access to discussions, resources, member profiles, and community features.

    Join 50,000+ cubers and puzzle enthusiasts from around the world to ask questions, share solves, improve faster, and be part of the community.

    Registration is free, fast, and easy — create your account today.

    Already a member? Log in here to hide this message and start participating.
I like that idea, and I think we can add something to help influence more so EJLS won't be all that is influencing the Orientation.

So what if we changed it to:

I. 2x2x2 in DBL + Slight Influence on EO (For 6+ Bad edges)
II. 2x2x3 + EO + Set up easy Pseudo CE Pair
III. Insert the Pseudo CE Pair into an F2L-Slot while Orienting all of the Corners + Placing E-Slice Edges (One will already be in place from the CE Pair)
IV. CP+EP

This would have more algorithms, but I think it would be more efficient, influencing throughout most of the solve.

Example Solve:
x' z //Inspection
D2 l U2 u' L //2x2x2 + Orientation Influence
R2 U l' D R' D x' //2x2x3 + EO + E-Slice + Some Oriented Corners (Lucky)
R' U2 R U2 R2 U' R' U' R U R2 //CO + 1x1x2 (Cancelled 'R' Move)
D R' U' R D' R U R D' R U' R' D R //CP+EP

36 STM

Used the same scramble as Crafto.
I did something slightly different because of the D-Layer Orientation Skip.
I think it can have decent fingertricks, after 2x2x3 at least, 2G+3G Steps.
Cp in the beginning and force a 2gll?
Here's a basic skeleton I came up with a while ago, seems pretty efficient.
1. FB (Roux block on left)
2. CP
3. SB
4. Roux style EO, I like to place FD and do EO like in FreeFOP
5. Place BD
6. 2GLL
 
Cp in the beginning and force a 2gll?
Here's a basic skeleton I came up with a while ago, seems pretty efficient.
1. FB (Roux block on left)
2. CP
3. SB
4. Roux style EO, I like to place FD and do EO like in FreeFOP
5. Place BD
6. 2GLL

That could work, but I think overall, Roux (Or Briggs2) would probably be more efficient.
Corner Permutation is a hard step to recognize during a Speedsolve with more than 4 pieces.
 
Last edited:
That could work, but I think overall, Roux (Or Briggs2) would probably be more efficient.
Corner Permutation is a hard step to recognize during a Speedsolve with more than 4 pieces.
It's not when they are already oriented.
I think it's a good time now to explain a cool idea I've had recently. I have no idea how good it would be, but it could work.
1. Solve a 2x2x3 block of all pieces oriented, the only ones that have to be permuted are the corners (so solving 2 corners and orienting a 2x2x3 block)
2. Orient then permute the corners, while influencing EO a little bit.
3. Solve the rest of EO.
4. Use RUM or LUM moves to solve the rest of F2L
5. PLL
So 21 alg 1LLL.
Or
1-3 the same
4. Solve Roux blocks instead of F2L
5. L6E.
Again, no idea how it would work, but everything new is worth experimenting is worth experimenting with.
 
hey for a blindsolving idea guys we have our Old pochmann and 3OP for corners, but what about 2OP(at least for corners, could use OP or M2 for edges)
I like the 3OP for corners because the orientation is super easy, but the permutation is difficult. I like the permutation for Old Pochmann because you just memorize a sequence, but the threefold style of orientation is difficult. What if we oriented corners as per 3OP, and then did old pochmann for corners? would it be useful or just hard? I mean cmon, for the orientation I need to memorize almost nothing, and the letters for the corners are confusing(the edges only have 2 orientations so they are fairly easy)
 
hey for a blindsolving idea guys we have our Old pochmann and 3OP for corners, but what about 2OP(at least for corners, could use OP or M2 for edges)
I like the 3OP for corners because the orientation is super easy, but the permutation is difficult. I like the permutation for Old Pochmann because you just memorize a sequence, but the threefold style of orientation is difficult. What if we oriented corners as per 3OP, and then did old pochmann for corners? would it be useful or just hard? I mean cmon, for the orientation I need to memorize almost nothing, and the letters for the corners are confusing(the edges only have 2 orientations so they are fairly easy)
I used to use boomerang for corners; that's a fast orient-permute method which solves one corner at a time. But it's slower than just solving them with OP. (E: with oriented corners, the OP algs are very bad, so if you want to do this use boomerang)

However... there's very little use in 3OP/2OP. It's not fast, at least, not compared to solving the pieces without fixing their orientations first. The only reason why you'd want to learn it is to reduce the number of algorithms to learn: there's only one for OP!
 
It's not when they are already oriented.
I think it's a good time now to explain a cool idea I've had recently. I have no idea how good it would be, but it could work.
1. Solve a 2x2x3 block of all pieces oriented, the only ones that have to be permuted are the corners (so solving 2 corners and orienting a 2x2x3 block)
2. Orient then permute the corners, while influencing EO a little bit.
3. Solve the rest of EO.
4. Use RUM or LUM moves to solve the rest of F2L
5. PLL
So 21 alg 1LLL.
Or
1-3 the same
4. Solve Roux blocks instead of F2L
5. L6E.
Again, no idea how it would work, but everything new is worth experimenting is worth experimenting with.
That seems like a great idea, but not too efficient. What about this:

1. FB with the E-slice edges not necessarily permuted, just oriented and in the E-slice
Movecount: ~6
2. Create the second FB with nothing but oriented pieces and the E-slice edges in the E-slice (you can leave one corner misoriented if that is the best option
Moveset: <RrUu>
Movecount: ~6-7
3. Orient the remaining corners with EJLS
Moveset: <RU>
Movecount: ~7-8?
4. Seperate and permute the corners while intuitively permuting the E-slice and solving the SB
Moveset: <RrUuD>
Movecount: 14
5. L6E
Moveset: <MU>
Movecount: 12

Moveset: Mostly pseudo 2-gen with some D moves for the 4th step
Movecount: ~47 STM

Or to make this even more efficient you can do this:

1. FB with Only oriented pieces but E-slice edges in the E-slice
Movecount: Perhaps as low as 4-5
2. Same as above
3. Same as above
4. Seperate and permute the corners while intuitively permute the FB and SB (much harder than above but still just about as efficient)
Moveset: Still <RrUuD>
Movecount: Still about 14, maybe even 13 since we aren't restricted by the FB in the beginning
5. Same as above

Moveset: Still mostly pseudo 2-gen with some D moves for the 4th step
Movecount: The movecount drops to 42 STM

The second variant is undoubtedly more efficient but the 4th step is way more complex since you have to figure out a way to seperate the corners while fixing the E-slice then simultaneously permute the corners and line them up the 2 different edges, whereas in the first variant we just seperate and fix the E-slice then permute the corners while lining them up with one edge. The first variant is probably faster because lookahead is easier. The question is does that lookahead make up for the extra 5 moves? I don't know, but I think the first variant is faster, and both variants only require 16 algs for a very efficient solve.
 
I used to use boomerang for corners; that's a fast orient-permute method which solves one corner at a time. But it's slower than just solving them with OP. (E: with oriented corners, the OP algs are very bad, so if you want to do this use boomerang)

However... there's very little use in 3OP/2OP. It's not fast, at least, not compared to solving the pieces without fixing their orientations first. The only reason why you'd want to learn it is to reduce the number of algorithms to learn: there's only one for OP!
what is boomerang and how can I find a tutorial for it.
also, the 3-cycle thing is hard to comprehend and do blindfolded.
and if I do orienting first, i dont need to worrk about which algorithm to use for that orientation. theres a few things i like and hate about 3OP.
 
what is boomerang and how can I find a tutorial for it.
If you google it it's literally the first, second and third result. Searching isn't that hard.

also, the 3-cycle thing is hard to comprehend and do blindfolded.
Not really, I've heard it's very similar to learning F2L, and that's also what I found when I tried to learn it twice (though I stopped after a short time because I lost interest in BLD).

and if I do orienting first, i dont need to worrk about which algorithm to use for that orientation. theres a few things i like and hate about 3OP.
Well with 3-style I don't think most people think about which pieces you're cycling and then what orientation those are in. I just look at which stickers I'm cycling.
 
Hey guys, elaborating on the L2S Idea, here's mine(~10 new algs if you know OCLL and PLL)
-petrus block
-2x2x3
-solve the last D-face edge and solve one of the last 2 e-slice edges
-solve the last CE pair with VHLS(like 5 algs)
-MGLS -I algorithms(7 algs)
-solve the last corner by placing it above where t goes and executing a triple sledgehammer
-PLL
 
I was hanging out with a Clarkeeyyy recently, reminded me about the fact that I wasn't entirely happy with my own weird 5x5 method (has some similarity to Yau5). Mostly that I can only start on W/Y centers (for white cross), for the same reason I have that problem on 4x4 with Yau. This time, I actually figured out something that I like. This is mostly for fun, but should also be decently fast in theory. May also be 4x4 viable.

1) Opposite centers (not cross colour)
2) Two cross edges, place at DL/BL (see video for details, or try it out and see how this has to work to make sense)
3) D/B centers with cross colour on D
4) Place the two cross edges with D'L' (optional: ensure BL has no cross pieces)
5) Finish L2C and cross somehow, can take tips from Hoya
6) Rest of solve

 
Hey guys, elaborating on the L2S Idea, here's mine(~10 new algs if you know OCLL and PLL)
-petrus block
-2x2x3
-solve the last D-face edge and solve one of the last 2 e-slice edges
-solve the last CE pair with VHLS(like 5 algs)
-MGLS -I algorithms(7 algs)
-solve the last corner by placing it above where t goes and executing a triple sledgehammer
-PLL

It looks like spending the moves using VHLS, MGLS, and Triple-Sledge, will probably take more moves then just solving the 2 slots normally, OLL, then PLL.

Most thoughts on L2S is orienting the U-Layer from one slot, and then solve the rest of the cube with the other. I don't think that some of the algorithms would be very efficient, but recognition and lookahead isn't very hard to have in this L2S way.
 
It looks like spending the moves using VHLS, MGLS, and Triple-Sledge, will probably take more moves then just solving the 2 slots normally, OLL, then PLL.

Most thoughts on L2S is orienting the U-Layer from one slot, and then solve the rest of the cube with the other. I don't think that some of the algorithms would be very efficient, but recognition and lookahead isn't very hard to have in this L2S way.
algorithm efficiency, and I can execute the L2S in less time than the actual Petrus EO and then F2L and then OCLL
 
algorithm efficiency, and I can execute the L2S in less time than the actual Petrus EO and then F2L and then OCLL

I don't really try to think about how many algorithms there would be to solve using a specific method/subset (Unless it is seriously high, such as 1LLL). It is pretty much true that the L2S you proposed is faster than Standard-Petrus.

I have no idea if I am going to make a complete change of my main method, CFOP. I am thinking of ways I can use the 4 CE Pair Inserts to influence the last layer to the point that you can skip it entirely (Sounds like a little too much influencing).

I have looked into other methods to see what I can influence to try to get a last layer skip. I have tried out Petrus, by Permuting the Corners and Orienting the Edges. I got a 33 STM Solve by doing so. It was still not a last layer skip but I skipped OCLL + CP.
 
That seems like a great idea, but not too efficient. What about this:

1. FB with the E-slice edges not necessarily permuted, just oriented and in the E-slice
Movecount: ~6
2. Create the second FB with nothing but oriented pieces and the E-slice edges in the E-slice (you can leave one corner misoriented if that is the best option
Moveset: <RrUu>
Movecount: ~6-7
3. Orient the remaining corners with EJLS
Moveset: <RU>
Movecount: ~7-8?
4. Seperate and permute the corners while intuitively permuting the E-slice and solving the SB
Moveset: <RrUuD>
Movecount: 14
5. L6E
Moveset: <MU>
Movecount: 12

Moveset: Mostly pseudo 2-gen with some D moves for the 4th step
Movecount: ~47 STM

Or to make this even more efficient you can do this:

1. FB with Only oriented pieces but E-slice edges in the E-slice
Movecount: Perhaps as low as 4-5
2. Same as above
3. Same as above
4. Seperate and permute the corners while intuitively permute the FB and SB (much harder than above but still just about as efficient)
Moveset: Still <RrUuD>
Movecount: Still about 14, maybe even 13 since we aren't restricted by the FB in the beginning
5. Same as above

Moveset: Still mostly pseudo 2-gen with some D moves for the 4th step
Movecount: The movecount drops to 42 STM

The second variant is undoubtedly more efficient but the 4th step is way more complex since you have to figure out a way to seperate the corners while fixing the E-slice then simultaneously permute the corners and line them up the 2 different edges, whereas in the first variant we just seperate and fix the E-slice then permute the corners while lining them up with one edge. The first variant is probably faster because lookahead is easier. The question is does that lookahead make up for the extra 5 moves? I don't know, but I think the first variant is faster, and both variants only require 16 algs for a very efficient solve.
Cool idea, but I suck at L6E.
I think we may be on to something with "orientation block building" (that's what I'm gonna call it).
The next idea I have sound pretty crazy, and it is, but I like the fact that if is original.
1. Solve a roux block on the left, while orienting and placing E slice edges in the E layer, not nessecarily permuting them (though it probably is just better to solve them).
2. Solve the top 2 M slice edges and the corners to the right of them, almost building a sideways roux block on the top right while orienting the other corners.
3. Solve the 1x1x3 block in the top left with an algorithm.
4. Finish the cube with an algorithm (a sideways roux block in the bottom left and the last LL edge).
An odd method and mostly a start to something else, but it could be the Mossey method after some serious refining.
 
Cool idea, but I suck at L6E.
I think we may be on to something with "orientation block building" (that's what I'm gonna call it).
The next idea I have sound pretty crazy, and it is, but I like the fact that if is original.
1. Solve a roux block on the left, while orienting and placing E slice edges in the E layer, not nessecarily permuting them (though it probably is just better to solve them).
2. Solve the top 2 M slice edges and the corners to the right of them, almost building a sideways roux block on the top right while orienting the other corners.
3. Solve the 1x1x3 block in the top left with an algorithm.
4. Finish the cube with an algorithm (a sideways roux block in the bottom left and the last LL edge).
An odd method and mostly a start to something else, but it could be the Mossey method after some serious refining.

That is a pretty strange idea.
It almost seems like this method creates an "Anti-2x2x3" by solving everything except for a 2x2x3 space, and an edge.
I am not sure how efficient the algorithms would be, along with recognition, due to pieces being on opposite sides for step 3.
I will try making an example solve on it, and see how efficient the method is.

y //Inspection
F2 D2 L' R u //First Block
U M U R2 U' R //Place E-Slice Edges
U B2 L F R' U' R F' R' F U' M //Partial UR Block + CO
x F' L F' M D' M' F2 D F L' F' //1x1x3
R' D R D' R D S' R S D' R' F' R F R' //L6P

49 STM

Yeah...
The first block was too easy to try and place the E-Slice along with.
The Last step seems to have the longest algorithms, along with the 2 previous steps.
 
Last edited:
That is a pretty strange idea.
It almost seems like this method creates an "Anti-2x2x3" by solving everything except for a 2x2x3 space, and an edge.
I am not sure how efficient the algorithms would be, along with recognition, due to pieces being on opposite sides for step 3.
I will try making an example solve on it, and see how efficient the method is.

y //Inspection
F2 D2 L' R u //First Block
U M U R2 U' R //Place E-Slice Edges
U B2 L F R' U' R F' R' F U' M //Partial UR Block + CO
x F' L F' M D' M' F2 D F L' F' //1x1x3
R' D R D' R D S' R S D' R' F' R F R' //L6P

49 STM

Yeah...
The first block was too easy to try and place the E-Slice along with.
The Last step seems to have the longest algorithms, along with the 2 previous steps.
It could maybe work with some refining. The last step definitely needs to be fixed, and I think the first and second steps can maybe less influence the next step but maybe the last ones?
I am out of ideas atm and am pretty tired, but I'll post anything I think of here.
This could also just be a cool block building experiment.
Also, what's the scramble on this?
 
So it seems to me that if we want to get a method to be more efficient and as a possible Speedsolving method, we can either:

I. Make an efficient method that isn't really a Speedsolving method, and then try to turn it into a Speedsolving method by getting better fingertricks and other things to assist speed.
II. Take an already fast method, and make it more efficient by making changes to the method.
III. Try and make an almost completely new method that has new concepts that can be fast and efficient at the same time.
 
Back
Top