PLL's little brother: NEO-PLL

If you want to avoid no edges oriented OLL's, you can force two edges to be oriented. For the simple RU'R' case, you can do the sledgehammer isntead (R'FRF'), and for the RUR' case, you can orient all 4 edges with R U' R2 F R F' U2 R' F R F'. That's very similar to OLL 17 (17 has R U2 instead of R U'), and it orients all edges. I posted in that thread I was going to find algs to orient 2 edges (in the event you had 2 edges already oriented) so you didn't have to do the F RUR'U' F' move, and especially f RUR'U' f' back to back with no edges oriented, but for all the RU'R' cases I found it was easier on move count to just sledgehammer it (depending on the two edges already oriented) or just solve it and F/f RUR'U' f'/F'.

But some two edges oriented algs are horrid...

eg this:
3XTr

The OLL for it is awful but you could do:
y' F (U R U' R') F'
And then use NEOPLL...

It's cases like this that make it worth it.

why the hell would you do that instead of doing (R' U' R U R' U2 R)[sune] (F R U R' U' F') for OLL. I fail to see how that case is worth doing anything other than OLL/PLL.
 
This is a bad idea because it is the worst subset of KLL (ELL+CPLL) so bad in fact that when thinking of methods for KLS that Tim Sun suggested it would be smarter to double the algs to always force 2 edges at least.
 
Toad: What didn't make sense about my post? I was telling him how to avoid the dot cases. You can either A) do the sledgehammer, or for the RUR' alg do the alg I posted. And I'm still on 2LOLL but you don't really much more. If the alg I said didn't make sense, I meant a f instead of F, but you get the point. I looked up the alg for the OLL you posted, saw why you said it's not fun, and posted what I'd do in the situation if the alg was that bad for me.
 
This actually looks pretty promising. How difficult is recognition for NEO-PLL?

And I agree with Cride that since you can use the same algorithms for multiple OLL cases that the number of algorithms isn't really any more (could even be less) than just OLL --> PLL.

But if you already know your OLLs then I guess you'd just end up forgetting some of them.

EDIT: I don't think I'd bother learning it but it might be good for someone who doesn't already know all their OLLs.
 
I still reckon this is a great idea and could save an average if used when it fits... Have you done any solves with it? How do you feel it's going?
 
It seems that this is effectively a set of 1LLL algs. Just for no edges oriented. Recognition shouldn't be too hard with all corners oriented, but without that, you would have to identify, CO EO CP. That just seems like too much to handle.
 
But with NeoPLL you only recognize EP and CP, just like PLL. The only difference is that the edges are flipped.

I have done about 30 timed solves with it (only NeoPLL, so F2L, OLL to misorient all the edges, then NeoPLL), and so far I have managed a 13.18 single and an 18.75 avg12. I now know half of the algorithms.

I have found that recognizing NeoPLL is very different to normal PLL, but not at all harder. The big difference is that where PLL allows you to use blocks to recognize, NeoPLL requires pure cycle recognition. This takes a lot of practise, but I think it can be done just as fast as normal block recognition on PLL.
 
18:14:50 <@j`ey> say yoou have sune +4flip
18:14:58 <+DanCohen> http://www.youtube.com/watch?v=cCQyaYdj6-8
18:14:58 <@j`ey> you do sune and neo
18:15:00 <+DanCohen> man i'm so good
18:15:14 <+Kirjava> j`ey: OR YOU COULD DO OLL/PLL :O
18:15:24 <@j`ey> ..
18:15:31 <+DanCohen> but sune is faster than the fRURUf'FRURURF'
18:15:34 <@j`ey> or you can do this
18:16:15 <+Kirjava> butbut
18:16:16 <+Kirjava> why
18:16:20 < pembo> tbh
18:16:21 <+Kirjava> like
18:16:23 < pembo> I'd rather just learn
18:16:24 < pembo> ELL
18:16:28 <+Kirjava> PLL are pwner
18:16:54 -!- fundash [[email protected]] has joined #rubik
18:17:07 <+Kirjava> I just don't think it's viable
18:17:08 -!- Visitor_1 [[email protected]] has quit [Quit: Visitor_1]
18:17:12 <@j`ey> well hes looking for nice cades
18:17:15 <+Kirjava> it'll never become useful
18:17:25 <+Kirjava> you need to know another set of PLL
18:17:29 <@j`ey> it might
18:17:32 <+Kirjava> which *is* going to have worse algs
18:17:35 <@j`ey> and?
18:17:35 <+Kirjava> hoeever you look at it
18:17:53 <+Kirjava> and then *think* in the solve
18:17:56 <+Kirjava> more thinking time
18:18:00 <+Kirjava> thinking time is not good
18:18:10 <@j`ey> if you can dtill do them like 1.5s
18:18:26 <+Kirjava> lol
18:18:27 <+Kirjava> no, no
18:18:30 <+Kirjava> I don't care
18:18:35 <+Kirjava> it'll never be useful
18:18:39 <+Kirjava> no one will ever use it
18:18:43 <+Kirjava> except maybe that one guy

18:22:26 <+Kirjava> I'm just skeptical of LL 'methods' that are a collection of algs that only apply in specific situations
18:22:45 <@j`ey> isnt that what algs do:p
18:23:43 <+Kirjava> no
18:23:49 <+Kirjava> OLL/PLL applies in every situation
18:23:51 <+Kirjava> as does ZBLL
18:23:54 <+Kirjava> and CLL/ELL
18:23:57 <+Kirjava> and COLL even
18:24:05 <+Kirjava> but COLL not so much
18:24:21 <+Kirjava> and only dumb people learn coll who don't use ZBF2L
 
Last edited:
There are certain cases I don't like, especially some no edges oriented OLLs. Doing for example a sune and then NEOPLL seems a lot faster then.
This post made me understand.

I'm in the same boat. I had no idea what was going on until I saw that post.

BTW: I don't really think this is a good idea. To be honest, I actually quite like that OLL case (although I always use partial edge control anyway).
 
Back
Top