The New Method / Substep / Concept Idea Thread

[Hazel]

So, a subset of VLS? I think it would only have 17 cases for the made pair, and 9 for the split pair.

Yep! So the number of algs would range from 9 to 52, 9 if you’re just doing joinable from one angle, 52 for both joinable and connected and with pairs in the back.

 

[Thom S.]

I thought of a LSLL subset that may actually be useful. The idea is that if there's a 1x3 block on the last layer of the LL color and the LS is paired or joinable, then you can use an algorithm to solve the LS and OLL at the same time. I've generated a few algs so far, and they aren't bad.

Sounds pretty useful but the 1LLL Subset with a line is also just 53 Algorithms/54 for flipped line, and Jabari himself said they are fast so some LS algorithms where you don't break the line might be even more useful

 

[Hazel]

Sounds pretty useful but the 1LLL Subset with a line is also just 53 Algorithms/54 for flipped line, and Jabari himself said they are fast so some LS algorithms where you don't break the line might be even more useful

That's true, but then you would have to learn twice the amount of algorithms since you would need a handful for preserving the line, and then the 1LLL set.

 

[Thom S.]

That's true, but then you would have to learn twice the amount of algorithms since you would need a handful for preserving the line, and then the 1LLL set.

To be fair, you need the Line VLS Cases and PLL so both of us have a one-look LS and a one-look Last Layer

 

[Hazel]

I've been experimenting with a new 3x3 method I came up with recently, and I think it's actually pretty good. I think of it as a Petrus that's less efficient but has better lookahead:

1) 2x2x3 block in DB
2a) Solve the last 2 E-layer edges
2b) EODF
2c) Insert last 2 corners like you would in regular F2L
3) ZBLL (or COLL/EPLL, etc.)

My best time with this method so far is 11.00, and so far my best Ao50 is 16.92. I've had about 5 or so 13-second solves, and a few 12-seconds ones as well. What I like about this is that there's a lot of flexibility. For example, if during the 2x2x3 stage you see a solved F2L pair that isn't a part of the 2x2x3, you can still insert it to make 2a and 2c a bit faster. I also think there's potential for subsets to make the LL better, like using Winter Variation, Magic Wondeful, VLS etc. You could also use CLS if you get a good case for it.
Plus, I personally really enjoy solving with this method, more than CFOP actually

Here's an example solve:

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

z2 F2 U L' B2 D2 F' D L U2 L2 // 2x2x3 (10/10)
F' L' U L // E-layer (4/14)
M' U M U' M' U' M U2 M' U M // EODF (11/25)
U2 L' U L U2 L' U L // Left corner (8/33)
y' U' L' U R' U' L U R // CLS (8/51)
U' R2 F2 R U2 R U2 R' F R U R' U' R' F R2 // G-perm (16/67)

Again, not very efficient but each step after the 2x2x3 is very ergonomic on its own and since look-ahead is pretty easy, you can have a high TPS and have fast solves.

 

[Neuro]

Interesting idea mixing PCMS and 42/Roux

1: 1x2x2 block on L
2: Make F2L pairs
3: CxLL
4: L7E

I'm hoping this can get good TPS and high efficiency but it requires testing. The 2nd step is highly variable, I like RUMrF. Should be noted it's pretty easy to plan ahead and get 1 extra F2L pair during inspection (even if it's just the Roux FB). I think it has some potential with improvements. Going to experiment with L7E quite a bit. You can use Roux EO/EOLR to insert DR while doing EO and do LR edges->L4EP. I think an algorithmic approach could be good as well, so I'm checking out buffers/setup to find good algs/systems.

EDIT: Ran analysis on HARCS, and it appears that this is an expected movecount:

FS is ~5 moves
F2L is ~9 moves (this likely raises significantly in human solves)
CxLL is ~11 moves (algs)
L7E is ~13 moves (again, likely raises when human solves)

So theoretically, this is a 38 move method on average. With humans solving, I'd expect ~45 moves in speedsolves. What you can also do is CFOP style F2L when making the pairs. It'll increase movecount, but it's proven to be fast.

 

[Hazel]

I've been experimenting with a new 3x3 method I came up with recently, and I think it's actually pretty good. I think of it as a Petrus that's less efficient but has better lookahead:

1) 2x2x3 block in DB
2a) Solve the last 2 E-layer edges
2b) EODF
2c) Insert last 2 corners like you would in regular F2L
3) ZBLL (or COLL/EPLL, etc.)

My best time with this method so far is 11.00, and so far my best Ao50 is 16.92. I've had about 5 or so 13-second solves, and a few 12-seconds ones as well. What I like about this is that there's a lot of flexibility. For example, if during the 2x2x3 stage you see a solved F2L pair that isn't a part of the 2x2x3, you can still insert it to make 2a and 2c a bit faster. I also think there's potential for subsets to make the LL better, like using Winter Variation, Magic Wondeful, VLS etc. You could also use CLS if you get a good case for it.
Plus, I personally really enjoy solving with this method, more than CFOP actually

Here's an example solve:

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

z2 F2 U L' B2 D2 F' D L U2 L2 // 2x2x3 (10/10)
F' L' U L // E-layer (4/14)
M' U M U' M' U' M U2 M' U M // EODF (11/25)
U2 L' U L U2 L' U L // Left corner (8/33)
y' U' L' U R' U' L U R // CLS (8/51)
U' R2 F2 R U2 R U2 R' F R U R' U' R' F R2 // G-perm (16/67)

Again, not very efficient but each step after the 2x2x3 is very ergonomic on its own and since look-ahead is pretty easy, you can have a high TPS and have fast solves.[/QUOTE]

Edit to this method, CLS is definitely the way to go. Really nice algs, and a 1 in 72 chance of a last layer skip every solve!

 

[Thom S.]

I've been experimenting with a new 3x3 method I came up with recently, and I think it's actually pretty good. I think of it as a Petrus that's less efficient but has better lookahead:

1) 2x2x3 block in DB
2a) Solve the last 2 E-layer edges
2b) EODF
2c) Insert last 2 corners like you would in regular F2L
3) ZBLL (or COLL/EPLL, etc.)

I have neutral feelings about it.
Blockbuilding is basically the same.
2 a,b,c are basically Petrus as the step is called -Finish F2L - and you are just doing EO during it.

What I like about this is that there's a lot of flexibility. For example, if during the 2x2x3 stage you see a solved F2L pair that isn't a part of the 2x2x3, you can still insert it to make 2a and 2c a bit faster. I also think there's potential for subsets to make the LL better, like using Winter Variation, Magic Wondeful, VLS etc. You could also use CLS if you get a good case for it.

Yes, this is why I like FreeFOP so much. You don't really have to have a Method, just use what you get and have a solid game plan

 

[The Pocket Cuber]

This thread is about new methods that can be developed to solve a 3x3, to get the same averages as CFOP. Post methods that could be developed into a viable speedcubing method on this thread, or new ways to solve specific things in methods, (e.g. Last Layer variant). To Start off, I will just briefly post a new method for the 3x3 which I developed and could be as fast as CFOP
The steps:
1. EO, Usually takes about 5 moves. Not sure whether to keep this step in method or not...
2. Blockbuild four corner-edge pairs. This step normally takes 5 moves per pair
3. COLL to solve corners while preserving edge orientation. COLL is I think 10 moves on average
4. L8E. Solve in any way possible. I don't know how many algorithims their would be to solve the rest in one alg, but it would be interesting to see if someone would make that set. What I do is solve the L and R Layer edges, which normally takes 6 moves and permute the M slice which takes 4 moves.

Overall that's a move count of 45, so it's pretty efficient. I hope to see new methods come in this thread soon. Thank You!

 

[DGCubes]

This thread is about new methods that can be developed to solve a 3x3, to get the same averages as CFOP. Post methods that could be developed into a viable speedcubing method on this thread, or new ways to solve specific things in methods, (e.g. Last Layer variant). To Start off, I will just briefly post a new method for the 3x3 which I developed and could be as fast as CFOP
The steps:
1. EO, Usually takes about 5 moves. Not sure whether to keep this step in method or not...
2. Blockbuild four corner-edge pairs. This step normally takes 5 moves per pair
3. COLL to solve corners while preserving edge orientation. COLL is I think 10 moves on average
4. L8E. Solve in any way possible. I don't know how many algorithims their would be to solve the rest in one alg, but it would be interesting to see if someone would make that set. What I do is solve the L and R Layer edges, which normally takes 6 moves and permute the M slice which takes 4 moves.

Overall that's a move count of 45, so it's pretty efficient. I hope to see new methods come in this thread soon. Thank You!

L8E seems tough, especially because rotations would likely be required. If you were to do it in one alg, it would require 2,580,480 algs, which is about 5,000 times the amount in ZBLL. Maybe it could be reduced a bit if you take symmetry into account, but it still wouldn't be humanly feasible.

Spoiler: math

Edge permutation = 8! / 2
Edge orientation = 2^8 / 2
Total L8E cases = EP * EO = 8! * 2^8 / 4 = 2,580,480

 

[The Pocket Cuber]

L8E seems tough, especially because rotations would likely be required. If you were to do it in one alg, it would require 2,580,480 algs, which is about 5,000 times the amount in ZBLL. Maybe it could be reduced a bit if you take symmetry into account, but it still wouldn't be humanly feasible.

Spoiler: math

Edge permutation = 8! / 2
Edge orientation = 2^8 / 2
Total L8E cases = EP * EO = 8! * 2^8 / 4 = 2,580,480

So happy you read this DG (your my favourite YouTuber

But yes, I agree it would be extremely hard to solve L8E in one step, however is that number with all the 8 edges oriented? I'm not good at math. I say this step should be executed by solving the L and R layer edges then permuting the M slice edges. I personally believe this method can be better than CFOP, if anyone has any ideas how this method is or needs changes to be faster, please say so.

Again, thank you so much for reading this, DG, I love you.

 

[The Pocket Cuber]

Over the past few days, I have come up with a method which in my opinion can be faster than CFOP. Please give me direction on whether this 3x3 method is or can be faster than CFOP or why it can;t be or needs improvements to be. Right now I am unsure. I will now go through the steps.
1. Edge Orientation. Speed Cubers say that this is hard when really it isn't, it just takes time to get used to. EO averages 5 moves
2. 4 Corner Edge pairs. Trying to blockbuild this can get you 5 moves on average for each pair.
3. COLL. COLL will preserve your edge orientation while solving the corners
4a. L8E. Solve the L and R layer edges. When done correctly, this averages 6 moves.
4b. Solve the middle layer. Averages 4 moves with easy simple algorithims.

Please let me know if this method is viable, or maybe tell me a different to solve L8E, but now I am unsure.

 

[Thom S.]

This thread is about new methods that can be developed to solve a 3x3, to get the same averages as CFOP. Post methods that could be developed into a viable speedcubing method on this thread, or new ways to solve specific things in methods, (e.g. Last Layer variant). To Start off, I will just briefly post a new method for the 3x3 which I developed and could be as fast as CFOP
The steps:
1. EO, Usually takes about 5 moves. Not sure whether to keep this step in method or not...
2. Blockbuild four corner-edge pairs. This step normally takes 5 moves per pair
3. COLL to solve corners while preserving edge orientation. COLL is I think 10 moves on average
4. L8E. Solve in any way possible. I don't know how many algorithims their would be to solve the rest in one alg, but it would be interesting to see if someone would make that set. What I do is solve the L and R Layer edges, which normally takes 6 moves and permute the M slice which takes 4 moves.

Overall that's a move count of 45, so it's pretty efficient. I hope to see new methods come in this thread soon. Thank You!

Your first sentense makes me sad. This thread is about every Concept/Idea/Full Method you think is viable, not just 3x3 Speedsolving.
Your method seems not too bad, but I doubt it has much potential. Just EO means in between the Pairs could be E Layer edges which need a S2 to get out. Plus I'm actually sure this already exists as a Columns first Variant but I need someone to back me up there

 

[DGCubes]

But yes, I agree it would be extremely hard to solve L8E in one step, however is that number with all the 8 edges oriented? I'm not good at math.

Oh shoot, you're right, I forgot you did EO in the beginning. In that case, it is notably less, at 20,160 algs (8!/2). Still way too many to be feasible, but maybe it could be done in two steps?

Thanks for the compliments, btw.

 

[The Pocket Cuber]

Oh shoot, you're right, I forgot you did EO in the beginning. In that case, it is notably less, at 20,160 algs (8!/2). Still way too many to be feasible, but maybe it could be done in two steps?

Thanks for the compliments, btw.

No Problem
Yes, that's what I suggested. Solving R layer and L layer edges (4 edges) at the same time, if done correctly can be done in 6 moves, than permutation of m slice can be done in about four. I believe this would be the fastest way to solve L8E. This is the fastest way I believe it has potential to be faster than CFOP, is that possible?

 

[The Pocket Cuber]

Your first sentense makes me sad. This thread is about every Concept/Idea/Full Method you think is viable, not just 3x3 Speedsolving.
Your method seems not too bad, but I doubt it has much potential. Just EO means in between the Pairs could be E Layer edges which need a S2 to get out. Plus I'm actually sure this already exists as a Columns first Variant but I need someone to back me up there

Sorry, this was originally in a new thread I created.
I don't think I've seen this anywhere else though (the method)
The edges could also be taken out with D M2, which is easier to finger trick.

 

[shadowslice e]

Step1: perfectly fine and nice and standard.
Step 2: I assume you mean like in PCMS? This a good step in that method though you need to be able to plan a fair amount ahead after EO which remains challenging and one of the main arguments against metods like ZZ. Also, having a reduced moveset possible will make it more inefficient so I'd think that the movecount for each pair will be greater than 5 especially in a speedsolve.
3) All good perfectly standard step (though it might be work looking as some algs which preserve only pairs and EO which may be shorter)
4) Are you sure about that movecount? I have dabbled in similar things because of SSC phase 2 and I usually have a higher movecount that than for that step.
5) middle layer: yep fine nice step.

Additionally, the moveset wold not be a particularly nice one as you don't really reduce the cube group very quickly which could lead to a lot of S2s, and similar which are not very good for speedsolving.

Overall, it is an interesting method and could have some potential though there are definitely some issues which would nee to be addressed before I would consider it definitely "better than CFOP". (It's worth noting I don' consider CFOP to be the best method anyway other than possibly for big cubes).

 

[DGCubes]

No Problem
Yes, that's what I suggested. Solving R layer and L layer edges (4 edges) at the same time, if done correctly can be done in 6 moves, than permutation of m slice can be done in about four. I believe this would be the fastest way to solve L8E. This is the fastest way I believe it has potential to be faster than CFOP, is that possible?

Hmm, if your estimated move counts are correct, I think there's definitely some potential here. I feel like it might not be faster than CFOP though. Comparing each step...

EO is about equal to cross in speed and move count.
F2L is probably a bit better on CFOP; yours has no rotations but is harder to find pieces (because they could be anywhere on the cube).
COLL is comparable to either OLL or PLL in speed/recognition time.
L8E seems like it would be slower than either OLL or PLL, because even if it's decently efficient, it seems hard to recognize and execute.

It doesn't really have any steps that are better than their CFOP counterparts, so personally I wouldn't say it's faster. These are just my opinions though; it's very possible that these steps could be much faster than I'm imagining.

 

[The Pocket Cuber]

Thanks

 

[shadowslice e]

This thread is about new methods that can be developed to solve a 3x3, to get the same averages as CFOP. Post methods that could be developed into a viable speedcubing method on this thread, or new ways to solve specific things in methods, (e.g. Last Layer variant). To Start off, I will just briefly post a new method for the 3x3 which I developed and could be as fast as CFOP
The steps:
1. EO, Usually takes about 5 moves. Not sure whether to keep this step in method or not...
2. Blockbuild four corner-edge pairs. This step normally takes 5 moves per pair
3. COLL to solve corners while preserving edge orientation. COLL is I think 10 moves on average
4. L8E. Solve in any way possible. I don't know how many algorithims their would be to solve the rest in one alg, but it would be interesting to see if someone would make that set. What I do is solve the L and R Layer edges, which normally takes 6 moves and permute the M slice which takes 4 moves.

Overall that's a move count of 45, so it's pretty efficient. I hope to see new methods come in this thread soon. Thank You!

Well, I made a post in your other thread though that appears to have been deleted so I'll rephrase here:

1) pretty standard and not too bad; only issue could be making the next few steps more inefficient
2) Are you *sure* about those movecounts? PCMS has the same movecount for F4P and that doesn't have EO in it (which usually makes it more inefficient) I think a more likely movecount would be about 24-26.
3) again pretty standard not much to comment on (though it may be worth looking at algs which don't preserve the M or S slices as well)
4) Again, are you sure about that movecount? I have dabbled a fair amount in L8E because of SSC phase 2 and I always find the movecount will be higher than that (more like 8 or so). YOU may also want to consider pseudoblocks (like UFUB in Roux) to get your projected movecount.
5) again pretty standard not much to comment on.

Another couple of points I would bring up is that this has significantly harder lookahead compared to most methods (especially CFOP) as well as a worse movegroup. This is because you don't really restrict the cube very quickly by building blocks/ filling in slices/layers.

Overall, I would say the method has some potenting though it definitely does have some issues which would need to be rectified before I would consider it "better than CFOP" (though it's worth noting I don't think that CFOP is the best current method we have anyway).

You might also find a few of the links I'm my sig reasonably useful/interesing to you.

Anyway, I hope to see more methods/improvements from you soon!