Cube rotations cause simultaneous moves to break

[bwong-ice]

I discovered this issue in Twizzle Alpha when inputting a 3BLD reconstruction.
U' U' R' E R U R' E' R U
(U' D') R E' R2' E R (U D)
U' L F L S' L2' S L F' L' U
(U' E') R' E R2 E' R' (U E)
r U R' U' r' R U R U' R'
L' E L U L' E' L2 E2' L' U' L E2' L'
x R' U R' D2 R U' R' D2 (R l)
R' D' R' U' R D2 R' U R D' R
R' (U D') R U' R' D R U R' U' R
(U D) R2 U' R2' U R2 D' R2' U R2 U' R2' U2'

Just lines 1-6 or 7-10 don't cause problems. However, lines 1-10 will cause simultaneous moves to break.

[lgarron]

The simultaneous move indexer is limited to algs with 100 moves:

cubing.js/src/cubing/twisty/model/props/puzzle/state/IndexerConstructorProp.ts

Line 32 in fccb7d2

experimentalCountMoves(inputs.alg.alg) < 100 &&

This is just a safeguard because the implementation is unoptimized, but I suppose we could raise it a bit higher to account for BLD solves. Do you know of any good stats for how long 3BLD reconstructions get?

[bwong-ice]

This document gives some statistics for 3BLD using 3-style (https://www.speedcubing.pl/content/3bld-statistics.pdf). Using just basic UF/UFR buffer, most solves require 10.26 basic 3-style algs. Assuming that most basic 3-style algs require 11 moves, we get an average of 112.86 moves per solve. This isn't a very good metric since we aren't considering the full distribution of solves. However, based on this rough calculation I would say raising the limit to 150 moves would be sufficient. If someone used Orozco instead, this limit would need to be nearly doubled (maybe 250 moves).

[lgarron]

Sounds like 256 moves should reasonable cover "normal" reconstructions — I'll bump it to that!

[lgarron]

Sounds like 256 moves should reasonable cover "normal" reconstructions — I'll bump it to that!

Actually, I've gone ahead and bumped it up to 1024.