4x4x4 FMC (computer and human) round 2

Wow, only a 15-move reduction! That should be easy for my program; I should have
been able to find this with my new reduction solver fast enough.

I'm going to have to try running through a bunch of last-layer positions and see what
I can do. Is OBT or SST more interesting for this?

Congratulations, Herbert.

Thanks! Personally I would prefer OBTM, I surely will modify my solver to this purpose sooner or later. But my solver is not really finished yet, so I will stay with SSTM for some time.
 
I let the dedge flip solver run over night and now found a 12 + 5 = 17 move solution in SSTM and STM for the single dedge flip

U2 3R' F2 3R U2 3R' U2 2R2 F2 3R U2 2RD2 F2 2L2 F2 D2

I hope this is quite remarkable because in https://www.speedsolving.com/wiki/index.php/4x4x4_Parity_Algorithms#One_Dedge_Flip I see only a single dedge flip algorithm which is 17 moves in STM but it is more in SSTM.

this is cool! i have been playing with this alg, and tried to make it more fingertrick friendly...

rewriting moves like 3R gives U2 2L F2 2L' U2 2L U2 2R2 F2 2L' U2 2R D2 F2 2L2 F2 D2

then, removing the U2 at the beginning, swapping the single slice moves for wide moves and making a couple of adaptations gives 2r U2 2r' U2 2l U2 2r2 F2 2l' U2 2r D2 F2 2l2 F2 D2
i think this could be improved still, might come back to it later :)
 
(I believe this question is more applicable to Tom's solver than Herbert's.)

Do you use the fact that if you have a reduction state, and you have OLL parity (ignoring whether or not you have PLL parity), then you know you must be at least 13 BTM/OBTM/SSTM from solved (or from any "true" reduction state for that matter)?
 
(I believe this question is more applicable to Tom's solver than Herbert's.)

Do you use the fact that if you have a reduction state, and you have OLL parity (ignoring whether or not you have PLL parity), then you know you must be at least 13 BTM/OBTM/SSTM from solved (or from any "true" reduction state for that matter)?

No I don't; once I have a reduction state, I just use a 3x3x3, and until I have a
reduction state, centers aren't solved, so this doesn't apply, right?

And the edge permutation parity is one of the elements of my edge pruning
table so the only reduction solutions I encounter are those where the total
edge parity is even.

I'm sure you're onto something that is useful; I just need to figure out how.

(That is a good point, though; when I say "reduction solve" I actually mean
reduced to a legal 3x3x3 position. My "near misses" do not include situations
where the edge parity is wrong, only where the centers are not in the proper
axes, or the centers are mirrored, or the 3x3x3 edge/corner parity is off.
When a human is doing a "reduction" solve, usually, they include the
edge parity, do not include the center mirror/axis problem, and do include
the edge/corner total parity. So we are talking slightly different things
between the two. The fact that I see some axis problems with center solves
and count them as "near misses" is actually due to the way my pruning
table for centers is set up, and it was a bit of a surprise to me that that
happens.)
 
No I don't; once I have a reduction state, I just use a 3x3x3, and until I have a
reduction state, centers aren't solved, so this doesn't apply, right?

Well, it doesn't necessarily mean centers aren't solved. If you have the pure single dedge flip position (for instance), the centers are solved, but you don't have "true" reduction. So (since it has OLL parity, what you've called edge parity) you know you're 13 moves away from a "true" reduction state. So this generally is not so useful for "random" positions, but may effective for many positions that are 3x3x3 reduced except for the reduction parities (notably the ones that have OLL parity but not necessarily PLL parity), or very close to such positions.

By "true" reduction, I mean a position that is solvable with just (single-layer) face turns. (So each face must have like-color centers, opposite face colors must be on opposite faces, and you can't have the mirrored configuration of colors. Also edges must be all paired up, and you can't can't have the 3x3x3 edge/corner parity, aka PLL parity).

So doing this might prune out some of what you call your "near miss" solutions, at least ones due to bad center configurations.

So if your solver indeed generates optimal "true reduction" solutions, it should be able to verify my number of 13 moves for whatever metrics (of BTM, OBTM, SSTM) that it supports. Just run it on the pure dedge flip and the standard double parity case (dedges UF and UB swapped, with one of them flipped).
 
Who computed them? Where do I find them? To whom these solutions are known?

EDIT: Ok, I found it
https://www.speedsolving.com/forum/...lver&p=983757&highlight=dedge+flip#post983757

Thanks! The parity algorithm Wiki should be updated.
Why? Isn't a link to my post enough? (There are two sections on "pure" single dedge flips.)

However, it's cool that you wrote a solver to find optimal solutions for this case. Too bad god's number for the single slice quarter turn metric isn't as easily reachable right now though. (The current upperbound is 23 single slice quarter turns, but it could be 21 when I found an alg like 2R' F 2L' F2 2R F 2R' F2 D F' D 2L D' F D' 2L F2 2R.)
 
Last edited:
Obviously not, else I would not have been confused. Especially because your link points to the section "Pure Flips/OLL Parity Algorithms which Don't Preserve the Last Layer" and you should not be surprised if some people including me think that these algorithms do not preserve the last layer.
In no particular order,

  1. I assume that those know what the term "pure flip" means and those that know what "/" means in the English language (when put in between two words with no spaces) can deduce that the algorithms listed in this section are *both*.
  2. I clearly put "this case image and this case image" at the beginning of that section to visually explain that these algorithms are both.
  3. I expect for people to at least be open to read the few bulleted comments at the beginning of a section to clear up any misunderstandings and in fact explain everything.
  4. Context clues alone from the main titles themselves can tell you that I am listing algorithms which preserve less and less as the page progresses, considering that the next main title is simply "OLL Parity algorithms Which Don't Preserve the Last Layer", and the next is "OLL Parity Algorithms Which Don't Preserve F3L", ... , "Parity Algorithms Which Don't Preserve F3L or the Colors of the Centers".
  5. I made the time to translate all algorithms into SiGN notation and linked them to alg.cubing.net for animation on just about any device. If the viewer somehow fails to understand all of the previous four (independent) hints listed above that this set of algorithms is both pure flips and algorithms which don't preserve the last layer, he or she can simply click an algorithm and view its effect. I do link to the pure versions in this particular section, after all.

If someone else thinks these five ways I have attempted to make clear of the nature of the algorithms in this section Mr. Kociemba and I are talking about are still not enough that I have to post all 248 15 btm single dedge flip solutions twice on that page, please let me know.

Yes, there are A LOT of algorithms on that page, BUT I do not have any duplicate algorithms or any algorithms which are equivalent by a transformation (unless I say name the algorithm "...(v1)", "...(v2)", etc. to say "version 1", version 2", etc.) on that page.

I purposely made a serious and time-consuming effort to structure this page this way to:

  1. "factor out" algorithm equivalences,
  2. accurately demonstrate unique algorithms and/or unique algorithm paths (for those interested in parity algorithm theory), and
  3. guarantee that when speedcubers insert their own custom cube rotations into an algorithm or speed optimize it in another form, that they are not going to get another algorithm on that page.
 
Last edited:
those that know what "/" means in the English language (when put in between two words with no spaces) can deduce that the algorithms listed in this section are *both*.
The confusion was that you interpreted it as "Pure Flips or (OLL Parity Algorithms which Don't Preserve the Last Layer)" whereas he interpreted it as "(Pure Flips or OLL Parity Algorithms) which Don't Preserve the Last Layer". Surely you can see how that would be confusing. And of course, if someone thinks something's clearly the wrong section, they surely aren't going to read all the details of that section and click through to the alg.cubing.net links for each alg.
 
I made a lot of improvements to the reduction part (phase 1 and 2) of my three stage solver. It seems that 24 move reductions can be found in a time now that are acceptable for a solver to be used interactively. The time only depends on how deep we have to search in phase1. The goalstate of phase 1 is a cube from where it can be transformed to the reduction state using only <U,R,F2,D,L,B2,2U2,2R2,2F2,2D2,2L2,2B2> after some eventual full cube rotations. The full cube rotations between phase 1 and phase 2 could of course be omitted if the phase 2 moves would be transformed appropriately.

Nr 1: < 1 second for 12+12=24 move reduction

3F' 3R2 U' 2U 2F2 3r2 F R 3F' 3U 3f 3r' y z U2 2L2 U' 2D2 R 2U2 D L 2D2 2L2 L 2F2

Nr 2: < 1 second for 12+12=24 move reduction

R 2F' 2R2 3f' 2U' 3R' F' R' 2U 3u' 3F R' y z U L' 2F2 2R2 D' R' 2D2 L D' 2F2 R 2U2

Nr 3: < 1 second for 12+11=23 move reduction

3u 3R2 3u 2F2 3f' 2U2 3r 2U2 F2 2R 3U' 2F x' z' U 2R2 2U2 F2 U 2F2 D 2F2 U2 L' 2F2

Nr 4: < 2 minutes for 14+10=24 move reduction

3r2 3f 3u R' 3u2 3r2 2U R 2R' 3F2 U 3f 2R' 3F y z 2U2 2F2 R F2 R2 2F2 U2 R' 2F2 2R2

Nr 5: < 6 seconds for 13+11=24 move reduction

F 3f 3R2 3F 2U 3f 2U' 3u' 3r 3f' 3U' 3R' 3U L U2 B2 U 2R2 L 2U2 2L2 2F2 U 2R2

There are some large pruning tables and the program needs 15 GB of RAM. I use a DELL precision T5810 with 64 GB of RAM installed. All computations used only one thread.
 
Nr 1: < 1 second for 12+12=24 move reduction
Nr 2: < 1 second for 12+12=24 move reduction
Nr 3: < 1 second for 12+11=23 move reduction
Nr 4: < 2 minutes for 14+10=24 move reduction
Nr 5: < 6 seconds for 13+11=24 move reduction

That's pretty impressive! How well do other multistage reduction solvers do?

I presume you also get additional longer solutions. Any thought of hooking
up a standard optimal solver to work on those as they come through? Doing
shallow searches with an optimal solver for a large set of 26-move reductions
can be very fast. I.e., you keep an increasing queue of reduction solves of
whatever length, with one thread for that, and in another thread or three you
run a 3x3x3 optimal solver that picks out the best candidates/depths to try.
 
Indeed I want to implement some kind of optimal 3x3x3 solver for the third stage. But I have no time within the next few weeks to work on this so I do not think I have results before october.
 
Wow, I've not been here for ages.
This is so nice to see a computer contest for 4x4x4 FMC. I will dig my code from the graves and see how it goes on the 5 scrambles. I remember it having an average solution of 40 moves, but it was designed for fast solutions (about 1 sec), I've no idea if it can produce lower solutions.
 
Wow, I've not been here for ages.
This is so nice to see a computer contest for 4x4x4 FMC. I will dig my code from the graves and see how it goes on the 5 scrambles. I remember it having an average solution of 40 moves, but it was designed for fast solutions (about 1 sec), I've no idea if it can produce lower solutions.
Hi, Clément! I'm a big fan of your contributions to the 4x4x4 parity algorithm domain. Wow, I thought you were never going to be active on this forum again. (I can't recall you being very active since I've been a member, at least. :))

Just a random note, but, using Cube Explorer, I made a complete and organized list of all (unique) possible 15 btm single dedge flip algorithms and posted them in the bottom of this post. (I stated their relationships with each other as well.)

I am very curious to see what your old solver is capable of, since I have been blown away with the solutions you found with it to PLL parity cases. In fact, your solver's algorithms for PLL parity cases has been a marvel to me. I recently found an old Yahoo Group post of yours regarding the diagonal corner swap case.
Diag2cornerswap.png

I added that page as an external link on the 4x4x4 parity algorithms wiki page to show everyone some history!

Just to let you know that your work as been appreciated by non-speed cubers such as myself, in this post, I decomposed your favorite of your solver's diagonal 15 btm solutions and found a 16 btm one by hand! Because the formatting of my post got messed up with forum updates, I have rewritten what I posted there below so that it's readable.
After A LOT of arithmetic and expansion, I broke this algorithm into 5 pieces. It was difficult to do this since many of the moves in this outline were not within the original algorithm itself, but this IS the outline for this computer-generated algorithm:

Rw2 F2 U2 r2 __________________________Preliminary
r2
___________________________________ Extra turn to induce PLL Parity
U2 Fw2 U2 Fw2 U' Rw2 U2 Fw2 U Fw2 Rw2
___Base
r2 U2 F2 Rw2
__________________________Reverse of Preliminary
U
____________________________________Finishing turn to make pure

...

Here is the full outline of my algorithm:
Rw2 F2 U2 r2
________________________Preliminary moves found from Clement’s algorithm.
r2
____________ _____________________ Extra turn to induce PLL Parity
y z' Uw2 L' Uw2 L R Uw2 R' Uw2 z y' _______Base
r2 U2 F2 Rw2
_________________________Reverse of preliminary.
U
__________________________________Finishing turn to make pure

Now, I'm not sure if you have seen that wikipage before, but I'm sure you will enjoy it if you haven't. I do give you due credit for your algorithms, and I provide an external link to the 4x4x4 parity algorithm sets you have contributed to the community. (If there are other resources that I missed, please let me know, and I will add them!)

In addition, I (and I believe many others) was always curious as to why you didn't provide a solution for the adjacent corner swap case.
Adj2crnrsp.png

Can you possibly recall if your solver found solutions such as z 2R2 U2 R' U2 R' U2 R x U2 r2 U2 B2 L U2 L' U2 r2 U2 z' y' for this adjacent corner swap case?

I have been wanting to see what your solver generates to solve the adjacent case (besides my hand-found algorithms)

I guess, while I'm asking, I am very curious to see the shortest solutions your solver creates for adjacent double parity. (I found (y' 2R2 F r' F') 2R2 U2 2R' U2 2R' U2 2R' U2 (F r F' 2R2 y) by hand, which is 16 btm. I can recall that Per loved the structure of this algorithm!)
Adj.dblparity.png



Lastly, I wanted to let you know (just in case you haven't seen that wiki page before) of some notable algorithms that I found which tackle various parity cases. (Just click on the links to Lucas Garron's new cube applet to see the case, animation and the algorithm.) There are of course many more that I find notable, but here is a good sample of them.

Apart from this small set of K4LL 1 3-cycle and 1 2-cycle parity algorithms, the remainder of the algorithms in this post can be found on the 4x4x4 parity algorithms page, but I wanted to select these for which I believe, based on your past contributions, might be of the most interest to you in one way or another.

Computer-found algorithms
A single dedge flip algorithm which is almost "pure".
2R' F 2L' F2 2R F 2R' F2 D F' D 2L D' F D' 2L F2 2R (21,18)

A brief wide turn OLL parity algorithm which has slice turns in two directions!
r2 F2 U2 r' F' u L' U2 L u' F' r' U2 r2 F2 r (23,16)

Three semi-fast OLL parity algorithms
r' U' r' U B2 U' r U' r' U2 r' x' U2 r U2 l' U2 r2 (23,17)
r2 U2 l' U2 r U' r' U B2 U' r U' r' U2 r' x' U2 r' (23,17)
l r U' r U' F2 U r' U' x U2 r' U2 r' U2 l U2 r2 x (23,17)

One of several 3 dedge flip algorithms in the slice M.
2L 2R F2 2L B 2U' B D2 B' 2U B 2R' D2 B2 2L2 F2 2R' (23,17)

Computer-Human Interaction Found algorithms
All of these are from me learning from cuBerBruce's specialized parity algorithm solvers and making algorithms which "mimic" the same idea, just as I did the same to make that (27,16) diagonal corner swap algorithm by studying your solver's (27,15) algorithm.

Two single F3L slot destroyer parity algorithms
2R' U2 F' U2 F U2 2R' U2 2R' U2 2R' F' U2 F 2R' (21,15)
2L U2 F' U2 F U2 2L U2 2L U2 2L F' U2 F 2L (21,15)

An additional two single F3L slot destroying parity algorithms in a "prettier" move set.
2R' U R U2 R' U' 2R' U2 2R' U2 2R' U' R U2 R' U 2R' (21,17)
2L' U' R U2 R' U 2L' U2 2L' U2 2L' U R U2 R' U' 2L' (21,17)

Two OLL parity algorithms nearly in the <M,U> move set.
2R U' m' U m' U' m' U' m u2 2R u2 U' m' U2 m' U m U2 m U m' U m U m' U' 2L'
2R' U m' U' m' U m' U m u2 2L' u2 m' U m U' m' U m' U m U2 m' U2 2R (double parity)

Hand-found algorithms

12 btm flipped PLL parity
F2 2L e F2 e' 2L' 2R' e F2 e' 2R F2 (16,12)
F2 2L e' F2 e 2L' 2R' e' F2 e 2R F2 (16,12)

Adjacent PLL parity
(r' U R U l' U2 r' U2) 2R2 (U2 r U2 l U' R' U' r) (22,17)

Supercube safe O permutation PLL parity algorithms:
2L 2R 3d' L R 2U' L' R' 3d m2 3d L' R' 2U' L R 3d' 2L 2R (20,19)
2L' 2R' 3d' L' R' 2U L R 3d m2 3d L R 2U L' R' 3d' 2L' 2R' (20,19)
2L 2R 3d L R 2U L' R' 3d' m2 3d' L' R' 2U L R 3d 2L 2R (20,19)
2L' 2R' U y L' R' 2U' L R 3d' m2 3d' L R 2U' L' R' U y 2L' 2R' (20,19)

"Pure" Single Dedge Flips
x' r2 U2 l' U2 2R U2 l F2 U 2R U' F2 U 2R' U r2 x (23,16)
x r2 U2 r U2 2L' U2 r' F2 U' 2L' U F2 U' 2L U' r2 x' (23,16)
z d' m D l' u' 2R' u l u' l2' b' 2R' b r' R' 2U y' m' u x2 z' (19,18)
r' e u2 f u r' 2R' f' 2R f r u' f' u 2R u e' r (19,18)
l' s b2 d 2R d' b d 2R' d' 2R' b' 2R b 2R b s' l (19,18)
l' F' 2B' r' b' r 2U r' b r 2U2 b' 2U b 2U 2B F l (19,18)
r U2 r U r U2 r U2 r' U2 r' U 2R' U' r U2 r U2 r' U2 r' U 2R2 U2 r' U2 r' (37,27)
r U2 r U' r U2 r U2 r' U2 r' U' 2R' U r U2 r U2 r' U2 r' U' 2R2 U2 r' U2 r' (37,27)

Last layer 3 dedge flip + PLL parity
r' U2 2R U2 r' x' U2 2R' U' R' U' r' U2 r U R U' r R U2 x (24,19)

A ZBLL brief single F3L slot destroyer:
2L U2 2L' F U R U' l' D2 2R D2 2R U2 r' U2 l F (22,16)

Last layer opposite two wing edge swap
z r' U 2L' u' r u 2L' f' 2L' f 2L2 u' r' 2U r z' (16,15)

Last layer diagonal wing edge swap
u l' u' 2L' u l f' l2 u' 2L' u l' L' f u' (16,15)
u l' u' 2L' u l2 d' l u' 2L' u L' d l' u' (16,15)
u l' b' 2R' b l2 b' r f' 2R' f R' b l' u' (16,15)
r2 F2 U2 2R U2 x U2 r2 U2 2R' U2 2L 2R U2 2L' U2 x' (25,15)

Last layer adjacent "oriented" wing edge swap.
(These are one move shorter than the L' B' (opp. 2 wing edge swap) B L combo.)
r2 u' b 2R' b' u b r' u' 2R' u r 2R b' r2 (17,15)
r2 2F u' b d 2R' d' 2R' b' 2R b 2R b' u r2 (17,15)
y' f2 2L u' b u 2L' u' 2L' b' 2L b 2L b' u f2 y (17,15)
y' z' f2 r' d 2L' d' r d l' b' 2L' b l 2L d' f2 z y (17,15)

Here's a 16 quarter turn algorithm for the same case:
u r' u' 2R' u r b' r' 2R' u' 2R' u R 2R' b u' (16,16)
Although longer than the previous two (but still equivalent to the combo algorithm btm move count), I also found algorithms such as.
2R' u l u' 2R2 f2 l' f 2R' f' l f2 2R' u l' u' (19,16).
(This alg resembles the form of Frédérick Badie's single dedge flip algorithm (2R' U2 2L F2 2L' F2 2R2 U2 2R U2 2R' U2 F2 2R2 F2)

Last layer adjacent "close-unoriented" swap:
2L2' U l U2 2R' U2 r' U2 x U' 2R' U x' U2 x U' m' 2L' (20,15)
z F' r2 2B' u l' u' 2B u 2B l 2B' l' 2B' l u' r2 F z' (19,17)
z F' l2 u b' 2L b u' b' l u 2L u' l' 2L' b l2 F z' (19,17)
z F' r2 z' r b' 2L b r' b' l d 2L d' l' 2L' f r2 F z' (19,17)
l' 2B u2 l u 2F' u' l' u 2F' l 2F' l' 2F2 u 2B' l (19,17)

Last layer adjacent "far-unoriented" swap:
2L2' U' l U2 2R' U2 r' U2 x U 2R' U' x' U2 x U m' 2L' (20,15)
r 2R z 2L f' u f 2L' f' 2L' u' 2L u 2L u' f z' r' 2R' (17,17)
r 2R y r' d 2L' d' r d l' b' 2L' b l 2L u' r' 2R' (17,17)
l 2R u' f 2L' f' u f l' u' 2L' u l 2L f' l' 2R' (17,17)

Last layer checkerboard algorithms which are similar in structure Stefan Pochmann's PLL parity algorithm: (r2 F2 U2) 2R2 (U2 F2 r2).
(2F2 2U' 2R2 u2 s') 2R (s u2 2R2 2U 2F2) (17,11)
(2F2 2U 2R2 u2 s') 2R (s u2 2R2 2U' 2F2) (17,11)

"OLL Parity" algorithms which don't preserve the centers or the Pseudo 3x3x3 state
r' U' R' U' r F' R' F' r' (9,9)
r' U' R U' r F' R F' r' (9,9)
r U' R U' 2R' D' R D' r (9,9)
 
Last edited:
Here are my solutions:
1. L' D2 2L2 U' F' U2 2D 2F2 L' 2R' 2U' F 2B 2D B2 2L' 2F2 R2 F B2 2U' F' B2 2D' F2 R2 2U2 L2 B 2D2 F2 U2 F 2R2 U2 2F2 2L2 U2 2L2 2F2 2L2 (41)
2. 2F' D F' 2F2 2U2 B2 R D F2 L' U' 2L' 2U F2 2D' 2L2 2F 2L' 2U2 2R2 U' B2 R2 2F2 2L' 2U2 D B2 U' 2L2 2B2 R2 D 2B2 U2 R2 2F2 2R2 B2 2D2 2L2 F2 (42)
3. L F' D' B L 2L 2U B R' U' L2 2U 2F2 R B2 R 2B 2U' R2 2F2 D2 2F2 L 2U' L' 2U' U2 R' 2B2 U2 L U2 F2 L 2L2 B2 L2 D2 F2 (39)
4. U2 L2 D2 F 2F' R 2F 2R 2B D' R' 2F2 D2 2D 2B 2L F' 2U' 2F' D2 U2 B' 2U' L2 2D' F2 2U' F' L2 2R2 B2 D2 B R2 U2 F 2D2 2B2 L2 2D2 2F2 (41)
5. 2L2 2U L F2 D2 2F2 L' U' F2 R' 2B2 2L 2U2 L2 D' 2L' D2 2B U' 2L2 2B2 U' 2D2 2L 2B2 2R U 2R2 2B2 D2 2F2 U' D2 B2 U 2D2 F2 2F2 (38)

EDIT: Each solution took about ten minutes to produce.

Christopher, that's nice to see you have been digging a lot in this topic. I see you have taken care of crediting everyone :)
I've been searching on my old files, but I didn't find my results for the pll parity cases. I guess that I didn't publish results for cases when I didn't find improvements other known algorithms. They were produced with a very naive program though, just bruteforce searching and storing hashes of all positions close to the solved state.

Hey ch_ts, I'm using a 5-stage solver who's principle was designed by Bruce (http://cubezzz.dyndns.org/drupal/?q=node/view/62). This solver does not reduce to a 3x3x3 solve, but reduce to the squares coset. One advantage of this solver is that each step is well defined in terms of representing cosets, whereas the solver using 3x3x3 reduction has a problem with parity if I remember correctly. Each step except the third one is small enough so that a complete pruning table can be stored, using clever symmetry reduction (up to a 192 factor reduction for stage 5). The problem of this solver is that you cannot use the known work and results from 3x3x3 solving.
Currently, I can solve each stage very fast, but I don't have a good strategy to produce short multistage solutions. Right now, I solve stage by stage, and I keep the best 100,000 solutions(+pruning of the next stage) of each to the next one.
I also tried to just produce each optimal solution from stage 1, then for each solution produce all optimal solution from stage 2, etc. My problem is that for a given stage, I have a lot of optimal solutions that look very close, and combining all those solutions for five stages is making the search very very long, just for optimal solutions of each stage.
The source code is here: https://github.com/clementgallet/FiveStage444
 
Last edited:
Back
Top