Im optimizing ZZ CC++

[zzcuberman]

Hi! Im starting to develop Chris trans idea of c ++. Starting with the ttlls. Then tlse and c. Ill be compiling a list of algs for each c case to show which set would be for each case accordingly. If anyone has any generated algs for ttll that are good please post them!

 

[N's-cvt]

Good for you. I rewatched the video and it makes sense but it's not really a hybrid it's just a which method is better for this solve based on the C case which is similar to method neutrality but to do it in a solve is not good. Personally after having spent the last 3 years doing ZZ-CT I think it would be better to pick one so you don't have to get good at 2 LSLL methods just 1. Algs could be better sure but the extra practice for all 3 sets is a bit deterring. However, that's my opinion, I think if this is a set you want to optimize I'd be down with that and I have not seen many people with ZZ-C/ZZ-CT algs so for you to do that would be awesome! Tell me if you have any cases you want me to help you with, I've already done some optimizing of my own with CT over the years.

 

[zzcuberman]

Hi! Im starting to develop Chris trans idea of c ++. Starting with the ttlls. Then tlse and c. Ill be compiling a list of algs for each c case to show which set would be for each case accordingly.
[/QUOTE

Good for you. I rewatched the video and it makes sense but it's not really a hybrid it's just a which method is better for this solve based on the C case which is similar to method neutrality but to do it in a solve is not good. Personally after having spent the last 3 years doing ZZ-CT I think it would be better to pick one so you don't have to get good at 2 LSLL methods just 1. Algs could be better sure but the extra practice for all 3 sets is a bit deterring. However, that's my opinion, I think if this is a set you want to optimize I'd be down with that and I have not seen many people with ZZ-C/ZZ-CT algs so for you to do that would be awesome! Tell me if you have any cases you want me to help you with, I've already done some optimizing of my own with CT over the years.

Oh really? Id love your ttll list i use justin taylors so its prob not the best lol

anyway the list of compiled algs would basically be the zz-c cases but where tsle is less moves i would do that. Itll bring a lower movecount overall. Basically only recognizing zz-c but not really recognizing by the ct cases

 

[N's-cvt]

Yeah I'd be glad to! I didn't have any images at the time I created my latest version so use Justin's list for the images and what order they are in.

 

[TerryD]

Great! I'm looking forward to it.

 

[PapaSmurf]

This will be super useful!

 

[OreKehStrah]

I bring this up every time I see people talking about ZZCT. I really don't think the way people are doing CT rn is worth it. TSLE into TTLL in it's current state is objectively worse than OLL and PLL because the algs are worse. I really don't like when people make the argument that TTLL solves the LL in one alg so it's okay because you still have to do TSLE beforehand, so there's no real difference between doing that, and OLL then PLL, since PLL solves the LL in one alg after setup from OLL.

I think TTLL has a lot of potential in the future of CFOP and ZZ as an option select thing. TSLE is pointless imo. Instead, you can just form a pair with an F2L edge and either the correct F2L corner or one of four different last layer corners (What I call Free Slotting/Pairing) based on what is either easiest/fastest, or can influence another pair or EO/OLL case. By doing this you get more influencing opportunity, and the ability to just use normal OLL algs, meaning you only need to learn TTLL to use this option select idea. By doing this you also get a greater chance for OLL skips or to use something like winter variation to insert the "Free Pair" and get OLL. Even better, if you can get EO while making the free pair, you can use COLL to control which group of TTLL cases you can get.

The main hurdle with all this is that nobody is really making TTLL algs, and when they do, they algs tend to not be super great. I see a lot with either high movecounts or awkward overturning situations. I've tried making some algs myself, and they usually aren't just super great. I wish more people would help with the algs, because I really do think that using this idea for option select would open a lot of doors for CFOP and ZZ, and offer a new path to go down for someone going beyond the standard method besides things like small sets like WV and COLL, and mega sets like VLS and ZBLL.

That being said, I do thing it's pretty cool that you are going to do this, and I hope this project goes well for you! I think ZZ is very cool, and would love to see it worked on further!

 

[xyzzy]

I really don't like when people make the argument that TTLL solves the LL in one alg so it's okay because you still have to do TSLE beforehand, so there's no real difference between doing that, and OLL then PLL, since PLL solves the LL in one alg after setup from OLL.

The entire point of ZZ-CT is that using TSLE+TTLL cuts down last slot last layer from three looks to only two, without needing as many algs as full ZBLL. With OLL+PLL, you still have to solve the last slot beforehand!

The main hurdle with all this is that nobody is really making TTLL algs, and when they do, they algs tend to not be super great. I see a lot with either high movecounts or awkward overturning situations. I've tried making some algs myself, and they usually aren't just super great.

Thinking out loud, I'm really just wondering if TTLL algs are just "inherently" bad and you have no choice but to have either bad ergonomics or bad move count. This is already the case with a decent number of ZBLL cases, for example. After all, TTLL is functionally equivalent to one-looking a subset of LSLL cases with a very specific F2L case, and it's not even a good F2L case!

 

[zzcuberman]

Thank you for the algs! I use alot of these and a couple different ones!

we could also generate algs for the other 2 corner permutations were 2 corners are still unoriented those sets would also be 72 algs but you would have to recog C cases not the tsle cases so it would only work if you know ols. but all of this may take awhile but it could give an overall method with a very good low movecount!

 

[N's-cvt]

I think Jayden had that idea of TTLL but with 2 unoriented corners cases and I generated some of them but they were not that good algs from what came up, worse than normal TTLL for them most part. But then again I only tested a few cases so maybe the majority is better IDK

 

[zzcuberman]

that is what he was speaking of. you cant only have one misoriented so it has to be two.

 

[OreKehStrah]

The entire point of ZZ-CT is that using TSLE+TTLL cuts down last slot last layer from three looks to only two, without needing as many algs as full ZBLL. With OLL+PLL, you still have to solve the last slot beforehand!


Thinking out loud, I'm really just wondering if TTLL algs are just "inherently" bad and you have no choice but to have either bad ergonomics or bad move count. This is already the case with a decent number of ZBLL cases, for example. After all, TTLL is functionally equivalent to one-looking a subset of LSLL cases with a very specific F2L case, and it's not even a good F2L case!

The problem with the argument of it being only two look vs three look is irrelevant for a few reasons. First, you can often get a free pair of an F2L edge and some random, oriented corner from the last layer randomly from just solving other pairs. Second, at a high level where doing tricks like this might matter, most people will have decent enough look ahead that it's basically not a three look. Now that we established that a good cuber can likely mitigate the issue of three looks just by having good look ahead and luck, it comes down to speed and movecount. While I can concede that just inserting an edge without thinking is faster than making a choice on what corner to pair with an edge, the movecount difference should be incredibly marginal if any. When you consider the additional freedom you get for influencing the LL or other F2L pairs, plus not needing to learn TSLE, the benefits far outweigh the cons in my opinion.

 

[zzcuberman]

I think Jayden had that idea of TTLL but with 2 unoriented corners cases and I generated some of them but they were not that good algs from what came up, worse than normal TTLL for them most part. But then again I only tested a few cases so maybe the majority is better IDK

i gened a couple. 1 that i generated is R'D'RU2R'DR lol thats a pretty good

 

[TerryD]

Here's a pdf of ZZ-C++ algs: https://drive.google.com/file/d/0B4wnDYRRloa1Mmswb1JmZW8yV2s/view. They may not all be great, but I think there are some good algs in there. Most of the algorithms in that pdf are RUL gen, and personally, I think RUD or RU gen would be better.

 

[zzcuberman]

the standard 1 corner flip cls cases have 4 each. one from the different U positions you can put the corner in

 

[Alexander]

Yeah I'd be glad to! I didn't have any images at the time I created my latest version so use Justin's list for the images and what order they are in.

Here with images. i made a txt file from it and then generate the PDF.

Update the files a Ra alg was missing an ' and the last algs did not have a y' in the begining now al algs looks good in image's

 

[zzcuberman]

Here with images. i made a txt file from it and then generate the PDF.

cool man thanks

 

[zzcuberman]

Here's a pdf of ZZ-C++ algs: https://drive.google.com/file/d/0B4wnDYRRloa1Mmswb1JmZW8yV2s/view. They may not all be great, but I think there are some good algs in there. Most of the algorithms in that pdf are RUL gen, and personally, I think RUD or RU gen would be better.

These are just c cases and alot of these are rul. The more optimized list on tao yu trainer is mostly ru and rud