aCube frontend v3.4 release! (beta)

After lots of postponing, I finally have a 'working' GUI front-end for ACube3.
I'd like to consider this ACube3.1, for all intensive purposes, and I'll rename as I get better releases.
THIS *MOSTLY* SUPPORTS AMBIGUOUSLY DEFINED CUBES
Here it is:
aCube 3.4
Screenshot
Expect PLLs to take like 20s on an average computer? Especially if hte "show all" option is on and the "show optimal" isn't.
Features:
I'm working with Josef to make the above happen. It'll only be considered aCube4 once we've implemented most of the above.

YAY!

Awesome, thanks

StachuK1992 said:

• Wide-turn support.
• M' vs M move restrictions, and restrictions likewise.
• Everything will be on github.
• It will be faster. Significantly.
• Pre-pruned tables will be an option. This means not waiting 15+ s in order to have the program actually look for a solution.
• Less memory (RAM) usage.
• GUI. We'll support both GUI and command ACube4, but GUI will likely be more supported than not.
• If the pre-pruned tables work out nicely, I could host a server-side ACube. Yeah, that's kind of awesome.

Click to expand...

YAY

may i suggest sth?

i am currently learning some ZBLL algos for OH and many algs can be created using only <RUL> but often <RUF> (or <RUFL>) is shorter. however i usually do not want more than 2 Fs to be in such an algorithm... is there some way to limit the number of F-moves in such an algorithm?

a "solved cube" button would also be very nice. (like in CE)

Those seem like appropriate suggestions to me, although the first of them will have to wait for a little while.

Thanks!

Simply awesome, many thanks

I would like to see both the features of Cube Explorer Facelet Editor and Heise's ACube front end, particularly...
Cube Explorer:
- Move buttons
- Apply maneuver in text box.
- direct painting of facelets (already has this, of course, except for graying facelets)
Heise:
- swapping cubies (but unlike Heise, do it "correctly," at least if completely colored cubies are swapped)
- twisting corners, flipping edges
- ignore position/orientation (would be an inherent part of ambiguous cubie support, I presume)

One thing I note lacking in ACube is direct support for "separation" steps. That is, you want the "solver" to place a piece into its correct layer, without caring about exact position. (I am guessing this will continue to be a wish list item.)

Bruce -
Move buttons and alg-execution will both of course be implemented.

Yes, I need to work on the graying of facelets, that will come with incomplete cubes

Hrm, I'll think about how to approach twisting/flipping cubies.

yes yes, those will be in the 'ambiguous cubes' update whenever that will be.

I'll talk to Jelinek about it and see what we can do, regarding that last request.
Edit:
"it will not be difficult (it is ready for that more or less), but the input is tricky"
Suggestions for input, Bruce?

StachuK1992 said:

Hrm, I'll think about how to approach twisting/flipping cubies.

Click to expand...

Surely you've seen this, maybe you can take ideas from that script, if you have it. (The only problems I have with that site is you can't un-gray pieces, or un-ignore them).

Wide-turn support is going to be awesome.

Stachu knows what needs to go into a functional GUI, as he's used mine plenty He just wanted to release it before it was done so he could get some feedback on what IS done.

whauk said:

i am currently learning some ZBLL algos for OH and many algs can be created using only <RUL> but often <RUF> (or <RUFL>) is shorter. however i usually do not want more than 2 Fs to be in such an algorithm... is there some way to limit the number of F-moves in such an algorithm?

Click to expand...

Yeah, this is a good idea. All ZBLLs can be done with at most 2 F moves (or at most 2 L moves, or at most 2 D moves) so it would be really cool to be able to search for stuff like that.

The proposed improvements in ACube 4 sound amazing - I can't wait

The "ambiguous states" supported by ACube do not seem to merely correspond to cubies with some facelets grayed. I'm not sure if masterofthebass's GUI is an ACube front end or not, but the Heise one certainly is designed to be just that, and has support for the exact same type of ambiguous states that ACube (the old version) supports. It also seems Stachu hadn't explicitly been planning on supporting swapping and twisting/flipping cubies. His response to me doesn't seem to say anything about if swapping will be supported. (By the way, Heise only supported swapping without any orientation change, regardless of which facelets were selected for the swap. That's what I considered "incorrect" about his implementation of swapping.)

As for the input format for "separation" support, I didn't have anything particular in mind, either for GUI or command operation. For command operation, perhaps "UX" for an edge or "UXX" for a corner (actual X letters, or could be a punctuation character like ^ or something) to indicate a cubie that must go into the U layer, with the assumption of possibly being combined with orientation info (@,+,-). As for GUI interface I don't even know what Stachu has in mind for displaying the existing ambiguous cubie types. Will it be like Heise, or something different? Until I know more I think it's premature to suggest something for separation support.

My GUI is a frontend written in Python that interacts with the ACube jar. Unfortunately, my method of interaction was tied into a python library that isn't very well supported, and it only works to an extent in linux environments. It uses PyGTK and Twisted, and does everything you would need from ACube (full cubestate definitions, full access to turn restrictions). It was inspired a lot by Ryan's frontend, but provided more integration and some minor improvements. If you'd like the source, I can give it, but don't expect it to be very polished

--edit--

With a little bit of fiddling, I got it to run on OS X Here's a screenshot:

masterofthebass said:

My GUI is a frontend written in Python that interacts with the ACube jar. Unfortunately, my method of interaction was tied into a python library that isn't very well supported, and it only works to an extent in linux environments. It uses PyGTK and Twisted, and does everything you would need from ACube (full cubestate definitions, full access to turn restrictions). It was inspired a lot by Ryan's frontend, but provided more integration and some minor improvements. If you'd like the source, I can give it, but don't expect it to be very polished

Click to expand...

So indeed you seemed to support the ACube ambiguous states in basically the same manner as the Heise front end. And even the same cube manipulation commands as Heise. I don't think I really care for a Python/Linux app, though.

Actually, I was using ACube the other day and was thinking of converting my own C# CubeApp program to be a front end for ACube, given the awkwardness of using the Heise front end. That was before I noticed what Stachu was working on. Now I'll probably wait until ACube4 and/or Stachu's program.

Anyway, here's what my CubeApp looks like. I guess I don't have support for "swap cubies" yet.

I plan to implement all features of acube, both current version and all future ones. I also plan to implemnt *all* of the features provided in Heise's GUI, as well as the features in CubeExplorer. With this, serious work will have to be donr to make sure the GUI isn't too crowded and noisy. Does this answer all questions?

Make it fool proof.

hao 2 fix?

ben1996123 said:

hao 2 fix?

Click to expand...

StachuK1992 said:

THIS DOES NOT YET SUPPORT AMBIGUOUSLY DEFINED CUBES

Click to expand...

As for this and more,
I'm on vacation (ending tomorrow) so I haven't made any progress.
However, I'll be working on this again starting Monday.

Cheers,
statue

Some small updates:
-cube starts off with colors filled in rather than blank.
-secret functionalities regarding incomplete cubes finally under way
-fixed a bunch of minor bugs, and reworked code

Next:
-incomplete cube and piece-swapping functionalities.

Again, let me know your thoughts.