Message #712

From: Klaus <klaus.weidinger@yahoo.com>
Subject: [MC4D] Re: 3^4 parity problems
Date: Tue, 20 Oct 2009 17:30:44 -0000

Well, of course it’s up to you in which way you try to use any of my suggestions. These were just thoughts about how to deal with problems that even might never evolve. Even if you don’t use any of them in the first version of the new programme I won’t be mad at you because I’m really looking forward to seeing this new programm at work ;-) And additionally I’m no speedcuber so i doubt that I will take part in many of those competitions. I think I will rather stick to fewest move solving.
Btw: What is the name of the new programme, or is it still called MC4D?

> I don’t think we’d need to hold competitions in a single location in
> order for it to be fair but it would certainly be the easiest way.

I don’t think so. Well, perhaps it would be the easiest way to prevent cheating, but it would as well ensure low attendance. I don’t now the 4D-cubing community very well, yet, but I think they are widely spread around the whole world and few would come from remote places.

> I agree with you that cheating will always be possible. I just feel a duty
> to think about it and to take measures to discourage it. I don’t see any
> way to create any sort of official speed records that are produced
> remotely but that shouldn’t stop us from letting people claim their
> private results.

Well, if you have some spare time ;-) and want to programme some web interface for user input and then run all the cubes on a central server it would be possible, but I think this is not really needed. (And of course one could hack the server ;-)

> I also like the idea of holding informal races timed
> only by the wall clock. I think that it makes good sense to include a
> timer in MC4D that solvers can use as they like in order to more easily
> measure and compare their personal, unofficial speeds.
>
> This is probably a good point to announce our intention to set up a wiki
> to let you guys maintain your own unofficial hall-of-fame for
> accomplishments and records. I still intend to maintain the current
> official list of solvers and shortest records for the 3^4, 4^4, and 5^4,
> as well as the shortest 2^4; but it will simply be too much work for me
> to do the same for the veritable zoo of new puzzles and sizes that are
> about to become available. If anyone has suggestions for how to
> administer and official HOF for these, please share your ideas. Until
> then then this will simply have to be based on the honor system.

Well, I can’t even imagine this zoo of puzzles yet, so I can’t come up with a way of maintaining the records. Well, of course I can think of the possible platonic polychora turned into puzzles, but what else can this programme do?

> Regarding your question about allowing half turns in addition to quarter
> turns: this is not a grip vs. sticker issue but it does involve the log
> files. The existing product supports half turns internally but not in
> the log file format. The new version will now support it in the log
> files as well but not yet in the UI. I had experimented with the idea of
> using the shift key to "double" the amount of twist you get when
> clicking. That actually would work fine but now with all the new puzzles
> it wouldn’t seem right to support only doubling of twist angles when
> some puzzles would benefit just as much from multiplying by 3, 4, 5,
> etc. The problem is that we can’t think of a good usable way to support
> that in the UI. This will make more sense once you’ve had a chance to
> play with the new puzzles a bit. We will then count on you guys to make
> suggestions for how we might implement that and how to compare records
> set before and after any such feature becomes available.
>
> Regarding your question about correcting past records due to changing to
> grip vs. sticker based log files: the only record that I think of that
> might need to be corrected would be the shortest 2^4. Thinking now about
> how to do that gives me an interesting thought about how to count twists
> in general. Maybe any number of consecutive twists on a given face with
> the same slice mask should only count as a single twist.

That is exactly what I meant. If you turn one side on a normal rubiks it is (generally) considered as one turn and this should hold true on every other derivation of it. Of course you are right that turns of one face with different slice masks should be considered separate turns. I didn’t even think of this but it perhaps feels most intuitive.
And from what you wrote above I conclude that I still don’t understand how a grip based system will behave. I thought it would be somehow like klicking on a cubie and then drag-and-drop it to the desired position, which would automatically include every imaginable way of turning a single face on any kind of puzzle.

Another request from me is to enable the usage of numpad keys to control the slice mask and making the numpad "," or the "0" equal to the current function of Ctrl.

Have a nice twist,
Klaus