Low algorithm counted LS method

[J-B]

Hello everyone, i have tried to develop a new LS method for 3x3 Rubik cubes. The method is a Mehta-APB variant, that has an extremely lower algorithms count than the traditional LS methods like ZB or APB and so going.
The method starts like in APB, so with a block on the left.
The steps in order are:
1)Create a 2x2x3 block on the left side, exactly like in APB
2)Insert the dBR pair and the FR edge
3)EO, using the semplified Mehta algorithms (11)
4)LXS while doing CP (The number of algorithms needed is 68, because inserting the FR edge you will need just 17 standard algorithms, and there are 4 possible corners patterns, so there are only 68 algorithms for LXS+CP)
5)Concluding the LL using 2GLL (85 algorithms)

Algorithms count: 164, that is way less than ZB, Mehta or APB method
Estimated movecount: 42-48 moves.
I am still developing the LXS+CP algorithms
Thank you for reading

 

[iguana]

Hello everyone, i have tried to develop a new LS method for 3x3 Rubik cubes. The method is a Mehta-APB variant, that has an extremely lower algorithms count than the traditional LS methods like ZB or APB and so going.
The method starts like in APB, so with a block on the left.
The steps in order are:
1)Create a 2x2x3 block on the left side, exactly like in APB
2)Insert the dBR pair and the FR edge
3)EO, using the semplified Mehta algorithms (11)
4)LXS while doing CP (The number of algorithms needed is 68, because inserting the FR edge you will need just 17 standard algorithms, and there are 4 possible corners patterns, so there are only 68 algorithms for LXS+CP)
5)Concluding the LL using 2GLL (85 algorithms)

Algorithms count: 164, that is way less than ZB, Mehta or APB method
Estimated movecount: 42-48 moves.
I am still developing the LXS+CP algorithms
Thank you for reading

This is a very interesting method!
(I hate to be the annoying person who points this out, but there is a method development thread)

 

[J-B]

Oh, sorry

 

[iguana]

Oh, sorry

That's okay! This honestly happens quite a lot, and you're new here, so it doesn't matter too much.

 

[That0newe1rdo]

Hello everyone, i have tried to develop a new LS method for 3x3 Rubik cubes. The method is a Mehta-APB variant, that has an extremely lower algorithms count than the traditional LS methods like ZB or APB and so going.
The method starts like in APB, so with a block on the left.
The steps in order are:
1)Create a 2x2x3 block on the left side, exactly like in APB
2)Insert the dBR pair and the FR edge
3)EO, using the semplified Mehta algorithms (11)

Solving DR rather then FR means there are only 6 algs I think, but then its just APB.

4)LXS while doing CP (The number of algorithms needed is 68, because inserting the FR edge you will need just 17 standard algorithms, and there are 4 possible corners patterns, so there are only 68 algorithms for LXS+CP)
5)Concluding the LL using 2GLL (85 algorithms)

Algorithms count: 164, that is way less than ZB, Mehta or APB method
Estimated movecount: 42-48 moves.
I am still developing the LXS+CP algorithms
Thank you for reading

Btw, LXS + CP may not be 68 algs since there are 5 corners left to permute, no ?

 

[J-B]

Yes, you are right about the EO, but there are 17 LXS cases, and during LXS one corner is the dfr, that is gonna be positioned during the alg, but its always on top of FR edge, so I think the remaining corners are four

 

[That0newe1rdo]

Oh yeah if the DFR corner is always on top of FR edge, there will be less cases, but would require more pausing no ?
There would also be cases where DFR is already permuted correctly too, no ? It would be very inefficient to force it on top of FR in that scenario

 

[J-B]

I watched the LXS Google sheets and I found 17 cases where the FR edge is already at place, for four corners to permute it's 68. (There are counted also the situations where the dfr corner is also at place I think