The New Method / Substep / Concept Idea Thread
- Thread starter elrog
- Start date
I tested the variant where you make the whole columns and insert the cross, then you just do eo exactly like In Roux and you finish the same. It works. For the second method I have to think a bit, because I don't know how to do eo with 8 edges ok? When I'll finish I'll send you everything
Constant Cuber
Member
This is actually a pretty good method; here's a link to a writeup with additional variants. No More PLL Method I'm not sure that it's better than straight CFOP.
But my current main method is ZZ-4c, which includes doing an pseudo EOCross and starting the solve an M2 slice away so the 4b setup is completed during the EOcross.
Didn't know it was already proposed, thanks for sharing!
Constant Cuber
Member
PS - doing EOcross at the beginning of the method (which turns the method into ZZ-4c) takes this method over the top in terms of viability, making it competitive to CFOP and ZB
Nirab_Shreatha
Member
i have created a new methord called psudo fcl please check it out and tell me any suddgestions for improvments on this methords on the comments the vid is:
Hello everyone, I just theorised a new Speedsolving method, that I call JB, that has a relatively low alg count, controlling last slot and last layer in two phases.
The method has 4 steps
1)Cross+ 1 corner.
2)Solve 3 f2l pairs.
3)Insert the last f2l edge while making eo and phasing
4)Close the solve with ZZLL
I made an approximative count of the algs and there are 44 algorithms for the last edge, and 169 algorithms for ZZLL.
I'm open to suggestions!
The method has 4 steps
1)Cross+ 1 corner.
2)Solve 3 f2l pairs.
3)Insert the last f2l edge while making eo and phasing
4)Close the solve with ZZLL
I made an approximative count of the algs and there are 44 algorithms for the last edge, and 169 algorithms for ZZLL.
I'm open to suggestions!
from what I understand, ZZLL isn’t the best ZBLL subset. I’m pretty sure it’s generally worse.
But, I love the concept, maybe you can have something like solving the edge while orienting some corners and EO or do EO + CP (though the recognition wouldn’t be nice).
This can be nice.
Oh and btw, there’s the zipper method that’s very similar.
Thank you! I was also thinking about doing last edge+EO+ orienting 2corners, it should have 198 cases, and then you will finish always with Zbll T or U
You can also do like the Zipper method, doing OLL + FR and PLL + FR.
Or, wild idea, do ZZ.
do EO with cross and one corner, then 3 pairs rotationless and nearly regripless.
Now you can solve the last edge with 6 CPFR algorithms (you’ll have to generate, they should be good) to get 2GLL or do BLE (27 algorithms) to get PLL or even CFRLL (solving the corners while ignoring FR (42 algorithms that will be better than COLL. a very nice algorithm set from my experience) to L5EP (16 algorithms, not the best since FR is a clanky edge to work with in L5EP).
Last edited:
Here's an idea I had:
maybe we can do Roux LSE with 2 looks.
the first look is what I call Shifted EOLR.
it's like standard EOLR where you solve EO and insert the LR edges to DF DB, but in this algset, you can ignore the ending position of the canters.
what do I mean?
well, let's explore what a single M move does.
to the centers on the M slice:
if they are LR edges, they are flipped (obviously). if they belong in the M slice, nothing changes in their orientation. why? because the new U center has changed and their thus their relation to the U center doesn't change even though they physically flipped.
for edges not on the M slice (UL / UR):
if they are the LR edges, nothing happens to them (obviously). if they are M slice edges, they get flipped, since the new U center has changes.
obviously, if UL and UR don't have the same kind of piece the logic still applies the same. to summarize the effects of a single M move on the edges:
on the M slice:
if LR edge - flip
if Medge - no change
on UL / UR:
if LR edge - no change
if Medge - flip.
with that logic, we can really reduce EOLR algorithms' movecount. some of the algorithms only have 1 move!
the main problem is recognition, but if you standardize the centers before LSE, as it is usually done anyway, nothing changes about that.
we can end it here, call it a day.
we just do DFDB recognition, insert the LR edges and finish with 4c (though the centers might be off by an M or an M' move. it doesn't add any moves).
from my research, Shifted EOLR has the same amount of cases as regular EOLR, since the edge flip technically doesn't care about the centerers as long as you follow the rules for orientation for each M move.
but, I have thought about taking it a step further. I'm pretty sure it's not worth it, but still:
what about finishing the rest with one algorithm? that way you can guarantee you get the best solution, never having a bad dots case ever.
so, I generated the algorithms using Trangium's Batch solver (sorry if I'm writing it wrong).
they are pretty good, but most of them are just "insert LR, do 4c". this proves that this algorithm set is not super good, but it can still save a couple of moves.
just like DFDB recognition is enough for 4c, you just need to know the color of F sticker in FR (L or R), the recognize using the UF edge and the shape of the U layer edges (which only requires 1 extra sticker, the one that UF has on U). and the centers. that's just 5 sticker recognition, 6 if you want to always look at UF and UR.
now, while I love the idea, it has some drawbacks:
1. Shifted EOLR can be confusing and have hard recognition, making it a tool requiring high skill.
2. EOLR isn't really an algorithm set, it's a mindset to adopt and use intuitively usually. it can be done algorithmically (108 algorithms or 128 cases, not too sure), though. Shifted EOLR can be done intuitively with the M slice logic I described, but it's very, very hard.
3. The algset to solve the cube after Shifted EOLR is generated, but it might have too much cases that I haven't reduced properly. also, most of them are just insertion to 4c, making it not super worth it to learn.
still, Shifted EOLR -> RL6EP (reduced last 6 edges permutation) is, mathematically, at most the same amount of moves as standard EOLR -> 4c, and it usually requires less moves. If you look at it from an algorithmic standpoint, the same applies, since every EOLR algorithms can be a Shifted EOLR algorithm, while not every Shifted EOLR algorithm can be an EOLR algorithm, and the same goes for RL6EP and insertion->4c.
so, please do tell me your thoughts. I'm aware this isn't much of a friendly, beginner method, but I think it can have a lot of potential.
I'll be attaching the files with algorithms and others (one of them is an index.html file, so just click on it and it will open up. please don't trust random code you see on the internet before inspecting it with a file checker and all the other safety precautions), so you may see them yourselves.
please do ask me anything and share your thoughts.
maybe we can do Roux LSE with 2 looks.
the first look is what I call Shifted EOLR.
it's like standard EOLR where you solve EO and insert the LR edges to DF DB, but in this algset, you can ignore the ending position of the canters.
what do I mean?
well, let's explore what a single M move does.
to the centers on the M slice:
if they are LR edges, they are flipped (obviously). if they belong in the M slice, nothing changes in their orientation. why? because the new U center has changed and their thus their relation to the U center doesn't change even though they physically flipped.
for edges not on the M slice (UL / UR):
if they are the LR edges, nothing happens to them (obviously). if they are M slice edges, they get flipped, since the new U center has changes.
obviously, if UL and UR don't have the same kind of piece the logic still applies the same. to summarize the effects of a single M move on the edges:
on the M slice:
if LR edge - flip
if Medge - no change
on UL / UR:
if LR edge - no change
if Medge - flip.
with that logic, we can really reduce EOLR algorithms' movecount. some of the algorithms only have 1 move!
the main problem is recognition, but if you standardize the centers before LSE, as it is usually done anyway, nothing changes about that.
we can end it here, call it a day.
we just do DFDB recognition, insert the LR edges and finish with 4c (though the centers might be off by an M or an M' move. it doesn't add any moves).
from my research, Shifted EOLR has the same amount of cases as regular EOLR, since the edge flip technically doesn't care about the centerers as long as you follow the rules for orientation for each M move.
but, I have thought about taking it a step further. I'm pretty sure it's not worth it, but still:
what about finishing the rest with one algorithm? that way you can guarantee you get the best solution, never having a bad dots case ever.
so, I generated the algorithms using Trangium's Batch solver (sorry if I'm writing it wrong).
they are pretty good, but most of them are just "insert LR, do 4c". this proves that this algorithm set is not super good, but it can still save a couple of moves.
just like DFDB recognition is enough for 4c, you just need to know the color of F sticker in FR (L or R), the recognize using the UF edge and the shape of the U layer edges (which only requires 1 extra sticker, the one that UF has on U). and the centers. that's just 5 sticker recognition, 6 if you want to always look at UF and UR.
now, while I love the idea, it has some drawbacks:
1. Shifted EOLR can be confusing and have hard recognition, making it a tool requiring high skill.
2. EOLR isn't really an algorithm set, it's a mindset to adopt and use intuitively usually. it can be done algorithmically (108 algorithms or 128 cases, not too sure), though. Shifted EOLR can be done intuitively with the M slice logic I described, but it's very, very hard.
3. The algset to solve the cube after Shifted EOLR is generated, but it might have too much cases that I haven't reduced properly. also, most of them are just insertion to 4c, making it not super worth it to learn.
still, Shifted EOLR -> RL6EP (reduced last 6 edges permutation) is, mathematically, at most the same amount of moves as standard EOLR -> 4c, and it usually requires less moves. If you look at it from an algorithmic standpoint, the same applies, since every EOLR algorithms can be a Shifted EOLR algorithm, while not every Shifted EOLR algorithm can be an EOLR algorithm, and the same goes for RL6EP and insertion->4c.
so, please do tell me your thoughts. I'm aware this isn't much of a friendly, beginner method, but I think it can have a lot of potential.
I'll be attaching the files with algorithms and others (one of them is an index.html file, so just click on it and it will open up. please don't trust random code you see on the internet before inspecting it with a file checker and all the other safety precautions), so you may see them yourselves.
please do ask me anything and share your thoughts.
I don't know, planning everything is very hard, and you cannot do them separately because movecount will grow a lot. I prefer stayin in my original idea, of making something similar to zb but inserting a corner more. For your method I am not an expert of roux, but I know one, I will ask him.
Yo, thank you for your response!
I was interested in what you suggested, it seemed interesting, so I generated some (most) of the relevant algorithms. I made your EOFRP (EO FR Phasing) idea, ZOLL (OLL on both FR and LL), ZPLL (permuting FR and LL).
for ZZZipper (the ZZ variant I suggested. it has less algorithms so I generated more algsets for it), I generated:
CFRLL (Corners ignoring FR of last layer)
FR L5EP (FR + LL Last 5 Edges Permutation)
CPFR (CP + FR)
BLE (FR + OLL in ZZ)
I hope this helps you develop it!
Thank you so much!
you welcome!
if you need anything feel free to ask me and if I can help, I will.
also, a little note on the algorithms:
they are all generated to be MCC optimized, so they should be rather fast, but I forced the generator to use specific movesets for the generation.
that means there might be better solutions for the cases which I haven't found, so please keep an open mind and don't take everything at face value. check the algorithms yourself and generate them if you think they are not good enough.
Powstick
Regular
How should I develop my own algorithms for a method? I think i’m too inexperienced but it would be good to know if there’s a good method to it
Oh there totally is a method for it!
I'll link the site here, it's great, then I'll write some instructions for how to use it:
Trangium's Batch Solver
okay, this site is amazing for generating algorithms and it has some amazing features:
1. it generates more than one algorithm per case and sorts them according to what it thinks is best. you can tell it with what metric to write. the default is MCC which is a system designed to track where the fingers are and what you can do to rank algorithms. I recommend using MCC as the main sorting and SQTM for the secondary metric (the default is none), since it also gives you a nice perspective. you can check out MCC for algorithms here: Trangium's MCC calculator
2. it auto generates the images for the cases for you, so you don't have to work as hard, and you can simply click "export" after you finish generating all of the cases and save it as an excel file. you can choose masks for the images, meaning you get to tell the software what each sticker should look like (use single letters like w for white, d for dark and s for silver. you write it in the mask section for the images. mess around with it, it allows you to control each individual sticker. it's quite intuitive). you can also choose how the image looks like (from the top, from the sides, a 4x4 and what not).
3. it allows you to generate for more puzzles than just 3x3, and even better, since it's so general, you can even define your own puzzles!
4. it generates a bunch of algorithms in one go, which is nice.
okay now for the tutorial:
there's the Puzzle section (default is 3x3) where you can see all the moves it supports and you can change it to custom to add your own moves. I used it to make a trigger based TSLE alg sheet.
Unique Orientations & Equivalences: this tells the solver what is considered solved. it took me a while to understand, but it's rather simple.
everything not mentioned there will be solved regularly.
if you put pieces in curly braces (no commas), you tell the solver that their positions are interchangeable, meaning, it ignores their orientation. for example, if you wish to generate OLLs, you don't care about the permutation of the LL. meaning, you'll write there: {UBL UBR UFL UFR} {UF UB UL UR} (notice that the edges only need 2 letters and the corners need 3. also notice how I separated the corners and edges. if you don't do that, an error will happen and it won't generate anything).
there's another, "1:". the symbol "1:" tells you to ignore the orientation of the pieces mentioned. for example, if you are generating EOFRB algorithms (like I did for JB), you don't care about CO. that means I'll put all of the corners after the "1:", like this - 1: UBL UBR UFL UFR. but, since I also don't care about CP, I can also use curly braces, writing 1: {UBL UBR UFL UFR}.
examples:
PLL - leave empty
OLL - {UBL UBR UFL UFR} {UF UB UL UR}
EOFRB - {UL UR} 1: {UBL UBR UFL UFR} (since I want to do phasing, UF and UB must be opposite to each other, meaning I care about their permutation)
ZOLL - {UBL UBR UFL UFR} {UF UB UL UR FR}
BLE - {{UF UB UL UR}}
there's a lot more examples I can give, but I think this is general enough to get the idea.
now, you get to choose how it'll try to solve the cube:
Prune - decides how many moves deep (or how many positions, but I haven't messed with this yet) from a solved state the solver pre generates before doing anything for faster times. more Prune -> longer time to start generating, faster generation per case after the first, more memory consumption (meaning your pc will hate you if you put a prune too high. I have a pretty strong pc and I use around 8, but generally speaking I recommend 6 or 7 (please don't make that joke).
Search - this is how many moves from the scrambled state the solver does to reach a state in the states generated by the prune. more search -> longer time per case. it doesn't require much more memory, but it can consume a lot of time.
Subgroup - the moves you allow the solver to use to solve. for example, for OLL you can have one subgroup of R U r M and another of R U D and another of R U F. yes, you can have multiple (press the '+' button).
for each subgroup you can define it's own prune and search.
the maximum amount of moves an algorithm can have is Prune + Search = total moves (a move can be a trigger if defined as a move in the custom puzzle).
that means, for algorithms of maximum 16 moves, you'll probably want Prune = 8 and Search = 8 or Prune = 7 and Search = 9. the algorithm will only use moves from the subgroup it currently generates with, so you cannot have R U D F algorithms if one subgroup is R U D and another is R U F.
now, for the Scramble tab.
ironically, the easiest way to use it (just writing the scrambles you want to solve there, separated by a comma) is something I don't ever use.
that is because I prefer to use generators.
generators simply tell it to "define each case reachable with any combination of the generators as a scramble to solve". don't worry, it can detect multiples and remove them, insuring you'll almost always (there might be bugs? I haven't tested it all) get the minimum amount of algorithms needed.
generators are written like this: <sequence 1, sequence 2, sequence 3, ...>. you can also write moves before the generators or after and it will add them to all the scrambles.
for example, when generating BLE algorithms, you want to be able to get all of the CO options and have FR out, so you'll write:
<R U R' U R U2 R', U> R' U' R' U' R U R U R
and bam! all of the 27 BLE cases will jump out, since you generated all of the possible CO LL combinations and just got the FR edge to the top layer.
useful sequences I keep in mind:
<R U R' U R U2 R', U> - generates every possible LL CO.
<R U R D R' U' R D' R2, U> - generates every possible L4C scramble (so CO and CP but doesn't effect EP).
<R U R' U' R' F R2 U' R' U' R U R' F', U, M2 U M U2 M' U M2> - generates every possible LL permutation
<U, M2 U M U2 M' U M2> - generates every possible LL edges permutation
some useful triggers:
R' U' R' U' R U R U R - inserts the edge on UL to FR and gets the FR edge to UR. doesn't effect CP or CO or EO.
S R2 S' R2 - does a 3 cycle on the DR UR and UL edges, preserving CP, CO and EO. useful to get DR out of DR.
R2 U2 R2 U' R2 U' R2 - inserts UBL to DFR and gets DFR to UFR. technically preserves CP since the cube is in the same R U orbit, preserves CO and EO.
Pre-Adjust and Post-Adjust: by default, its U, so you get free pre and post AUF. you can also add D for ADF and more, as much as you want for each (be careful though, it can be problematic if done incorrectly).
I haven't tested it yet, but if you define Post-Adjust to R U you can have algorithms that put the corners into an R U orbit without actually having it solve them. the Unique Orientations & Equivalences would look like this: 1: DBR DFR UFR UFL UBL UBR {UB UR UF UL FR BR DR}. anyway, this is a nice idea if you're into 2gen reduction.
case sorting - you can have the solver sort the cases by qualities, like permutations or orientations of certain pieces or permutations or orientations on certain places on the cube. very useful for clean and readable algsheets. again, you can have it sort by multiple parameters. if you have a few pieces of the same type where you check the same quality for them and none of them is more important then the rest, you can simply put them together. (do that by clicking Set priority and then writing the pieces at the text box).
okay, then there's the Options part which I recommend you to not touch, besides changing the "show top x solutions for each case" and "show ending adjustments". here you can also change the metric which it sorts algorithms by (default : MCC. recommended by me: MCC) and the secondary metric (default : None. recommended by me : SQTM).
in the image options you can choose what kind of image (3x3, 2x2, 3x3 top and so on) will be displayed, from what angle, and how large the picture will (the default 150 is pretty good, same for the X and Y rotations).
here you can also do the masking I described earlier.
you may check the Show preview box to make sure your masking and everything else is on point (it'll show you how a solved cube looks like with your settings).
then, after everything is said and done, click start search and it will start generating. in the statistics you can see things such as how fast it is generating, how many cases it generated out of how many cases there are overall, average MCC scores, average STM score, average SQTM score and average ESQ score (not sure what ESQ is).
then, you click export output to save it as an excel file on you pc and you can press "clear output" to clear the output of the software, deleting all of the algorithms you generated and haven't saved on your pc. when generating multiple algsets, please do press that button after each one is saved.
and that's it! you can now generate as many algorithms as you want and be pretty sure they'll also be fast and organized for you!
you can ask me any questions you might have and really just mess around with it, things will happen.
last important note: this software hasn't been written by me. it was written by Trangium who's a genius and deserves a lot of respect and love for this contributions. in my opinion, besides a custom IDA* search with custom or downloaded MCC scoring (yeah, scary Computer Science big words that make me sound smart even if I don't know anything... scaryyyyyyy nah jk these really are useful), it doesn't get much better than this!
hope you have an amazing time generating algorithms, inventing methods and cubing, and you may ask me anything you might need and talk about your ideas if you have them.
What about applying a Makisumi Garron last slot philosophy to a roux-cfop hybrid?
I was thinking like doing the first two blocks, then insert db Edge while doing eo, then insert df edge while doing corner orientation, and close with pll. It should have something like 55 algs for eodb, 35 for codf and 21 plls
I was thinking like doing the first two blocks, then insert db Edge while doing eo, then insert df edge while doing corner orientation, and close with pll. It should have something like 55 algs for eodb, 35 for codf and 21 plls
You forgot to do EO beforehand.
if you want to develop this, you have 2 options:
You can either do cross - 1 (kociamba or something like that). That lets you use the M slice for F2L also it’s efficient and rotationless. Alternatively, you can just do Nautilus.
As for the finish, there are 3 options, all of them completely generated for you if I’m not mistaken (maybe EODF beeds to be generated, but it’s easy enough to generate since it’s a tiny and intuitive algset).
A (my favourite): do NCLL (Nautilus CLL. It’s like CMLL but it preserves DB. 42 good algorithms), they do L5E (they are not oriented so this has a lot of algs. They already have been generated by Atherfre so you’re covered, and this is a pretty nice algset).
B (Hawain Kociamba or something like that):
OLL + DF (orient the LL and the edge on DF. Same amount of algorithms as the ZOLLs I have already generated. Can’t remember the exact number) then PLL + DF (72 algorithms).
C (most similar to your idea):
EODF (if not generated already, this has a tiny amount of algorithms so you can generate it yourself easily) - insert DF while doing EO.
Then ZBLL (or OCLL -> PLL).
i didn't understandt much your ideas, but mine was doing the first two roux blocks, then, instead of CMLL and LSE, you could insert the two bottom pieces, while influencing the last layer, ready for pll, i don't know if i explained myself
