SM cubing
Member
THIS IS VERY IMPORTANT!!!!!!This is a message to everyone interested in making a method or who is about to post a method: Stop making RouxFOP
THIS IS VERY IMPORTANT!!!!!!This is a message to everyone interested in making a method or who is about to post a method: Stop making RouxFOP
A very inefficient method for big cubes (not sure if you could accurately determine average move count, but it would be very inefficient):I'd like to propose a new method challenge:
Create the worst method you can think of! I'll be really interested to see what you guys make up!
But, I do need to set some basic rules so the methods aren't infinite or impossible:
- If you end up breaking progress of previous steps you must restore it in the same step that you break it.
- No more than 12 steps are allowed(sorry about your crazy ideas w/ 100 steps).
"Score" is judged by the average (stepwise optimal) movecount.
Good luck!!
1.Orient white corners on bottom(5 moves)I'd like to propose a new method challenge:
Create the worst method you can think of! I'll be really interested to see what you guys make up!
But, I do need to set some basic rules so the methods aren't infinite or impossible:
- If you end up breaking progress of previous steps you must restore it in the same step that you break it.
- Maximum of 12 steps are allowed(sorry about your crazy ideas w/ 100 steps).
"Score" is judged by the average (stepwise optimal) movecount.
Good luck!!
oh I just realized this section is deadIm not sure if this has been said here before (i don't feel like going through 200+ pages) But I propose something for those solves where it is much easier to keep a cross edge flipped than it is to orient it.
So this will be a set of algs that orient the last layer, but also fix the cross edge. Cross edge is by default held in front, but by doing D moves can set up the cube into the right position to do the alg.
I'm sorry if this has been proposed already, but I really like this idea, as I think it has less algs than full oll. But, I haven't done the math(s) to see. And I can see some potential in it, as long as all the algs aren't terrible. I have two algs, but those are probably the best ones. One of them is a seven move M U alg, and the other is just a setup to F sexy F'. I'm thinking many algs will be just setup into an oll.
I like it but I am never going to learn it bc I hate algsThis is a serious idea that uses aspects of M-CELL and Zipper. I've called it Z-CELL (Zipper-CELL) temporarily, but that's not for certain at all.
1x2x3 block on the left, exactly the same as Roux. Average movecount of 7 and definitely speedsolving viable.A 1x2x2 at RDB, just like Roux SB but only the back square. Average movecount of 6.8 which is imo achieveable, but if not, low 7s is definitely in human expectations.Solve DFDB and also all the centres. 5.6 average movecount and very easy to do optimally.You solve the last 5 corners. Unfortunately there's an alg count of 614 algs, but fortunately an average movecount of about 10 (I dunno exactly because speed optimal algs don't exist. HARCS says 9.623 over 1000 solves). That is fortunate as the number of moves you have to learn is 6140. ZBLL is (14.5*493=)7148.5 moves, so technically it is less info than ZBLL. From what I can gather, recog should be fine.This is where you finish the cube. The step has an average movecount of 11.09 ATM according to Justin Taylor's algs and has an alg count of 245. Apparently all the algs are good, as is the recog.From the movecounts given (and AUFs) the method averages 7+7+5.6+10(?)+11.09+2.25=42.94. The first 3 steps are definitely speedsolving viable, as is the last one. L5C is a lot of cases to be going through at once, but again I think that it should be fine. It is also easier to lookahead from DFDB to this step than other non algorithmic to algorithmic steps as its majority slices. There are also 859 algs, but you need to memorise less info than ZB.
With this method, if you can get good at the blockbuilding first half but you also like algs, this method works well. It has a very low movecount and most likely a decent TPS. Any thoughts are welcome.
Doubt it's way more efficient.L5C with a free M-slice is way more efficient than CMLL.
I also doubt that RUMr has a higher tps than MU. Have you seen some Roux solvers lately?L7E is only slightly longer than L6E. In L7E, all you need is one of UL, UR, or FR to be random filled with an L/R edge which happens on most solves. In that case L7E is actually Waterman L6E which takes the same number of moves as Roux L6E except in most cases has higher TPS because RrUM has faster TPS than MU.
It's more like: Roux - 7.5, 10.5, 11, which is 29. And the second method you just described is Roux just with more algs. Even if you did save the 4.5 moves, it would still be as efficient as Z-CELL.For Roux you would have to solve the last FR pair, THEN do CMLL which is a bad way to solve corners because it must preserve the M-slice. For Z-CELL, you SKIP the last FR pair AND save several moves on the corners solve, and then lose maybe 1.5 moves on average on L7E, the net result is a fairly large savings and an increased use of luck as well.
Taking a wild guess
Roux last pair: 5 moves
CMLL: 11.5 moves
L6E w/EOLR: 15 moves
Total: 31.5 moves
Z-cell w/L7E approach:
Last pair: 0 moves (skip)
L5C: 10 moves
L7E: 17 moves
Total: 27 moves (saves 4.5 moves over Roux with no loss of ergonomics or lookahead)
That's harder than doing it during DFDB. Basically, you described an advanced version of Roux that has no advantage over Z-CELL. I do think that FB, SBsqr, L5C, L7E should be explored, it's just that no one has found a good way to do L7E. Not waterroux or other ideas. The best IMO is to solve EO+one U edge then do conjugated L6EP, but that still is probably bad.With Z-Cell, you would be able to look ahead to the L5C case as you are solving the back right pair, reducing recognition time.
I disagree that L6E-EOLR can be done in 11 moves on average, but even if it could, consider that in L7E, solving the FR edge directly never takes more than 7 moves. Solving FR directly then doing L6E is the dumbest and worst possible L7E method, but by that simple analysis it takes no more than 7 extra moves vs. Roux L6E-EOLR. Around 200 L5C algorithms have already been generated for 2x2 and are in active use, and they are a lot shorter than CLL/EG1 algorithms; but again even if you assumed the most skeptical possible scenario and assumed that L5C takes the same number of moves as CMLL, then as far as STM moves, the only difference between Z-cell and Roux would be that Roux takes 7.5 moves for the last pair while Z-Cell skips the last pair and solves FR in 7 moves or less; so even in the most skeptical of all possible scenarios, Z-cell takes 0.5 moves less, and in reality it would do a lot better.Doubt it's way more efficient.
I also doubt that RUMr has a higher tps than MU. Have you seen some Roux solvers lately?
It's more like: Roux - 7.5, 10.5, 11, which is 29. And the second method you just described is Roux just with more algs. Even if you did save the 4.5 moves, it would still be as efficient as Z-CELL.
That's harder than doing it during DFDB. Basically, you described an advanced version of Roux that has no advantage over Z-CELL. I do think that FB, SBsqr, L5C, L7E should be explored, it's just that no one has found a good way to do L7E. Not waterroux or other ideas. The best IMO is to solve EO+one U edge then do conjugated L6EP, but that still is probably bad.
2 things. Firstly, Z-CELL is the method described by me. What you're describing is an advanced form of Roux which would take off if L7E became viable, so call it the right thing. Secondly, please document your L7E idea properly because it could change Roux if it is good. If it isn't let's try to find a good one. Once we have (if we have to) we can then compare Z-CELL to this Roux variant. Also, thanks for the compliment!I disagree that L6E-EOLR can be done in 11 moves on average, but even if it could, consider that in L7E, solving the FR edge directly never takes more than 7 moves. Solving FR directly then doing L6E is the dumbest and worst possible L7E method, but by that simple analysis it takes no more than 7 extra moves vs. Roux L6E-EOLR. Around 200 L5C algorithms have already been generated for 2x2 and are in active use, and they are a lot shorter than CLL/EG1 algorithms; but again even if you assumed the most skeptical possible scenario and assumed that L5C takes the same number of moves as CMLL, then as far as STM moves, the only difference between Z-cell and Roux would be that Roux takes 7.5 moves for the last pair while Z-Cell skips the last pair and solves FR in 7 moves or less; so even in the most skeptical of all possible scenarios, Z-cell takes 0.5 moves less, and in reality it would do a lot better.
The best method thus far to solve L7E is just the latest unpublished LMCF method of doing it. I'd be happy to bet anyone $100 on 50 scrambles that Z-cell with L7E takes 1.5 moves or less than Roux finishing the same solve.
One of the problems of L7E is the way we use to count the moves. Roux in general frequently has cases where you do [M'R'] or [MR] or [M2R] or [M2R'] at the same time. If you count M-R combos as one move for the entirety of the Roux solve, with a fictional 'STMR' metric, then L7E suddenly looks way more appealing because L7E heavily relies upon the [M'R'] or [MR] single move.
I didn't invent Z-cell, I'm just supporting a good idea that someone has put forward which is the best idea I have seen in years.