Thread: "Various issues with MC4D"

--------------020608020103070300080506
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hello Doug,

This is a fine place to discuss many of these thoughts though the ideal=20
place to start is with the project's issues list here:=20
https://github.com/cutelyaware/magiccube4d/issues/. Where bugs and=20
feature requests exist, please add input there. In other cases, consider=20
creating new issues. Where there is a lot of room for design,=20
discussions here can be very fruitful. I'll make some in-line comments=20
below. If you create or edit any of the issues, please include my=20
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=20
> ({4,3,3} 1). It hogs up CPU and won't exit. I have to kill the=20
> process. Presumably this might happen with other trivial=20
> single-layer/length puzzles.
>

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

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

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

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

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

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

I like the general idea, though the menus are deeply nested, so it could=20
be difficult to find the submenu that would contain the highlighted=20
entry. I'd prefer to add the name to the window title or other location=20
that is always visible. Note that you can always click the "Invent My=20
Own" item and the pop-up will be populated with the symbol for the=20
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=20
> spells danger! I recommend removing that hotkey all together, or=20
> having a pop up message asking "Are you sure?".
>

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

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

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


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

I agree this should be addressed, but it needs to be handled more=20
generally than that. All loops in the state graph should be removed, and=20
all sequential sets of moves on a single face should be combined into=20
one. One could even argue that non-sequential sets of moves on more than=20
one face which do not affect anything else should also be merged into=20
one twist for each such face, but then in what order? And of course all=20
this gets complicated when considering how undo should work in=20
connection with the feature. Don did an initial implementation of move=20
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=20
> stickers just touch. In various puzzles, non-cube sides appear messed=20
> up -- display artifacts or just bad display Z-ordering (can see=20
> *through* some of the surfaces of stickers and even highlight stickers=20
> 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=20
be integrated. This is one of the top priority items.

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

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

>
> It'd be nice to hide certain pieces like in the MC5D program. For=20
> example, when grouping the core pieces on a 5x5x5x5. I would want to=20
> hide (or lower the opacity of) face, edge, and corner stickers.
>
>
> A "piece finder" feature would be great. A way to highlight only=20
> pieces having color A and color B (which would be 2c, 3c, 4c -- or=20
> none if non-adjacent sides), and also a way to filter by the piece=20
> type, like only 2c and 4c pieces but not 3c. Or even to find a=20
> specific piece.
>
>
> A way to customize the colors of each side from within the GUI,=20
> instead of trying to blindly fiddle with a facecolors.txt file --=20
> 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=20
> facecolors.txt such that a mouse-over highlighting will actually show=20
> up in a different color. For example #FFFFFF (white) can't get any=20
> brighter when trying to highlight it so I had to manually make it=20
> slightly gray. Also, highlighting orange stickers makes them appear=20
> 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=20
recently published it on Stack Overflow here=20
). It contains options to=20
restrict color brightnesses to be not too bright or dark which in this=20
case makes it so that lighting and highlighting have some room in which=20
to work. When you create your own face colors, that is up to you to do.=20
If we add a GUI like you suggest (good idea, BTW!), that part could be=20
done automatically.

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

Note that with custom colors externalized into facecolors.txt, anyone=20
can create a stand-alone GUI program with the purpose of generating=20
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=20
> tends appears very dim, making it hard to discern colors on that side.=20
> This was an issue for me while solving the 5x5x5x5.
>

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

>
> It would be nice to support things like Rhombic-Dodecahedral Prisms=20
> or Cuboctahedron Prisms. In general, allowing Schl=C3=A4fli extensions li=
ke=20
> 'truncated', 'snub', 'rectified', and 'cantellated' in addition to the=20
> usual 'regular'. Notionally, it accepts 'x' but not '+' -- Having=20
> 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=20
> ctrl-Y. I thought there was one in a previous version of the program.=20
> A way to instantly go back to move 0 would be good. Or even better the=20
> use inputs the move number to jump to.
>

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

Thanks for all the thoughtful ideas!
-Melinda

--------------020608020103070300080506
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable



">


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:
re/magiccube4d/issues/">https://github.com/cutelyaware/magiccube4d/issues/<=
/a>. 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.

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.

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.<=
/p>

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.

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.>

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.

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?".

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.

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 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.

<=
br>

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.

It'd be nice to hide certain pieces like in the MC5D
program. For example, when grouping the core pieces=C2=A0<=
span
style=3D"word-spacing:normal;line-height:1.25;">on a 5x5x5x5.an> style=3D"word-spacing:normal;line-height:1.25;">=C2=A0I would wan=
t 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).