Undo/Redo (also on the Edit menu) appear to work properly.

This is currently the bottom option on the Puzzle menu.

As one example, a full scramble looks deficient for:

{6}x{6} 6

for backward compatibility.

Melinda's thoughts:

Make initial EyeW a function of puzzle size and maybe make the slider adjust 
view scale to keep it constant?

Roice's thoughts:

We could perhaps also do this by normalizing the puzzle definition points at 
the end of build time.  This could potentially break some things though 
because there is some code that currently does things like check distances to 
face centers and what not.  It may only be the build code that is doing 
things like this though.

For uniqueness, we currently disallow the following reference click cases:
(1) Duplicate ref clicks.
(2) 3 ref clicks that are colinear
(3) ref clicks that end up being colinear with the face center.

The ability to remove these restrictions and have it make any sense seems 
to actually depend on the macro moves used, and puts extra burden on the 
user to be smart.  If the orientation is not uniquely specified, the 
program can still pick one, and leave it up to the user to make sure that 
the actual macro moves they chose are independent of the set of 
orientations specified by the reference stickers.  

This definitely feels like a "power user" kind of thing, and would require 
more implementation to handle these cases.

Fix so that building new puzzle releases memory used by previous puzzle. (by 
removing listeners?)

Summary says it all.

As Melinda said in the TODO, "yeah right!"

We should definitely have all the prisms based on platonic solids working.  
The following puzzles result in not-implemented exceptions:

{3,3}x{} 3
{3,4}x{} 3
{3,5}x{} 3

Ctrl-clicking the various stickers can have some pretty interesting effects 
on the look of the puzzle (due to changes in the 4D view).  It'd be nice if 
there was an easy way to reset to the original view.

Slicemasking seems to work correctly on this though (amazing how well it 
already works).

We need to decide what we're going to do about these slivers (filter them out 
or try to improve the slicing code).

They lead to all sort of questions (reference them in the log files? use them 
as grips? etc.)

This would require a rework of the isSolved impl.

Canceled cheats don't finish properly when restarted.

See the note in PuzzleManager.calculateNTwists()

Good puzzles to see this on are large duoprisms, e.g. {100}x{4} 3 twists are 
instantaneous.

This is totally pie in the sky, but it would be pretty neat to have a true 
stereographic projection of these puzzles.

It is not trivial at all because the sticker surfaces would become sphere 
sections, and drawing these may simply be impossible performance-wise.

I'm talking of the ctrl-click feature here.  The fact that Don did this per-
sticker is awesome!

It took me a while to figure out why it wasn't behaving quite as expected for 
stickers that were not at the centers of cells (e.g. 1C stickers).  The 
weirdness is that that projection of non-cental stickers makes them look as 
if they haven't actually moved to the "center".  This could be fixed if the 
rotation code paid attention to the shrink parameters.

Having to go to the slider each time feels too cumbersome.

This would be off by default to give current behavior.

This is not something that helps to solve the puzzles really, but it is nice 
for understanding the objects.

Besides the scales, this might also involve reversing the effects of some of 
the current sliders (e.g. twist speed).

Macro reference clicks are currently grip based vs. sticker based.

There are advantages/disadvantages to both approaches, so we might want to 
support both methods.

3C stickers do nothing, 4C seems wrong? (although maybe the behavior is 
reasonable because it allows movement that would otherwise not be possible).

I might just not be seeing this right, so I'd like other opinions on this 
one.

This may be well known, considering the History class is undergoing revision.

Super-beneficial for the bigger puzzles, and actually fully necessary when 
there are lots of colors.

We can use the gravitation3D piece finding functionality as a model.

Melinda's first attempt at this was super neat, so we should definitely try 
to get it polished enough to publish.

Fix "whichax out of range" errors

This is one disadvantage of the grip approach, but maybe I just need to turn 
off the special casing of grip-finding for these cells when reference clicks 
are done.

It is with words as with sunbeams.  The more they are condensed, the deeper 
they burn.  ~Robert Southey

It brings up the octagonal duoprism instead.

It is also not listed correctly in the UI

Fix random Exception in thread "AWT-EventQueue-0" 
java.lang.ArrayIndexOutOfBoundsException: 4042
    at GenericPipelineUtils.paintFrame(GenericPipelineUtils.java:683)

See summary.

Figure out a UI that allows for twists with "directions" that are multiples 
of 1 and -1.

The ultimate goal in the issue title is not really possible (consider 
onehundredagonal puzzle), but we can and should come up with something that 
would be a big improvement.

Maybe keep printing puzzle state data but skip over reading it and initialize 
from history data instead.

Make the view scale small and the shadows will appear to be floating above 
the horizon rather than being on the ground.

  - First just for the appropriately sized cubes and eventually for all 
puzzles.
  - Consider including and using Don's N-D solve rather than port MC4D 
version?

This would be in the macros tab.

update to 2009

Non-central 2C sticker doesn't twist as I'd expect (twists like a 3C sticker 
instead of a 2C).

Reenable "Reset to Defaults" button in the preferences panel and sync prefs 
with Viwe4D without losing puzzle state.

This is something I never liked about MC4D and avoided when doing 
Magic120Cell.

I think it might be nice to do something similar here if possible, though it 
might be a bit of work.  The key involves shrinking stickers from points on 
the boundary of the cells (vs. shrinking them from sticker centers).

When enabled, the timer can be started with the Reset button or other means. 

Klaus Weidinger suggested a refinement which might allow us to compare
macro solution with non macro solutions. (See
http://games.groups.yahoo.com/group/4D_Cubing/message/706) The new option
would time the twisting phase of any initial macros built at the start
might be useful too and then when a macro is applied while solving, we
increment the solution timer by the amount twist time used when defining
that macro.

The only version of the {5,3,3} I could get to come up at first was the one 
with one per side.  I was able to get all of them to come up by running with 
custom memory parameters, like this:

java -Xms128m -Xmx256m -jar mc4d.jar

Maybe we can get these settings into the jar file though so users don't have 
to deal with this.

Warn user of overwrite after switching puzzle type and saving (so we don't 
have the nightmare I had with that M120C user).

try for example:

{3,3,3} 3
{3,3,3} 5
{3,3,3} 7
etc.

{3,3,3} 4 and other even puzzles work well.

* move ctrl-click rotation code to the rotation handler.
* Update MacroManager names/notes to reflect the fact that it is grip based 
instead of sticker based (assuming we keep it that way).
* How much of Math4d is dead code?  Maybe get rid of this.
* add VecMath.copymat calls where some matrices are being copied manually 
now.

Since they are the same, I question whether there should be separate UI 
options, e.g.

{5}x{4} 2.5, {5}x{4} 3
{10}x{10} 2.5, {10}x{10} 3

  - try embedding the full app too (hey, we can dream!), and
  - extend the PropertyManager to access applet parameters or add them via 
the applet init.

What we even want to do needs to be figured out.

This affects a number of puzzles, which we're not planning to display in the 
4.0 beta.

Don's humor is awesome (invention rejection form letter :D)

However, it is possible to trick this feature.  I tricked it with {4,3,3}x{3} 
3 (a 6d puzzle), and it ran out of heap space.  We might want to more 
severely limit the forms it accepts.