• 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.
Cool, very cool... Except CP :(
Maybe combine this with my idea and solve CP in beginning? Just an idea.

If you can find a way to 2-gen blockbuild efficiently in a way that doesn't affect CP, that would be a damn good method--recog would be ridiculously easy and without recog issues I think 2GR is certainly competitive.

That being said I'm looking into recog now and I'm convinced it's not as big an issue as it looks--there's no need to setup to L5C recog like in ZZPorky and others and it works the same way that any CLL recog does (detect orientation subset, then look for patterns).
 
Is there any direct last layer solutions for 4x4?

I used an intuitive system to solve the puzzle, but I'm stuck with a last layer. No, it isn't parity, but an actual last layer without any reduction steps.
 
Something Shiv3r and I thought of...

After a 2x2x3 Block + EO are solved, you then solve the rest of F2L, except the the FR Edge.
Then you use an algorithm to solve Corner Permutation and that F2L Edge simultaneously.

The algorithms are pretty good, averaging 8.167 Moves with only 6 algorithms, a couple are just inverses of each other and are the standard EO preserving algorithms.

This is something that can be easily learned, and used for when the F2L Case comes up as you just need to know standard CxLL Recognition, as the FDR Corner is already solved.

Algorithms

Neat idea. How many moves does it save compared to standard Petrus/ZZ?
 
Is there any direct last layer solutions for 4x4?

I used an intuitive system to solve the puzzle, but I'm stuck with a last layer. No, it isn't parity, but an actual last layer without any reduction steps.

Roux4 in my sig

Alternatively, K4 last layer. snk.digibase.ca/k4/7.htm
 
Is there any direct last layer solutions for 4x4?

I used an intuitive system to solve the puzzle, but I'm stuck with a last layer. No, it isn't parity, but an actual last layer without any reduction steps.
I think there was a method that solves the Corners with CxLL, and then the rest with just Commutators for the rest of the Last Layer like in BLD.

Edit: K4 Method
 
Last edited:
Neat idea. How many moves does it save compared to standard Petrus/ZZ?
Hm...
So this method is pretty much a Last Slot Subset, so in relative movecount...

I believe Last Slot is around 6.25 Moves on average (Adding 0.25 for AUF), add 8 Moves for OCLL, and 12 for PLL (0.25 for AUF), making Petrus/ZZ Last Slot + Last Layer around 26.5 Moves with standard OCLL/PLL.

With this variant, Inserting One F2L Corner averages 4.5 Moves (0.25 AUF), then the Edge and CP at 8 Moves, and finishing with 2GLL at around 13.25 (0.25 AUF), making the Subset average Movecount around 25.75 Moves.

Although, this I think should be mainly used when the Corner is in the slot already and not the Edge, so 4.5 Moves are saved.
 
CP taking 40k Algs?? Uh, then maybe we can find a way to do it intuitively...
Yes, I am a fan of Briggs2. The difference with mine is that it is solved first step so you don't have to slow down, and if you are only turning LU or RU or maybe even FU at a time TPS will probably be pretty high...
With either Briggs or B2 you do solve CP in the first block with Roux FB or 2x2x3

Oh, and just my two cents on mehod creation (for speed and lookahead)
1) build blocks which don't have to be broken and then restored during parts of the solve: if you do this you may be better off doing pseudoblocks (SSC is an example of this as you only break what you have already created in the very last step. Roux is also a good example)
2) intuition is your friend. If you can find a way to do something intuitively that is a comparable movecount I would suggest you go for that (another good example of this is Roux LSE)
3) if you use algs, make sure they do two things: solve a fairly large section of the cube and have very good recognition. Also try to develop some system for predicting such as ROLL
4) don't have too many little steps as lots and lots with impede lookahead especially if they are alg based.
5) equally, don't have too few (though this is harder to do). 4-5 major steps should be good.
6) if you include something fancy like EO or CP try to put it at the start or at least find a way to help lookahead.
7) there are maybe 6 key things of which every method should have 3 or 4 somewhere (though they met be done in a slightly different way): EO, EP, CP, CO, Blockbuilding and Algs. (unless you have a really, really revolutionary method).
 
Last edited:
CP recognition @ L5C as promised from earlier: here.

Just like COLL or CMLL recog: AUF to identify orientation subset, identify 3 relevant stickers, disambiguate with pretty simple patterns.
 
I know it isn't talked about, but what about a corners first method for clock? It's my second favorite event being 3x3, and I was dabbling with this idea:

It's still an idea, but maybe it will work:

Solve corners while Simultaneously solving the center clocks.

Orient Edges (just get all the edges and center clock to face the same direction with one alg)

Permute Edges (get all the oriented edges to Face Noon with one alg)

This would take a rather high amount of algorithms, but I haven't seen any real speed clock methods out there.
That seems really inefficient. Also, if you're talking about algs for clock, you probably don't have a good understanding of how clock works. The current method solves the clock with at most 14 cog turns, which is optimal (for fixed pin order). The turns on clock commute, which means that you can do them in any order relative to each other, and since there are 14 clock faces you need 14 different moves to solve it (so says linear algebra).

Since you can't move individual edge clocks in one move without affecting corners, you need to do more twists than necessary and so it's worse than the usual solving method.
 
CP recognition @ L5C as promised from earlier: here.

Just like COLL or CMLL recog: AUF to identify orientation subset, identify 3 relevant stickers, disambiguate with pretty simple patterns.
Nice, have you made Algs yet? I may invest a bit of time into this.
Also, for the recog doc, what is the orientation of the cube?
 
Main doc here (links to algs and how to recog in there as well).

I post example solves every day on reddit, hopefully they will clear up your other questions
 
With either Briggs or B2 you do solve CP in the first block with Roux FB or 2x2x3

Oh, and just my two cents on mehod creation (for speed and lookahead)
1) build blocks which don't have to be broken and then restored during parts of the solve: if you do this you may be better off doing pseudoblocks (SSC is an example of this as you only break what you have already created in the very last step. Roux is also a good example)
2) intuition is your friend. If you can find a way to do something intuitively that is a comparable movecount I would suggest you go for that (another good example of this is Roux LSE)
3) if you use algs, make sure they do two things: solve a fairly large section of the cube and have very good recognition. Also try to develop some system for predicting such as ROLL
4) don't have too many little steps as lots and lots with impede lookahead especially if they are alg based.
5) equally, don't have too few (though this is harder to do). 4-5 major steps should be good.
6) if you include something fancy like EO or CP try to put it at the start or at least find a way to help lookahead.
7) there are maybe 6 key things of which every method should have 3 or 4 somewhere (though they met be done in a slightly different way): EO, EP, CP, CO, Blockbuilding and Algs. (unless you have a really, really revolutionary method).
briggs recognition is a little terrible: if anyone has a solution, then please share it.
 
So, if you guys are at all familiar with me by now you will know that I often propose strange and abstract methods/concepts here. This one is no exception, and I think it's by far my best. I kinda wanna keep this post short because I'm learning Algs currently.
1. FB, 2x2x1 in the back.
2. SB, 2x2x1 in the back on the other side.
3. Solve FR and FL
4. Roux style EO and make sure M slice is offset by an M2 for next step
5. LSSLL: Left Side Semi LL, solve the rest of the LL face and the 2 B M slice edges (which are now in front for better recog), while also resetting the M slice for next step, all in 1 alg.
6. RSSLL: Right Side Semi Last Layer, solve the rest of the R slice and the 2 F M slice edges. Cube solved.
The main strong point in the method, I believe, is recog because the first 2 steps solve most of the back part of the cube pushing everything you need to see in front. Also, no rotations (except maybe in Algs) :D.
Suggestions/criticism? This method is still a WIP which is why it's not too great yet.
I would like an alg sheet; I would do it, I just need an alg sheet to start.
 
briggs recognition is a little terrible: if anyone has a solution, then please share it.
I don't deny it isn't very nice. I was merely pointing out that fact because the person I was quoting seemed to think otherwise.

Just to go over in brief though if anyone wants to see if they can improve it; set one corner as DBL and locate the corner that should be in DFL.
Separate the remaining corners into permutation pairs with the pieces consisting of (DFR-DBR), (UBR-UFL), (UFR-UBL)- essentially opposite colour U layer and remaining d-layer.
identify the 3-cycle that will solve the DFL corner and shift the other pieces into one of 3 patterns (XI, :I:, %- look at jaap's CP page). You can learn the 3-cycles if you wish.
 
I've found usually 2-3 moves is sufficient to place the remaining corner and reduce CP, so if a decent recognition system can be found RouxCP becomes very promising

I would propose something like

FB+CP

SB

EO+DFDB

2GLL
 
I've found usually 2-3 moves is sufficient to place the remaining corner and reduce CP, so if a decent recognition system can be found RouxCP becomes very promising

I would propose something like

FB+CP

SB

EO+DFDB

2GLL
Again, we can apply my idea to this...
I think we should work on a way of intuitively solving CP in beginning like EO... this would validate so many methods...
also, for your redux method, EO+CP can be performed like this for noobs:
1. CP, solve like Noah's CP blocks method 2
2. EO, similar to Roux (I have algs/cycles, its very easy) maybe while placing FD?
works great with very few algs.
 
The beginner variant i was using when testing out the method was just to use Old Pochmann algorithms to perform the requisite swap and <R,r,U> to orient things and place FD

Yes of course we can your idea is CP into free blockbuilding
What is important is how the blocks are built and how CP is reduced
 
The beginner variant i was using when testing out the method was just to use Old Pochmann algorithms to perform the requisite swap and <R,r,U> to orient things and place FD

Yes of course we can your idea is CP into free blockbuilding
What is important is how the blocks are built and how CP is reduced
after CP, blockbuilding is actually pretty nice and very high tps...
I think the best place to start with CP is finding patterns after 2 adjacent corners are permuted.
 
Back
Top