Message #3169

From: Melinda Green <melinda@superliminal.com>
Subject: Re: [MC4D] Various issues with MC4D
Date: Mon, 17 Aug 2015 11:53:23 -0700

Hello Doug,

This is a fine place to discuss many of these thoughts though the ideal
place to start is with the project’s issues list here:
https://github.com/cutelyaware/magiccube4d/issues/. Where bugs and
feature requests exist, please add input there. In other cases, consider
creating new issues. Where there is a lot of room for design,
discussions here can be very fruitful. I’ll make some in-line comments
below. If you create or edit any of the issues, please include my
comments here in that context.

On 8/17/2015 3:20 AM, d_funny007@yahoo.com [4D_Cubing] wrote:
>
>
> MC4D Freezes when scrambling 1^4:
>
> Program freeze up when I ask it to scramble a 1^4 trivial puzzle
> ({4,3,3} 1). It hogs up CPU and won’t exit. I have to kill the
> process. Presumably this might happen with other trivial
> single-layer/length puzzles.
>

Known bug but extremely low priority. Open question as to what if
anything to signal when scrambling won’t do anything.

>
> The "Twist Speed" slider does not seem to scale with the puzzle type.
> I had to drag it WAY to the right to view things at similar speed as a
> 5^4 comparatively. Also 2^4 treats all turns as face-turns, clicking a
> corner should do a corner-turn, and then perhaps have a clickable
> placeholder in the middle of centers and middle of edges to do the
> face-turns and edge-turns (2c-moves and 3c-moves), respectively.
>
>
> Twist Speed doesn’t scale particularly well within the *same* puzzle.
> To see what I mean, try the 100-Duoprism (3 layer, not the trivial 1).
> Place the slider in the middle, and the cube-side turns are very slow
> while the prism-side turns are very fast. Taking the slider to the
> very right, and cube-side turns are painfully slow. The thing to do
> would be to scale turn speed based on how far the pieces have to
> travel, in such a way that each turn takes the same amount of time
> across all turn-types and puzzle-types/puzzle-sizes.
>
>
> When I try the Hyper-Megaminx ({5,3,3} 3) I discovered that the Twist
> Speed is correlated more with the puzzle complexity than the distance
> stickers have to travel. Even at fairly low/left settings the
> animation takes a long time. At the rightmost setting, an edge-turn
> takes around 18 seconds to animate.
>
>

Currently, twist speed controls the number of animation frames per twist
without regard to face type. Making it track the clock seems like a good
option but that can cause other problems.

>
> As an aside, this particular puzzle (the 100-Duoprism) has 104 sides,
> which means the need to discern 104 distinct colors. It is not
> practical for the human eye, no matter what facecolors.txt settings
> you override with. It is probably best to remove this puzzle from the
> menu selection all together.
>

I don’t think it hurts to have it in the menu even if it’s unsolvable
with so many faces. Note that the uncut "1" puzzles can’t be solved
either but you didn’t suggest removing those.

>
> The puzzle type is not indicated anywhere. It might make sense to put
> a check-mark or bullet-point in the menu for puzzle selection as to
> which one is currently chosen.
>

I like the general idea, though the menus are deeply nested, so it could
be difficult to find the submenu that would contain the highlighted
entry. I’d prefer to add the name to the window title or other location
that is always visible. Note that you can always click the "Invent My
Own" item and the pop-up will be populated with the symbol for the
current puzzle which is a handy, if not obvious trick.

>
> The hotkey to Solve is ctrl-T which is next to ctrl-Y for Redo. This
> spells danger! I recommend removing that hotkey all together, or
> having a pop up message asking "Are you sure?".
>

The Solve hot-key is important when experimenting with algorithms.
Perhaps a different key would be better though I’d like it to be easily
reachable with the left hand. I don’t like "Are you sure?" dialogs in
general. Users attempting non-trivial solutions need to learn to save
their progress incrementally, and to archive log files at milestones.
Unfortunately, most of us only learn the hard way.

>
> For "{3,3,3} 5" clicking on face-stickers which itself has a vertex
> touching (kissing) the edge of a side, trigger an (order-2) edge-turn
> instead of an (order-3) face-turn. This is not intuitive and deviates
> from what is expected from the flagship 3^4 puzzle controls – but
> then again so does the 2^4.
>

The 2^4 and related puzzles/faces are definitely unusual and I find them
unintuitive. I argued against including them at all but Don did all the
work so it was hard to push. But I don’t think that’s what’s happening
in this case unless I’m misunderstanding you. Edge stickers generate
edge (180 degree) twists and this puzzle seems to do that properly.

>
> Mover Counter: Performing an order-N turn N times consecutively
> increments the move count by N instead of by 0. For N>2, performing an
> order-N turn N-1 times consecutively increments the move count by N-1
> instead of by 1. In laymen’s terms, doing a 270-degree turn is
> equivalent to doing a 90-degree turn but one is counted as 3 while the
> other is counted as 1.
>

I agree this should be addressed, but it needs to be handled more
generally than that. All loops in the state graph should be removed, and
all sequential sets of moves on a single face should be combined into
one. One could even argue that non-sequential sets of moves on more than
one face which do not affect anything else should also be merged into
one twist for each such face, but then in what order? And of course all
this gets complicated when considering how undo should work in
connection with the feature. Don did an initial implementation of move
compression on saving of log files, but I think I’ve broken it.

>
> I like to set the Sticker Shrink slider to around 70% where the
> stickers just touch. In various puzzles, non-cube sides appear messed
> up – display artifacts or just bad display Z-ordering (can see
> *through* some of the surfaces of stickers and even highlight stickers
> underneath it). This may be due to rounding-errors in the engine.
>

Don’s new engine supposedly fixes all the Z-ordering issues but needs to
be integrated. This is one of the top priority items.

>
> In "Invent my own!" option, it can’t seem to do Octahedral Prism,
> which I believe is denoted "{3,4}x{}". Nor can I do an Icosahedral
> Prism, "{3,5}x{}". The Tetrahedral Prisms work well enough it could be
> added to the selection menu (at lengths 3 and up). At layers/length 3,
> it’d be nice if face-stickers at the ends of the prism would be
> clickable to re-orientate the whole puzzle – like holding down 1+2+3
> on a 3^4 and clicking an adjacent side. Trying to scramble a "{3,3}x{}
> 2" freezes up the program. If all the legal turns are allowed, that
> puzzle is nearly trivial as it takes at most 1 turn to solve – but I
> think there should be a way to flip the prism sides leading to more
> combinations.
>

This feature is experimental and therefore unsupported, but you can
still file issues against it.

>
> It’d be nice to hide certain pieces like in the MC5D program. For
> example, when grouping the core pieces on a 5x5x5x5. I would want to
> hide (or lower the opacity of) face, edge, and corner stickers.
>
>
> A "piece finder" feature would be great. A way to highlight only
> pieces having color A and color B (which would be 2c, 3c, 4c – or
> none if non-adjacent sides), and also a way to filter by the piece
> type, like only 2c and 4c pieces but not 3c. Or even to find a
> specific piece.
>
>
> A way to customize the colors of each side from within the GUI,
> instead of trying to blindly fiddle with a facecolors.txt file –
> which by the way doesn’t load if there is no logfile in use (a known bug).
>
>
> It would be nice to shift of scale the colors given in the
> facecolors.txt such that a mouse-over highlighting will actually show
> up in a different color. For example #FFFFFF (white) can’t get any
> brighter when trying to highlight it so I had to manually make it
> slightly gray. Also, highlighting orange stickers makes them appear
> identical to yellow stickers (in my settings and with my eyes at least).
>

The automatic face color generation is one of my proudest features. (I
recently published it on Stack Overflow here
<http://stackoverflow.com/a/30881059/181535>). It contains options to
restrict color brightnesses to be not too bright or dark which in this
case makes it so that lighting and highlighting have some room in which
to work. When you create your own face colors, that is up to you to do.
If we add a GUI like you suggest (good idea, BTW!), that part could be
done automatically.

Needing to worry about highlighted stickers of one face looking like
another seems like too much to worry about at any level, though the
problem would naturally go away if brightnesses are fixed at a single
level, though that may reduce the number of sufficiently distinct colors
that can be generated.

Note that with custom colors externalized into facecolors.txt, anyone
can create a stand-alone GUI program with the purpose of generating
those files, so it does not strictly need to be built into MC4D.

>
> The way the lighting works, the ‘upper’ side of a Hyper Cube puzzle
> tends appears very dim, making it hard to discern colors on that side.
> This was an issue for me while solving the 5x5x5x5.
>

Is it a problem when not using custom colors? If so, maybe the light
source needs to be moved somewhat.

>
> It would be nice to support things like Rhombic-Dodecahedral Prisms
> or Cuboctahedron Prisms. In general, allowing Schläfli extensions like
> ‘truncated’, ‘snub’, ‘rectified’, and ‘cantellated’ in addition to the
> usual ‘regular’. Notionally, it accepts ‘x’ but not ‘+’ – Having
> bipyramids and duopyramids would be nice.
>

I believe a lot of those things and more are included in the new engine.

>
> It would be nice to have a ‘play button’ instead of holding down
> ctrl-Y. I thought there was one in a previous version of the program.
> A way to instantly go back to move 0 would be good. Or even better the
> use inputs the move number to jump to.
>

I don’t recall ever supporting anything like this other than "Solve" but
I’ve wanted to do something like this from the beginning. I imagine
something like full VCR controls would make sense including looping
options for screensavers, etc. The move history supports arbitrary
bookmarking which was meant to allow some of this sort of stuff and
more. (EG fast forward/backward to the next bookmark.)

Thanks for all the thoughtful ideas!
-Melinda