Square-1 is now using the optimal solver as backend, thanks to the lightning-fast fixes from @cs0x7f :)

Requesting review from experienced people because this roots deep into the solver

Actual (problem) behavior

tnoodle-lib depends on a version of log4j that includes a severe security vulnerability as described here: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

Expected behavior

tnoodle-lib should depend on log4j version 2.16.0 or later. This should be as simple as updating a build dependency and running some tests to make sure nothing breaks.

Steps To Reproduce

1. Build tnoodle-lib or a dependent project like my tnoodle-cli and see that it downloads log4j version 2.13.3

Desktop (please complete the following information):

• OS: MacOS and Windows
• Browser including version n/a
• TNoodle Version: latest (0.18.0)
• Java version: I'm using Java 11 which is generally considered safe from this CVE, but since tnoodle-lib also runs on Java 8, it should be upgraded to prevent any issues from users of that Java version.

Screenshots [OPTIONAL])

My gradle build cache after building tnoodle-lib from source showing the dependency on a vulnerable version of log4j

Additional context [OPTIONAL]

I'll just share the link to the official CVE description again for ease of access. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

The behavior of Search(FullCube fc) is different from previous one. By default, Search(FullCube fc) won't inverse the solution to generator. To generate scrambles, use Search(FullCube fc, int verbose) with verbose = Search.INVERSE_SOLUTION instead.

This part of the README: https://github.com/thewca/tnoodle-lib/blame/master/README.md#L58 links to https://bintray.com/thewca, which gives a 410 Gone. Is there a working link?

A year or so ago, I was trying to build an Android cube timer app. However, I found it quite difficult to find out how to use the tnoodle library for generating scrambles and scramble images. Ultimately, I figured out the usage from looking at the code of other projects using tnoodle-lib on GitHub and the tnoodle-samples repository, but this was quite tedious and time consuming, even though using tnoodle-lib for generating scrambles is actually very easy and only takes a few lines of code.

To make it easier and more accessible for people to use tnoodle-lib in their own projects, would it be possible to add some simple code snippets that show how to generate scrambles and scramble SVG strings for various kinds of puzzles in the README file of this repository or the tnoodle-samples repository? For example, for generating a scramble for a 3x3x3 cube, the code sample could be something simple like

Puzzle puzzle = new ThreeByThreeCubePuzzle();
String scramble = puzzle.generateScramble();

and for generating a scramble SVG string, the code sample could be something like

Puzzle puzzle = new ThreeByThreeCubePuzzle();
String scramble = puzzle.generateScramble();
String SVGString = puzzle.drawScramble(scramble, null).toString();

Hey there, sorry for opening an issue for this, I tried to find any other resources of how are the official scrambles generated for competitions.

I'm currently working on a timer app, written in Python. The way I implemented the scramble generation is not the best nor the official way. I would like to implement official scrambles into my app and possibly make a Python module out of it. If you all are ok with it.

I don't need actual code, just an explanation of how it is done.

Thanks

These are annoying, and can't be controlled in the same way that logging can. Plus, thewca/tnoodle#112 kind of requires this.

This issue can be closed once we've gone through all our code and removed the offending calls, and then added a precommit hook to make sure we don't add any new ones.

Since (x, y) is counted as a single move in WCA metric, the number of states that can be solved in 11 moves is much larger than that in face turn metric. Similarly, the search space is also much larger than that in face turn metric at specific move limit.

On my laptop, the average solving time spent for checking 11-move solvability is about 10ms for a random state. However, for specific states (e.g. 15-move scrambled state), it might take several seconds to do the verification.

Recent Gradle versions have deprecated Java 6. We kept J6 compatibility for Android, but even there J8 is fine these days. So I migrated everything and even cleaned some static code analysis warnings while I'm at it.

See title. This is essentially replicating the condition from https://github.com/suushiemaniac/tnoodle-lib/blob/64eae76555321ac6801f817c4e9deb3cf8815c9a/threephase/src/main/java/cs/threephase/Edge3.java#L166

Now that the individual scramblers have been extracted, we can basically reproduce PuzzlePlugins.

Merging as soon as Travis says Yes, because this reinstates a previously existing feature.

Using the scrambler from https://github.com/cs0x7f/cube555 with some minor adjustments (mostly for inverting solutions). The code has not been officially reviewed or sanctioned by WST or WRC at this point!

Contains some duplication from the error handling of ThreeByThreeCubePuzzle. At this point in time, I just wanted to come up with "something that works":tm:. No need to formally review, but feedback is always welcome :smile:

Based on a discussion about allowing 5x5 misscrambles, which pointed us back to https://github.com/thewca/tnoodle-lib/issues/17

Currently, this scrambles all layers that have centers using 3x3 random state scrambles from outside to inside, except for the innermost layer of even NxN, which resorts to using a 2x2 random state scramble. The model scales to any NxN automatically, meaning we can apply the concept to 6x6 and 7x7 on a whim.

As of the intial PR, the outermost layer (the "reduction stage") is not scrambled with a 3x3 random state, although this can be fixed by literally changing one character in the source code (changing a one to a zero in the constant EXCLUDE_OUTER_LAYERS definition)

Obviously this is not tested thoroughly because it's intended as a proof of concept at this stage. These scrambles are not WCA-legal! We also have not had a second pair of eyes to check the original mathematical analysis that prompted this approach.

Feel free to discuss!

In big cube scrambles, a sequence with unnecessarily many regrips might appear, such as "Rw Lw' R2 L", where all the moves are across the same axis, and therefore the order of them doesn't change the scramble state.

My proposal is that anytime moves on the same axis appear in sequence, they are sorted, such that you perform all moves starting with the same letter first, e.g. "L' Lw 3Lw2 3Rw Rw' R2" instead of switching back and forth between L and R. i propose sorting moves left to right, top to bottom, and front to back, but i'm impartial to the directions.

As a developer, I'd like to use tnoodle-lib for web/desktop/iOS platforms. I think it's possible to rewrite the code so it can be used in Kotlin multiplatform projects. Any thoughts on this?

There was a post in CF today asking about repeated 2x2 scrambles, and someone found a duplicate 2x2 scramble within the same comp. This should probably be filtered out.

Scrambles ending in the same state but in a different orientation should be considered duplicates. However, whether a scramble that is the same as another scramble applied to a different starting orientation is a dupliate needs to be discussed.

Hello,

I've been writing a cubing tool for myself and scrambles have proven to be the hairiest part of the implementation. I've been hoping to avoid what I'm suggesting but I can't see any other tool in JavaScript that generates acceptable scrambles across different puzzles.

I have looked into the generated tnoodle.js file but this is far from ideal and has (unnecessary) dependencies on global objects (like window or document).

I have been reading through the codebase a little in preparation of a JS port and I just wanted to ask here if there are any upcoming plans to rewrite tNoodle. It doesn't have to be JS but I feel like the codebase needs a bit of cleaning up (I would like to understand the decision behind tightly coupling the representation of puzzles (svg) to the scramble generator).

I feel like I will go ahead with a JS port and make it available on npm (don't know when I will finisih it) and I would greatly appreciate if you could give me some pointers on where I should start within tNoodle, like general pointers to keep in mind.

Thanks a lot!