• Welcome to SpeedSolving.com — the world’s largest puzzle community!

    You’re currently browsing as a guest, which means you have limited access to discussions, resources, member profiles, and community features.

    Join 50,000+ cubers and puzzle enthusiasts from around the world to ask questions, share solves, improve faster, and be part of the community.

    Registration is free, fast, and easy — create your account today.

    Already a member? Log in here to hide this message and start participating.
Just sounds like hta to me, except the last couple steps aren't intuitive. I only know of one person who has ever gotten sub20 with that, so I doubt it has any potential whatsoever. And I have solved using hta before, so I feel in somewhat qualified to make this conclusion.
 
Yes, it sounds complicated and long method, but it actually takes 45 moves to solve the complete cube (sometimes less than 40 moves), I will upload a video on youtube very soon.

Either your move count is way off, which is what I would bet on, or you're planning a method that requires learning 3x3 P2L, which is a ridiculous number of algs (483 if I did my math correctly). Even just doing OCLL on two faces at once takes 63 algorithms. That or the description you posted is just unclear.

Edit: Both of those numbers should be low (P2L by roughly a factor of 2, and OCLL by a factor of 3) due to parity issues.
 
Last edited:
This is the video I said I would upload, I explain the steps and how the method works, for all of you guys that have some doubts about my method. It's only an overview, not a tutorial ok. Here you can check that the process is not so long as it sounds. Please comment XD
https://www.youtube.com/watch?v=EWVpuCK6sc8&feature=youtu.be&hd=1

I counted 59 moves STM for what appeared to be a relatively lucky case (4 move EO, no corner parity, top CP skip, etc). Where did you get your 45-50 move average number?

Additionally, as someone who's made this mistake before: did you use Cube Explorer to generate those algs? That EP at the end looked like it was designed to be move optimal rather than being finger tricky (evidence: that z2 mid alg to reach from F2 to B2). If so, I'd recommend using ACube for better algs. That will increase your move count, but it'll make for easier execution.

How bad is the lookahead for this?
 
Last edited:
Why are half of all "new" methods just basically the belt method ? It isn't now and has never been a good idea. The point of speedsolving the cube is to solve portions of it in a way that you can use the unsolved portion to easily create more solved pieces. Petrus simply sections off the cube, limiting the kinds of moves you can make. Fridrich eases lookahead by restricting edges to the U and E layers and creates an environment where finger tricks can easily be used, roux leaves the m layer free to eliminate cube rotations, zz accomplishes the same thing a different way, but they all are mostly intuitive and take advantage of what's not solved to make some aspect of the solve easier. How does solving the E layer make solving the rest of the cube easier? Because the way I see it it restricts you to solving the rest of the cube using algs, and that doesn't seem useful to me. Let us know when you get a sub20 ao100.
 
Yeah, I used cube explorer for the final permutation of PLLs , I know my solve was more than 50 moves ; the problem was that I solved the D layer corners to minimize the final PLL cases on the double permutation. The complete method was completed just by solving the U layer corners and making a U(a) or U(b) on the U face to directly solve both faces at once. That means 2 Pll cases x 21 pll cases = 42 cases. but unfortunately I don't recognize all PLL cases, that's the reason. Thank you for your advice :)
Well, look ahead can be a good help since double OLL (ox2) is made using algs, and px2 also needs algorithms, we will need look ahead in the part of solving the parity of corners and the separation of edges to create a U(a)-(b) on the U face.

Lookahead is always helpful, but in the method you just described, it would be incredibly difficult, since at any given time, as many as 3 or 4 unsolved pieces need to be tracked because they're invisible (hidden on the bottom of the cube), at the same time as doing whatever you're doing to solve the cube. The recognition for OC2L (Orient Corners of 2 Layers) would be incredibly difficult, since at least one of the corners is always hidden, and recognizing a PLL on the bottom while at the same time recognizing an EPLL on top will be almost as tough.

Additionally, as I mentioned, that solve was rather lucky. Even with full EPLL top-PLL bottom, if you use finger tricky algs instead of stuff off cube explorer, especially if you get corner parity, I would bet that it will actually be less move efficient than CFOP, without any of lookahead benefits that lerenard explained above.

In short, like all Belt methods I've ever heard of, it's not going to become an effective speedsolving method. As lerenard said, while Belt seems like it could be really effective, it doesn't provide any real benefits, and unless you're planning to memorize several hundred algorithms, is going to waste a lot of moves.
 
It could work , mm anyway I am convinced this will never be a good method :( ... I will learn ZZ method , maybe I could reduce my time using this method. here watching some tutorials I see the F2L looks easier than CFOP F2L
It is, because no cube rotations are necessary. Also, lookahead is easier because, for example, you know that if you see a blue sticker on UB (assuming you have orange F and yellow U) and you only have one slot left on the blue side you know that's the edge you need.
 
another good thing about ZZ lookahead is that you subconsciously feel the difference between FR/BL pairs and FL/BR pairs.

also you can use open-slotting which saves moves and certainly improves cube awareness.
 
It is, because no cube rotations are necessary. Also, lookahead is easier because, for example, you know that if you see a blue sticker on UB (assuming you have orange F and yellow U) and you only have one slot left on the blue side you know that's the edge you need.

That is all true but you forgot to mention the drawbacks of ZZ compared to CFOP (in terms of lookahead):
1. In ZZ you can have edge pieces "hiding" in DL and DR positions. In CFOP you know that after cross there won't be any unsolved edges in D-layer.
2. To be a "real" ZZ solver you need to be able to track 3 pieces at once (the 2 edges and 1 corner that make 2x2x1 block) where in CFOP you only need to track 2 at a time (1 corner and 1 edge that form a pair). And obviously tracking 3 is harder than tracking just 2.

Now I think you can make fairer comparison. :) As usual both methods have something that is better than the other and something that is not as good as in the other method...
 
New Redux Variant

I have thought up a new redux variant that skips a whole step, I'm not 100% sure that it works but my idea is this

First, you solve the centres as normal

Second, you solve all the edges except the ones with a yellow sticker on them

Thirdly, you solve it like a regular 3x3, without pll, pretending that the yellow edges are solved (ask if you don't understand this, I might have to explain in more detail)

Lastly, you do one algorithm to permute all the yellow edges

Reply if you would like me to make the algorithms for the lask step
Also comment if you have any questions/need a step explained in more detail...

I really hope this works because I think it will be alot faster than regular redux and it might really have potential


Also I'd like to apologise if this has already been suggested, I looked around the forums and couldn't find it
 
Im fairly certain that the number of algs to permute the remaining edges is very large.

Maybe you could do it in 2 look, like you permute the top face and than just do pll, i think it could be interesting but i have no clue with making algorithms so i need help
 
I have thought up a new redux variant that skips a whole step

What does this even mean? It might skip what step precisely?

To me it just sounds similar to saying that by using Roux, you can skip PLL. (Well duh, you're not using a method that finishes with PLL...)

I don't understand what you're saying.
 
Back
Top