The New Method / Substep / Concept Idea Thread

[Arc]

This is pretty different from BOPE, and I though of an idea a while ago that almost the exact same thing and maybe saves a move or two with less algs:

1. FB
2. BR square
3. VOP L5E: this solves the last 5 corners in a similar way to OSC/PSC
4. Crafto's L7E method

EDIT: I typed this up as @efattah posted his response, so you probably don't need to look through both. As he said, this sort of idea was proposed a while ago in the WaterRoux thread and is pretty good.

@efattah as far as I know the only methods that are really being worked on right now are our two methods, LMCF and BOPE. BOPE progress is slow, nobody's really helping me right now with OSC/PSC and I'm yet to find a great way to do L8E. One thing I've though about recently is using TEG with BOPE, it saves a move or two to use a TEG and potentially push Bope under 40 moves. I think it's only worth it to use TEG for LSC if you already know the algs from 2×2, though.

As for the other methods you mentioned, nobody's really found a CPRoux variant that has stuck, and I really think someone just needs to figure out how to do CPFB until it goes anywhere. I believe ZBRoux/LLOB has already been fully developed, as has 2GR. WaterRoux was sort of abandoned since Bope looks better, but it could make a resurgence.

I am doing Briggs (or a variation of it, semantics) which uses CPFB. It seems promising and has the most ergonomic solutions I've ever seen, with a comparatively low move count and 84 algs. The problem is just CPFB (this step is very hard) and EO recognition immediately after (9 edge EO).

(If you're curious):
CPFB
EO 2x2x3
F2L
2GLL

For ZBRoux the method is developed from a technical standpoint but there is still not a single person who knows full ZBLL and has the DFDBEO algorithms memorized, so we don't even have a sample size of 1, to get speed comparison estimates vs. CFOP or Roux... By 'developing a method' I mean to imply that there is at least one person who has memorized all the algorithms and can execute full speed solves with it, and has been using it as a 'main' method (even temporarily) for a few months.

There aren't really EODFDB algs. It's extremely similar to EOLR. Besides that point, Tao Yu knows full ZBLL and said he would try ZBRoux out. However it's not too relevant, because the difference between ZBRoux with COLL/EPLL and ZBRoux with ZBLL is the same as the difference between ZZ with COLL/EPLL and ZZ with ZBLL. Since we know the difference (roughly, there's still contention) between COLL/EPLL and ZBLL, and we can do ZBRoux with COLL/EPLL, we can safely speak of ZBRoux with ZBLL. However your point on someone using it as a main method is definitely relevant. However the first two steps of ZBRoux are exactly the same as Roux, and that is extremely developed. Really what we are left with is EODFDB as the remaining unknown in the equation. I was actually using ZBRoux with COLL/EPLL myself for about a month and a half, and found EODFDB to be a little awkward (felt like a lot more M than M' when compared to LSE, in particular). However I don't consider myself an expert on it by any means and would still like to see other people play with the step. My gut feeling on it is that ZBRoux is a good method but that having multiple CMLLs for EOLR influence and still having fewer algs tips the scales slightly in the favor of Roux.

 

[Thermex]

This idea is very different from that method and from WaterRoux because it has more of a focus on ergonomics and takes much fewer algorithms and might be the first method to have the potential for sub-40 or even sub-35 movecounts. OSC/PSC are integrated into the other steps to skip PSC 100% of the time with just 42 algorithms. Additional algorithms can be learnt to solve the last edge + corners of last layer, reducing movecount even further (for example Tyrannical Caterpillar which I was inspired by partially and is less efficient than TT).

I think we all should start looking into TT method and variants to try and develop it. Perhaps you should try and modify BOPE to incorporate some of the more efficient aspects of TT instead and meanwhile I can investigate some ways to finish L7E in even less than 17 moves.

I don't really see how your idea here could achieve sub-40/35 movecounts, it's literally just Roux with the FR edge unsolved during LSE. Variants of this idea could be developed, but at the current moment I think both Tyrannical Catterpillar and BOPE are a bit better than "TT". I definitely would like to look into ways to solve L7E/L8E with you, though.

Btw using VOP for the last five corners is both more efficient and less algs than doing 1 corner+CMLL.

 

[Tao Yu]

For ZBRoux the method is developed from a technical standpoint but there is still not a single person who knows full ZBLL and has the DFDBEO algorithms memorized, so we don't even have a sample size of 1, to get speed comparison estimates vs. CFOP or Roux... By 'developing a method' I mean to imply that there is at least one person who has memorized all the algorithms and can execute full speed solves with it, and has been using it as a 'main' method (even temporarily) for a few months.

Where can I find DFDBEO algorithms?

I just finished full ZBLL, and I'm decent at F2B and EOLR. I have been averaging 11-13 seconds with ZBroux. At least I'm trying?

 

[efattah]

This idea is very different from that method and from WaterRoux because it has more of a focus on ergonomics and takes much fewer algorithms

The very first proposal for WaterRoux was to omit the FR edge, do CMLL, then solve L7E (which is what you are proposing). Later CMLL was replaced with TCMLL allowing the FRD corner to be solved at the same time as the upper corners. Later full WaterRoux ignored the second block entirely and used TLEG-1.

All of these have potential, as well as tyrannical caterpillar. But I don't think any get sub-40 move counts, and indeed it is really starting to become clear that move counts are not really that important, ergonomics, high TPS, good look ahead are much more important.

As an example, I have been experimenting with dummy move injections. I have found that in certain algorithms, injecting dummy moves that have no effect can speed up an algorithm, by eliminating regrips. This increases the movecount and decreases the time to execute the algorithm.

 

[efattah]

Where can I find DFDBEO algorithms?

I just finished full ZBLL, and I'm decent at F2B and EOLR. I have been averaging 11-13 seconds with ZBroux. At least I'm trying?

Critical Cubing is the only one who has the algorithms, I think.

 

[Teoidus]

I don't really see how your idea here could achieve sub-40/35 movecounts, it's literally just Roux with the FR edge unsolved during LSE. Variants of this idea could be developed, but at the current moment I think both Tyrannical Catterpillar and BOPE are a bit better than "TT". I definitely would like to look into ways to solve L7E/L8E with you, though.

Btw using VOP for the last five corners is both more efficient and less algs than doing 1 corner+CMLL.

Without having done whole solves or seen some of the 6-move CLL cases I think you might not have noticed the efficiency gains of approaching LS/L10P in this way. In addition the solve flows much better compared to BOPE and does not require a pause during an algorithm as Tyrannical Caterpillar does. Overall this is to be the most efficient roux-like method for 3⊗3/BOPE variant, giving a PSC skip every time and being mostly <R,r,U,M> pseudo2gen so it is built around super fast move sequences like efattah has been suggesting recently. This method is an inspired combination of the best features of 3⊗3 method development that have been proposed so far and I think it has the potential to average sub-40 moves on average:

6-7 Big block (minimum?)
7 square + place DRF?
9 CLL + orient DRF (or even less? I've found several 7-8 movers for this step)
17 L7E ? or even less

 

[shadowslice e]

This thread seems to be a reasonable place to ask but what do you mean by a "compromise method" @efattah?

 

[Thermex]

Without having done whole solves or seen some of the 6-move CLL cases I think you might not have noticed the efficiency gains of approaching LS/L10P in this way. In addition the solve flows much better compared to BOPE and does not require a pause during an algorithm as Tyrannical Caterpillar does. Overall this is to be the most efficient roux-like method for 3⊗3/BOPE variant, giving a PSC skip every time and being mostly <R,r,U,M> pseudo2gen so it is built around super fast move sequences like efattah has been suggesting recently. This method is an inspired combination of the best features of 3⊗3 method development that have been proposed so far and I think it has the potential to average sub-40 moves on average:

6-7 Big block (minimum?)
7 square + place DRF?
9 CLL + orient DRF (or even less? I've found several 7-8 movers for this step)
17 L7E ? or even less

Until a sub-15 move method is created for solving L7E (which could probably be made) I really don't see how this could be sub-40 moves. FB is 7, SB+DFR is more like 9 in my experience (I have in fact done example solves with this method), CLL is 9, and L7E is 17. Mix in AUFS and the total is around 44 moves, just a bit higher than Bope. This is highly ergonomic and pretty low-algorithm, so 44 is really good, but as @efattah pointed out things like this (if not exactly this) were proposed during the early development of WaterRoux. And also I still think using VOP L5E is better than inserting the DFR corner and then doing CLL, it's about the same amount of moves with half the algorithms.

The very first proposal for WaterRoux was to omit the FR edge, do CMLL, then solve L7E (which is what you are proposing). Later CMLL was replaced with TCMLL allowing the FRD corner to be solved at the same time as the upper corners. Later full WaterRoux ignored the second block entirely and used TLEG-1.

All of these have potential, as well as tyrannical caterpillar. But I don't think any get sub-40 move counts, and indeed it is really starting to become clear that move counts are not really that important, ergonomics, high TPS, good look ahead are much more important.

As an example, I have been experimenting with dummy move injections. I have found that in certain algorithms, injecting dummy moves that have no effect can speed up an algorithm, by eliminating regrips. This increases the movecount and decreases the time to execute the algorithm.

I'm just starting to realize this more as I cube. There are so many times when I create a TEG algorithm and the 10-11 moves RUF algs are way faster than the 7-8 RUFLxy ones, proving that really, it's just about how fast you can execute the solve. The obsession over movecount is a bit like the obsession over how FAST a cube is, theoretically if the cube turns faster you can get faster times, just like how theoretically if a method has less moves you could get faster times with it.
I see @efattah do this sometimes, and I think we should all start doing this along with movecount as it's just as important. Beside the number of projected moves of a step, also include how fast a Zemdegs-speed solver could do it. After all, cubing is for speed, not moves (unless you're doing FMC).

@Teoidus what I think we really need to do is just make methods (together if you have time) for solving L7E & L8E. Even if we disagree on which method is faster between Bope and TT, these algsets are relevant to both of our methods and any future ones too.

 

[Thermex]

Where can I find DFDBEO algorithms?

I just finished full ZBLL, and I'm decent at F2B and EOLR. I have been averaging 11-13 seconds with ZBroux. At least I'm trying?

There are no real "new" algs for ZBRoux, EODBDF is literally just EOLR but you pretend that the DF and DB edges are the LR edges. Good luck with ZBRoux

 

[Hazel]

So... I kinda made a method that isn't super good or anything but is really fun at least:
1: 2x2x2 block
2: Solve remaining 3 F2L pairs
3: Insert one of the two last First Layer edges, then the second with EODF
4: COLL --> EPLL

I just got a 19.90 mean of 24 with a 14.83 single and 16.97 Mo3

 

[Teoidus]

Approximate movecount: 6 2x2x2 + 3*6 pairs + 3 DR + 7 EODF + 9 COLL + 8 EPLL = 51

 

[Teoidus]

And, on a more serious note: I did have to do some sincere investigation into L7E for "TT" and 17 move average is definitely possible. Here are the first few example solves I constructed. All solutions are found intuitively:

17 stm
17 stm
17 stm
17 stm
16 stm
18 stm

Here is the basic process I'm using:

if (<= 2 moves to solve place a solved edge at UR)
  M* U* R LSE R'
elif (FR oriented)
  EOFR L6EP
else
  EO+forceULUR/UFUB opposite FR L6EP
end

 

[Thermex]

And, on a more serious note: I did have to do some sincere investigation into L7E for "TT" and 17 move average is definitely possible. Here are the first few example solves I constructed. All solutions are found intuitively:

17 stm
17 stm
17 stm
17 stm
16 stm
18 stm

Here is the basic process I'm using:

if (<= 2 moves to solve place a solved edge at UR)
  M* U* R LSE R'
elif (FR oriented)
  EOFR L6EP
else
  EO+forceULUR/UFUB opposite FR L6EP
end

A 17 move L7E is definitely possible, as is a 17 move L8E. Now I know I've posted a lot of CPRoux garbage today, but I just thought of this one and it has to be one of the best methods ever proposed:

1. CPFB (minimum 9 moves, hopefully @Arc can update us how to do this most efficiently)
2. SB-DFR corner (probably around 9 moves as well, maybe 10)
3. EODFDB (8 moves)
4. Solve the rest in one alg (~200 algs? I have no idea. I actually think the recog for this step would be pretty good. ~10 moves, 2 gen too)

This has a lot going for it, it's ergonomic, pseudo 2-gen after the first step, rotationless, sub-38 moves and probably less than 250 algs. I would like some opinions before I work on this, but I think this has SERIOUS potential and is maybe the best method ever proposed.

EDIT: Looking back on this, I kinda think I might scrap Bope to work on this. I have no doubt in my mind that this'll be my main method. Should this just be called CPRoux or should we maybe make a more creative name?

 

[Teoidus]

Approximate movecount: 9 CPFB + 9 SB-DFR + 8 EODFDB + 15 remainder = 41

 

[Thermex]

Approximate movecount: 9 CPFB + 9 SB-DFR + 8 EODFDB + 15 remainder = 41

15 moves for 1 alg?? I kinda doubt that, but you are the expert on 2GLL. You should run some tests on it (I don't have HARCS).

 

[Teoidus]

A 17 move L7E is definitely possible, as is a 17 move L8E.

Crafto's L7E method is the only one that even approaches 17 moves and I think it was closer to 18.

thinking.gif

 

[Teoidus]

15 moves for 1 alg?? I kinda doubt that, but you are the expert on 2GLL. You should run some tests on it (I don't have HARCS).

Maybe @Arc will run it or something, but I wouldn't be surprised.

 

[Thermex]

Maybe @Arc will run it or something, but I wouldn't be surprised.

I gotta practice piano right now, but later I'll gen some sample algs to get an idea of the movecount. Even if it 15 moves, a 41 move total is still really good for ~250 algs.

 

[Arc]

15 moves for 1 alg?? I kinda doubt that, but you are the expert on 2GLL. You should run some tests on it (I don't have HARCS).

2GLL is 13.15 HTM for optimal <R,U> algs.

Here is the analysis on your method. Note that these are optimal numbers. In a human speed solve, CPFB will likely be closer to 9, SB- will probably be around 9-10, EODFDB I'd say is closer to 9, and 15 for 2GLL+DFR since that is just algs, totaling at around 43, which is pretty good. Overall I wasn't expecting this to be this low. I don't have the beta version of HARCS that can give you the alg count for a step and I don't want to do that by hand.

Unrelated, here are some stats for Briggs:

And here is the HARCS run leaving out DFR and solving it with 2GLL:

 

[Thermex]

2GLL is 13.15 HTM for optimal <R,U> algs.

Here is the analysis on your method. Note that these are optimal numbers. In a human speed solve, CPFB will likely be closer to 9, SB- will probably be around 9-10, EODFDB I'd say is closer to 9, and 15 for 2GLL+DFR since that is just algs, totaling at around 43, which is pretty good. Overall I wasn't expecting this to be this low. I don't have the beta version of HARCS that can give you the alg count for a step and I don't want to do that by hand.

Okay, so the movecounts are a bit higher than I expected, but still potentially sub-40. I would use these movecounts and time splits for someone who maybe is about as fast as Feliks is with CFOP:

1. CPFB (9 moves that are planned out in inspection, ~1 second)
2. Square on BR+FR edge (9 moves, maybe 2 seconds)
3. EODFDB (really more like 8 moves since optimal solutions are probably the fastest when you're doing <MU> turning, about another second)
4. 2GLS (I actually would be willing to make some 3-gen algs for this step of they're a faster/more ergonomic than the 2-gen ones, so probably more like 12-13 moves. Algs could probably be recognized and preformed in around 1.5 seconds. @Arc are you able to test this step without it being 2 gen? That would be helpful)

With these splits, the method is about 40 moves and could be done in sub 6 seconds on average by someone who's mastered it. It's also rotationless and only about 250 algs, which are huge plusses. I think I'll go ahead and make the 2GLSLL algs in the upcoming week or so. Tomorrow I'll probably do a megapost on this method with proposed names, tricks, Alg samples and more.