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.
Similar threads
- Deleted member 27249
- Puzzle Theory
- Deleted member 27249
- Puzzle Video Gallery
