greentgoatgal
Veteran
Is there such a thing as kilo oll and pll?
[Help Thread] Kilominx Discussion and Help
- Thread starter Skullush
- Start date
Pyjam
Premium Member
The FanXin Kilominx is stickerless and has colored center caps.
Unfortunately, the two blues are too close, same for the greens. They are difficult to distinguish.
On the top, are two different blues. Same on the left. On the top, are two differents greens, not three:
Finally, this puzzle has too much lock-up. Removing the center caps helps to solve this issue.
Here's how I pimped my kilominx:
Unfortunately, the two blues are too close, same for the greens. They are difficult to distinguish.
On the top, are two different blues. Same on the left. On the top, are two differents greens, not three:
Finally, this puzzle has too much lock-up. Removing the center caps helps to solve this issue.
Here's how I pimped my kilominx:
VIBE_ZT
Regular
Hi, I am new to this thread. I joined because I have an interest in trying to magnetize a Kilominx, but I am unsure if it is a viable idea. I decided that I would be able to reach a larger group of cubers via this website.
I am planning on using a Shengshou Kilominx, and I think the best option is to do a corner-edge scheme. I think it will be rather difficult though to get the magnets into the edges. I was unable to find any post or video about someone trying to magnetize a Kilominx, so I am assuming that it either hasn't been thought of or attempted yet, or that it is impossible.
Any thoughts? Tips? Ideas?
I am planning on using a Shengshou Kilominx, and I think the best option is to do a corner-edge scheme. I think it will be rather difficult though to get the magnets into the edges. I was unable to find any post or video about someone trying to magnetize a Kilominx, so I am assuming that it either hasn't been thought of or attempted yet, or that it is impossible.
Any thoughts? Tips? Ideas?
(partially not useless bump)
New "release" of the kilominx random-state scrambler.
(don't want to go to the trouble of saving the file first? here's a hosted version)
Key features:
(i) Now uses Fisher-Yates shuffling instead of… whatever the heck I was doing before! (What this means: it's truly random-state now, as opposed to being very slightly biased. At least, insofar as you can assume the web browser's RNG is free from bias.)
(ii) Option to not draw the scrambles. Sometimes you just don't care, and that's fine.
(iii) Option to automatically copy the scrambles once they're generated. (Clipboard API was not a thing when I first wrote it in 2016, apparently?)
(iv) Option to generate as many scrambles as you want, all at once, without having to manually edit the code.
Note that the random-state scrambles are rather slow to initialise. The first batch of scrambles will take ~40 seconds, but subsequent ones will take around 30 milliseconds per scramble. The hybrid scrambles (partial random state; this is the default if you don't check "use random-state scrambles") are much faster to init, but they're also a bit longer. (They may also occasionally contain moves that can cancel; this is not a bug. You can deal with it.)
New "release" of the kilominx random-state scrambler.
(don't want to go to the trouble of saving the file first? here's a hosted version)
Key features:
(i) Now uses Fisher-Yates shuffling instead of… whatever the heck I was doing before! (What this means: it's truly random-state now, as opposed to being very slightly biased. At least, insofar as you can assume the web browser's RNG is free from bias.)
(ii) Option to not draw the scrambles. Sometimes you just don't care, and that's fine.
(iii) Option to automatically copy the scrambles once they're generated. (Clipboard API was not a thing when I first wrote it in 2016, apparently?)
(iv) Option to generate as many scrambles as you want, all at once, without having to manually edit the code.
Note that the random-state scrambles are rather slow to initialise. The first batch of scrambles will take ~40 seconds, but subsequent ones will take around 30 milliseconds per scramble. The hybrid scrambles (partial random state; this is the default if you don't check "use random-state scrambles") are much faster to init, but they're also a bit longer. (They may also occasionally contain moves that can cancel; this is not a bug. You can deal with it.)
Last edited:
LukasCubes
Veteran
Hey how many moves should the scramble be for kilominx when I am using old style scramble on cstimer?
Short answer: 100 moves ought to be enough.
Long answer:
Use the scramble generator I posted above.
Seriously, just do it. It's not that hard to use (just press a button!), and you're definitely getting proper scrambles if you check the "use random-state scrambles" option. The only downside is that you need to manually paste the scrambles into csTimer and that it takes a horrendous amount of time to generate the first batch of scrambles. (I have a rough idea of what to change to make it faster, so I guess I'll work on it this weekend.)
The next best thing is to use the hybrid scrambles. (Same program; just leave "use random-state scrambles" unchecked.) Again, you still have to manually paste the scrambles into csTimer, but they're still guaranteed to be uniform random-state in one aspect (locations of the white and grey corner pieces) and almost-uniform in another (corner orientation).
The third option is to use standard megaminx scrambles. If 70 moves is too long for your liking, maybe cut it to 60 moves. Purely by gut feel, I think 40 moves (which we're using in the forum weekly comp) is too little, but at least there's precedent for that too.
The 12-gen scrambles are extremely bad. They're hard to read, slow to execute, and need to be long to effectively scramble the puzzle. It's the worst of all worlds. But to address your original question: how long should they be?
We first have to note that csTimer's implementation is cursed and only returns 1/5 clockwise turns for each face. According to this post by Herbert Kociemba, the number of canonical scramble sequences of length n, with the length being measured in terms of clockwise fifth turns, grows roughly like 12 × 9.249^(n−1). (It's probably off by a small constant factor, but this does not materially affect the conclusion.) There are around 2.4e25 states on a kilominx and only around 2e25 scrambles of length at most 25, so to even reach every possible state, you need at least 26 moves. If your scramble sequences are 25 moves or less, there'll be a bunch of perfectly legal scrambles you just won't get.
So, answer is 26 moves, and we're done, right? Wrong! The above computation allows for consecutive moves to be of the same face, but this is not what csTimer does. Instead, csTimer does the whole commutativity check thingy and (i) never allows consecutive moves to be of the same face and (ii) doesn't even allow subsequences like L R L or U D U even when there's an intervening different move. This substantially reduces the number of possible scrambles, although now I don't have a convenient formula someone else already worked out to reference, so we can't continue with the scramble count analysis. What we can do, however, is to look at where the pieces end up after so-and-so many moves, sampling a large number of old-style scrambles. (For that matter, this is a better way of analysing scrambles than just counting scramble sequences. More on this later.)
With 100000 scrambles, 21 moves, this is the distribution of what corner piece is in position #0 (the U-BL-BR corner), and what its orientation is.
[3704, 2073, 1380, 2608, 4005, 2748, 2005, 2609, 866, 1382, 463, 835, 1357, 1392, 2552, 277, 448, 881, 914, 437, 4603, 4003, 2120, 1318, 2853, 2015, 2875, 1295, 1355, 865, 468, 1413, 875, 2104, 2616, 307, 528, 794, 827, 486, 2394, 2876, 2887, 2478, 2046, 4150, 1376, 2568, 867, 803, 643, 866, 803, 2862, 1261, 305, 643, 1411, 1425, 680]
You don't need to load up any fancy statistical analysis software to see that this is very much not uniform. With proper scrambles, you'd expect 100000/60 = 1667 hits per bin, and you definitely don't expect to see only 300 hits in any of the bins. If you bother to actually do a Pearson's chi-squared test, this thing has a p-value of basically zero.
What about 30 moves?
[3165, 2821, 1972, 1640, 2436, 2186, 2247, 1638, 1422, 1224, 941, 1437, 1260, 1943, 2198, 754, 887, 1169, 1186, 887, 2230, 2466, 2263, 2151, 2084, 2858, 1721, 2109, 1302, 1152, 935, 1240, 1170, 2393, 1634, 736, 993, 1524, 1494, 951, 2874, 2049, 1739, 2180, 2802, 2399, 1994, 2168, 1112, 1492, 869, 1152, 1431, 1724, 2185, 683, 931, 1257, 1256, 884]
Still "obviously" non-uniform from a casual glance, although it's less extreme. Again, p-value is still basically zero.
60 moves?
[1880, 1845, 1760, 1663, 1784, 1847, 1782, 1680, 1603, 1593, 1452, 1543, 1622, 1736, 1755, 1386, 1468, 1657, 1617, 1492, 1870, 1760, 1878, 1762, 1836, 1918, 1732, 1795, 1589, 1614, 1554, 1603, 1486, 1767, 1715, 1435, 1514, 1642, 1632, 1483, 1833, 1820, 1699, 1786, 1870, 1709, 1708, 1798, 1643, 1558, 1489, 1650, 1584, 1686, 1826, 1483, 1534, 1611, 1505, 1458]
p-value is now 5e−146 or within a few orders of magnitude of that. The distribution is starting to look uniform, but the discrepancies are still large enough that the chi-squared test is a complete failure. You have to go up to around 90-100 moves for the distribution to really start approaching uniform. Here's the distribution with 100 moves, just for posterity:
[1710, 1643, 1692, 1747, 1701, 1679, 1686, 1686, 1711, 1634, 1671, 1644, 1633, 1715, 1665, 1658, 1675, 1756, 1657, 1674, 1703, 1584, 1635, 1624, 1664, 1649, 1666, 1641, 1666, 1621, 1685, 1574, 1580, 1766, 1688, 1711, 1622, 1714, 1638, 1652, 1677, 1739, 1713, 1688, 1720, 1701, 1673, 1711, 1671, 1635, 1606, 1664, 1613, 1649, 1740, 1645, 1579, 1638, 1663, 1555]
And the p-value: 0.086. This means that with 100000 samples, there is no statistically significant difference (at a 5% threshold) between ideal scrambles and csTimer "old style" 100-move scrambles. There still is a difference; it just needs more samples to consistently hit the 5% threshold.
Maybe you'd say that 100000 samples is kind of overkill, and I'd be inclined to agree, but the thing is that I'm not analysing the full scramble, but only one corner piece; non-uniformity in the distributions among multiple corner pieces might mean an increased chance of pre-made blocks compared to ideal scrambles, which means the scrambles are biased towards being easier. If the marginal distributions already deviate significantly from uniform, the joint distribution can't be any closer.
If you're sharp, you may have noticed that applying the scramble count analysis to the Pochmann R++/D++ scrambles actually also shows that 70 moves is vastly inadequate. There are only 2^70 = 1.2e21 such scrambles, which is much smaller than the number of kilominx states. Despite this, we currently believe that the Pochmann RDU scrambles are "generic": they don't have easily-recognised special features that allow you to solve them faster than the other scrambles, on average.
ADDENDUM:
If you're really sharp, you might have noticed that I pulled a fast one on you. We don't actually need the distribution itself to be uniform; we just want the distribution modulo rotations to be uniform (whatever this means—it's actually nonobvious how we should define "modulo rotations" here and I don't have a good answer). This is because the kilominx has no fixed centres, but unlike 2×2×2 (which also has no fixed centres), you can't just fix a corner piece and rewrite face turns that move that corner piece into face turns that don't—they'd be rewritten into wide turns instead. Wide turns move 15 pieces, as opposed to face turns moving only 5, so they're truly very different in the case of a kilominx.
Nevertheless, there's no good reason to expect that modding out rotations will mysteriously and magically smooth out the nonuniformity.
ADDENDUM 2: Statistical significance versus practical significance
This is a topic that should be taught in every introductory statistics class, but (to my knowledge) often isn't. (At least, I wasn't taught this in high school. Then again, I also refused to take the AP Stats prep class then because I thought I was smarter than the teacher(and, you know, I was). … I digress.)
In "real life", you almost never have exactly identical values. The outcome of an experimental drug versus the placebo is never going to be exactly identical; crank up the sample size enough and you will find that the drug has some effect. How large is the effect? The larger your sample size, the more sensitive your experiment will be to tiny differences. There is some point where the difference is so tiny that you just don't care—it may be statistically significant with your ginormous N=1000000000 sample size, but not practically significant in reality.
It's kind of the same thing when we're analysing scrambling methods. Markov chain random state is the ideal scrambling method (imagine doing a billion random moves, then replacing it with a shorter move sequence that has the same effect), but often isn't a practical option. So we compromise by using random moves instead, which brings us again to the question of how many random moves to use. With the exception of almost-trivial puzzles like a 2×2×1, applying random moves will never exactly reach the stationary distribution. It converges there, and it even does so exponentially quickly, but it'll never be exact. So the real question here is: how much of a deviation from the stationary distribution can we accept?
If we can't do proper random-state scrambles, the state space is necessarily also too large to directly compare the distribution of random-move scrambles to the stationary distribution. Instead, we'll have to compare either some subset of the state space (this is usually not a good idea), or some quotient of the state space (this is usually what people do). What I mean by "quotient" here is grouping up similar-looking states together in the state space, for some sense of "similar-looking". That's actually one more parameter you get to choose when analysing the scrambles.
Some notions of "similar-looking" are more useful than others. For example, many years ago, Stefan Pochmann analysed the edge orientation of random-move scrambles for the 3×3×3. That's quite useful, since it was very relevant to the most common blindsolving method then (3OP). An example of a useless notion of "similar-looking" is to take the SHA-1 hash of the puzzle state and classify by the first 8 bits of that; the states being grouped together have basically no relation to each other.
So, once you've chosen your notion of "similar-looking", and also a threshold for the amount of acceptable deviation, you can either exactly compute the exact distribution for random-move scrambles (this is not always possible, but sometimes it is, e.g. the aforementioned EO analysis) or compute it empirically by doing thousands/millions/billions of scrambles with a computer program. You can then do an appropriate statistical test to determine whether this empirical distribution is within your threshold. (Note that this can require much larger sample sizes than just a basic statistical significance test like I did above! You're trying to find the shortest scramble length that lies within the threshold (because shorter scrambles are better, all else equal), which also means that you'll be very close to the threshold, which in turn means you need a lot of samples to determine whether it's really under the threshold or if it's a statistical fluke.)
Seriously, just do it. It's not that hard to use (just press a button!), and you're definitely getting proper scrambles if you check the "use random-state scrambles" option. The only downside is that you need to manually paste the scrambles into csTimer and that it takes a horrendous amount of time to generate the first batch of scrambles. (I have a rough idea of what to change to make it faster, so I guess I'll work on it this weekend.)
The next best thing is to use the hybrid scrambles. (Same program; just leave "use random-state scrambles" unchecked.) Again, you still have to manually paste the scrambles into csTimer, but they're still guaranteed to be uniform random-state in one aspect (locations of the white and grey corner pieces) and almost-uniform in another (corner orientation).
The third option is to use standard megaminx scrambles. If 70 moves is too long for your liking, maybe cut it to 60 moves. Purely by gut feel, I think 40 moves (which we're using in the forum weekly comp) is too little, but at least there's precedent for that too.
The 12-gen scrambles are extremely bad. They're hard to read, slow to execute, and need to be long to effectively scramble the puzzle. It's the worst of all worlds. But to address your original question: how long should they be?
We first have to note that csTimer's implementation is cursed and only returns 1/5 clockwise turns for each face. According to this post by Herbert Kociemba, the number of canonical scramble sequences of length n, with the length being measured in terms of clockwise fifth turns, grows roughly like 12 × 9.249^(n−1). (It's probably off by a small constant factor, but this does not materially affect the conclusion.) There are around 2.4e25 states on a kilominx and only around 2e25 scrambles of length at most 25, so to even reach every possible state, you need at least 26 moves. If your scramble sequences are 25 moves or less, there'll be a bunch of perfectly legal scrambles you just won't get.
So, answer is 26 moves, and we're done, right? Wrong! The above computation allows for consecutive moves to be of the same face, but this is not what csTimer does. Instead, csTimer does the whole commutativity check thingy and (i) never allows consecutive moves to be of the same face and (ii) doesn't even allow subsequences like L R L or U D U even when there's an intervening different move. This substantially reduces the number of possible scrambles, although now I don't have a convenient formula someone else already worked out to reference, so we can't continue with the scramble count analysis. What we can do, however, is to look at where the pieces end up after so-and-so many moves, sampling a large number of old-style scrambles. (For that matter, this is a better way of analysing scrambles than just counting scramble sequences. More on this later.)
With 100000 scrambles, 21 moves, this is the distribution of what corner piece is in position #0 (the U-BL-BR corner), and what its orientation is.
[3704, 2073, 1380, 2608, 4005, 2748, 2005, 2609, 866, 1382, 463, 835, 1357, 1392, 2552, 277, 448, 881, 914, 437, 4603, 4003, 2120, 1318, 2853, 2015, 2875, 1295, 1355, 865, 468, 1413, 875, 2104, 2616, 307, 528, 794, 827, 486, 2394, 2876, 2887, 2478, 2046, 4150, 1376, 2568, 867, 803, 643, 866, 803, 2862, 1261, 305, 643, 1411, 1425, 680]
You don't need to load up any fancy statistical analysis software to see that this is very much not uniform. With proper scrambles, you'd expect 100000/60 = 1667 hits per bin, and you definitely don't expect to see only 300 hits in any of the bins. If you bother to actually do a Pearson's chi-squared test, this thing has a p-value of basically zero.
What about 30 moves?
[3165, 2821, 1972, 1640, 2436, 2186, 2247, 1638, 1422, 1224, 941, 1437, 1260, 1943, 2198, 754, 887, 1169, 1186, 887, 2230, 2466, 2263, 2151, 2084, 2858, 1721, 2109, 1302, 1152, 935, 1240, 1170, 2393, 1634, 736, 993, 1524, 1494, 951, 2874, 2049, 1739, 2180, 2802, 2399, 1994, 2168, 1112, 1492, 869, 1152, 1431, 1724, 2185, 683, 931, 1257, 1256, 884]
Still "obviously" non-uniform from a casual glance, although it's less extreme. Again, p-value is still basically zero.
60 moves?
[1880, 1845, 1760, 1663, 1784, 1847, 1782, 1680, 1603, 1593, 1452, 1543, 1622, 1736, 1755, 1386, 1468, 1657, 1617, 1492, 1870, 1760, 1878, 1762, 1836, 1918, 1732, 1795, 1589, 1614, 1554, 1603, 1486, 1767, 1715, 1435, 1514, 1642, 1632, 1483, 1833, 1820, 1699, 1786, 1870, 1709, 1708, 1798, 1643, 1558, 1489, 1650, 1584, 1686, 1826, 1483, 1534, 1611, 1505, 1458]
p-value is now 5e−146 or within a few orders of magnitude of that. The distribution is starting to look uniform, but the discrepancies are still large enough that the chi-squared test is a complete failure. You have to go up to around 90-100 moves for the distribution to really start approaching uniform. Here's the distribution with 100 moves, just for posterity:
[1710, 1643, 1692, 1747, 1701, 1679, 1686, 1686, 1711, 1634, 1671, 1644, 1633, 1715, 1665, 1658, 1675, 1756, 1657, 1674, 1703, 1584, 1635, 1624, 1664, 1649, 1666, 1641, 1666, 1621, 1685, 1574, 1580, 1766, 1688, 1711, 1622, 1714, 1638, 1652, 1677, 1739, 1713, 1688, 1720, 1701, 1673, 1711, 1671, 1635, 1606, 1664, 1613, 1649, 1740, 1645, 1579, 1638, 1663, 1555]
And the p-value: 0.086. This means that with 100000 samples, there is no statistically significant difference (at a 5% threshold) between ideal scrambles and csTimer "old style" 100-move scrambles. There still is a difference; it just needs more samples to consistently hit the 5% threshold.
Maybe you'd say that 100000 samples is kind of overkill, and I'd be inclined to agree, but the thing is that I'm not analysing the full scramble, but only one corner piece; non-uniformity in the distributions among multiple corner pieces might mean an increased chance of pre-made blocks compared to ideal scrambles, which means the scrambles are biased towards being easier. If the marginal distributions already deviate significantly from uniform, the joint distribution can't be any closer.
If you're sharp, you may have noticed that applying the scramble count analysis to the Pochmann R++/D++ scrambles actually also shows that 70 moves is vastly inadequate. There are only 2^70 = 1.2e21 such scrambles, which is much smaller than the number of kilominx states. Despite this, we currently believe that the Pochmann RDU scrambles are "generic": they don't have easily-recognised special features that allow you to solve them faster than the other scrambles, on average.
ADDENDUM:
If you're really sharp, you might have noticed that I pulled a fast one on you. We don't actually need the distribution itself to be uniform; we just want the distribution modulo rotations to be uniform (whatever this means—it's actually nonobvious how we should define "modulo rotations" here and I don't have a good answer). This is because the kilominx has no fixed centres, but unlike 2×2×2 (which also has no fixed centres), you can't just fix a corner piece and rewrite face turns that move that corner piece into face turns that don't—they'd be rewritten into wide turns instead. Wide turns move 15 pieces, as opposed to face turns moving only 5, so they're truly very different in the case of a kilominx.
Nevertheless, there's no good reason to expect that modding out rotations will mysteriously and magically smooth out the nonuniformity.
ADDENDUM 2: Statistical significance versus practical significance
This is a topic that should be taught in every introductory statistics class, but (to my knowledge) often isn't. (At least, I wasn't taught this in high school. Then again, I also refused to take the AP Stats prep class then because I thought I was smarter than the teacher
In "real life", you almost never have exactly identical values. The outcome of an experimental drug versus the placebo is never going to be exactly identical; crank up the sample size enough and you will find that the drug has some effect. How large is the effect? The larger your sample size, the more sensitive your experiment will be to tiny differences. There is some point where the difference is so tiny that you just don't care—it may be statistically significant with your ginormous N=1000000000 sample size, but not practically significant in reality.
It's kind of the same thing when we're analysing scrambling methods. Markov chain random state is the ideal scrambling method (imagine doing a billion random moves, then replacing it with a shorter move sequence that has the same effect), but often isn't a practical option. So we compromise by using random moves instead, which brings us again to the question of how many random moves to use. With the exception of almost-trivial puzzles like a 2×2×1, applying random moves will never exactly reach the stationary distribution. It converges there, and it even does so exponentially quickly, but it'll never be exact. So the real question here is: how much of a deviation from the stationary distribution can we accept?
If we can't do proper random-state scrambles, the state space is necessarily also too large to directly compare the distribution of random-move scrambles to the stationary distribution. Instead, we'll have to compare either some subset of the state space (this is usually not a good idea), or some quotient of the state space (this is usually what people do). What I mean by "quotient" here is grouping up similar-looking states together in the state space, for some sense of "similar-looking". That's actually one more parameter you get to choose when analysing the scrambles.
Some notions of "similar-looking" are more useful than others. For example, many years ago, Stefan Pochmann analysed the edge orientation of random-move scrambles for the 3×3×3. That's quite useful, since it was very relevant to the most common blindsolving method then (3OP). An example of a useless notion of "similar-looking" is to take the SHA-1 hash of the puzzle state and classify by the first 8 bits of that; the states being grouped together have basically no relation to each other.
So, once you've chosen your notion of "similar-looking", and also a threshold for the amount of acceptable deviation, you can either exactly compute the exact distribution for random-move scrambles (this is not always possible, but sometimes it is, e.g. the aforementioned EO analysis) or compute it empirically by doing thousands/millions/billions of scrambles with a computer program. You can then do an appropriate statistical test to determine whether this empirical distribution is within your threshold. (Note that this can require much larger sample sizes than just a basic statistical significance test like I did above! You're trying to find the shortest scramble length that lies within the threshold (because shorter scrambles are better, all else equal), which also means that you'll be very close to the threshold, which in turn means you need a lot of samples to determine whether it's really under the threshold or if it's a statistical fluke.)
edit: Added two addenda above.
Last edited:
Finally got around to doing the optimisations. The kilominx random-state scramble generator is now roughly 2.4 times as fast (~13 seconds instead of ~31 seconds to generate the first batch). Available at the same links.
Note that the auto-copy is probably not going to work for the first batch of scrambles if you leave it running while you go do other things on your computer/phone/whatever, since web browsers rightfully refuse to mangle your clipboard when the web page isn't focused. You'll see a popup box if you have auto-copy checked and the copying fails for any reason. (Except if you're loading it over HTTP (or another insecure context), in which case auto-copying will fail silently. This will be fixed the next time I'm bored enough to bother, but also how about you don't go out of your way to type the URL and click one of the links above instead?)
The original Python version (that I banged out in one afternoon) was like an order of magnitude slower, so, y'know.@xyzzy maybe your code is slow because you wrote it in javascript
Real talk; it's slow because this is a hard problem and I'm also bad at programming.
qwr
Legend
The original Python version (that I banged out in one afternoon) was like an order of magnitude slower, so, y'know.
Real talk; it's slow because this is a hard problem and I'm also bad at programming.
did you try running it with pypy?
I was going to say "did PyPy even support Python 3 in 2016, because the last time I tried to use it it only supported Python 2" but it turns out the answer is "yes, support was added in 2014", so I have no excuse there. I'm not curious enough to try it for myself, but if you want to, well, knock yourself out.
qwr
Legend
so is the reason kilominxes don't have good reverse cutting because the centers are so small and protrude all the way to the outside of the cube? The only way a 2x2 has reverse corner cutting is by hiding the center piece behind the corner caps.
qwr
Legend
Honestly the Shengshou kilominx is so frustrating for speedsolving I don't even want to bother. It keeps on slipping and accidentally misaligning layers in my hand. Anyone have a good method to control the puzzle?
On the Shengshou you can remove the centre caps, which gives pieces a bit more room to reverse cut. Supposedly. It doesn't seem to make much of a difference on mine.
Honestly, if you want a good "kilominx", use any modern megaminx but with uncoloured edges and centres. If your megaminx is stickered, this means removing the stickers; if it's capped (like the Galaxy v1 or the Gan), you can remove the caps.
qwr
Legend
I looked at the mechanism and that doesn't seem like it would help because the center stalk and bottom of corner piece just aren't shaped correctly.
I don't think the center "lip" is a problem in itself because the GTS2 has a very noticeable lip. Rather the corner needs to be a concave shape rather than the current solid blocky shape.
This is a good idea. Unfortunately my Yuhu v2 megaminx is stickerless without caps. It's sad that no company has made a reasonable kilominx yet (looking at you Qiyi) Magnets and ridges would benefit this puzzle a lot because of the difficulty is holding it.
Last edited:
BenChristman1
Legend
- Joined
- Oct 26, 2019
- Messages
- 3,601
- Location
- in my room doing math
- WCA ID
- 2019CHRI11
I have the ShengShou, but mine doesn’t sound as bad as both of yours. I just used it like it was OOTB until C@H, where I took off the center caps, loosened the tensions, and put in some DNM. Accidental turns happen occasionally, but not super often.
qwr
Legend
I tried that and it helps some with corner cutting but I still have issues with grip. The center caps are an irritating wedge shape that basically requires taking out pieces just to get them off.
I had a mod idea for the center stalk that was basically filing the corners, but that would require a lot of sanding and possibly some filling in with apoxie sculpt and I don't think the result would be that much better.
ray5
Regular
- Joined
- Oct 10, 2020
- Messages
- 39
I really like the R' D' R D technique for corner OLL, but I was surprised that it can also be used for PLL! I saw this here
So I had a question: Is it possible to merge OLL and PLL into one phase and do it faster using this R' D' R D algorithm?
So I had a question: Is it possible to merge OLL and PLL into one phase and do it faster using this R' D' R D algorithm?
abunickabhi
Legend
I think the R' D' R D algorithm will be faster than any algset which merges OLL and PLL on the kilominx. We also have to take into account the recognition part and fingertrickability part.
Similar threads
