Wonderful, so efficient! Almost two years ago, back on page 16, I said I hoped to figure out a way of checking the orientation of the 1.2.7-1.2.9 corners using pencil and paper, but I never found a way and I gave up.

In the first stage we could solve the first 7 corners intuitively instead of 8 -- for example, all of the "1" corners in your diagram and two of the "3" corners next to each other -- and then if after checking the orientation using your method we need to make a move, we could move the "2" corner that does not disturb any of the 7 solved corners.

Yeah I was thinking along the same lines. The trouble with fixing the parity as step 1 is that it mostly eliminates intuitive solving. You have too keep the total twist constant after the fix which mostly means the use of commutators only. If you solve the first 1/3rd or so of the corners intuitively and then count the twist, you might be able to get the best of both techniques.

Remember though, this fix is 1 moves versus 24 for the other. If it costs you more than 23 moves to maintain the twist while solving the rest of the corners then it is a net loss. I hope to give 1.2.9 a go in a week or two and then I'll have a better idea of how hard it is...

It sure is nice to have an easy algorithm for counting total twist though!

The feeling is mutual. To me, it is stunning that you could figure out that 1.2.2 routine in your head. When Stefan first posted here and I saw he was Agamemnon, it felt to me like the words "The Fellowship of Gelatinbrain" had hovered over my monitor for a few seconds!

Yeah I wish I could offer more competition on the fewest moves records but I'm lacking fundamental basic skills such as F2L techniques and such. I also wish Elwyn weren't so busy these days since seeing his revolutionary reduction tricks are great to read about. We now have three solvers (excluding Michael) that like competing with move counts. I would like to, too, but I have a lot of catching up to do. I enjoy being able to contribute technique/solve order ideas and commutator development though

I don't really like mystery so I'll describe my 1.2.x ideas...

As I said when I posted the 1.2.2 twist-parity fix, I was thinking about the Circle FTO and the center orientation on it. The way I fix orientations on things like the Pyraminx and 1.2.1 is a simple [X, Y, X', Y]x2 conjugate sequence. I figured this sequence out through a bit of intuition and a lot of luck about 1.5 years ago when I first got a real Pyraminx.

I'm sure you all know the sequence and use it or some variation of it. It's pretty easy to find so I think everyone must "discover" it. The way it works is by using one vertex twist as scratch space while an adjacent face is spun around. The end result is a 3-cycle of the edge pieces around a corner. If you twist the corner and those edge pieces once more you put the edges back where they were originally but leave an excess twist in a corner.

In trying to solve the circle FTO I spent a very long time trying to make a pure center orientation twist that would not cycle the corners, edges, or triangles of a face. I came really close but I never could get it just right.

As applied to 1.2.1, you'd pick two adjacent vetexes, label them A and B:Then obviously they have a perfect overlap where 1/3rd of the pieces around A exactly overlap with B:So if you apply the sequence [B, A, B', A]x2 you end up with:

This sequence as applied to the FTO 3-cycles 3 edge pieces and 3 face pieces:You can't see it but the red triangle pieces were also cycled the same direction as the edges.

I bring this up though because I realized that the what makes a perfect orientation parity routine of the form [X, Y, X', Y]x2 is when one and only one of each piece type is spun around when you twist the Y face. I could not figure out how to meet these conditions on the Circe FTO although I'm pretty sure with more work I can figure something out.

The principle is roughly:
* Pieces that are toggled back and forth in B don't move
* Any piece that doesn't overlap between A and B 3-cycles
* There is an excess twist in A (mod 3)
* If exactly one of each type of piece around A overlaps with B the sequences will be pure

A much easier puzzle for me to picture in my head though is 1.2.1 and 1.2.2 so at some point, I switched from thinking about the FTO to thinking about 1.2.2. I reasoned that if I could figure out a principle for doing it on 1.2.2 I should be able to adapt the same principle to the FTO.

The trouble with 1.2.2 and the reason why [X, Y, X', Y]x2 doesn't work on 1.2.2 is that it is that the cuts are just deep enough that when you spin X it moves the corner on Y that's supposed to be twisted and when you spin Y it moves the corner on X that's supposed to stay in place.

I reasoned though that if you pick an A and a B vertex on 1.2.1, the mechanism that keeps all the pieces around B clean is that B toggles back and forth with B ... B' ... B ... B' and so on. Pieces that are moved are put right back. So, I should be able to apply this idea to the the A corner that gets moved out of place by B by just picking a C vertex and toggling it back and forth. Then, to solve the B vertex being moved by A I could just pick a D vertex that would toggle back and forth. This should prevent any net-changes in the overlapping pieces and create a nice 3-cycle in the unmasked pieces and therefore an excess twist in the A vertex.

I thought about this some but I couldn't picture the whole sequence. The principles seemed sound though so I got up and sat down at the applet to figure out if it would work.

I worked on just A B and C first to get the saving of the A vertex working. Then I added D to get the saving of the B vertex working:Which ends up having the nice effect of cycling these pieces:Notice that if those pieces get 3-cycled while the A vertex is being twisted the net effect will be a pure orientation parity fix.

I couldn't follow all of this through in my head. I came up with the principles and how to overcome the problems in my head. I came up with the actual implementation mechanics on the applet.

The reason this sequence isn't pure on 1.2.3 is that the deeper cuts cause more pieces to be moved that need to be masked off. Unfortunately the masking that I used on 1.2.2 works for corners and the wide triangles right next to the corners but it doesn't work for the centers and there are extra narrow-triangles that need to be masked too. The good news though is that the saving/masking principle that I applied to 1.2.2 will work for corners of any cut depth. That's why by spreading out the A, B, C, and D vertexes on 1.2.9 you were able to get it clean for the corners even though it made a mess of everything else.

Although I've kinda taken the magic out of the sequence, hopefully my approach here is interesting or even a bit useful.

I should mention that Doug had to know about this idea too since his 2.2.3 parity fix challenge uses an idea quite similar, but so much more sophisticated and beautiful. I figured out, mod 3, that moving 1 piece of each type can create a pure cycle. Doug managed to figure out, mod 5, how to handle moving 1 of some pieces and 2 of others in a really genius way. Doug also didn't need to mask off the vertex and managed to get it to move around in the cycle and pop back in place just at the right moment.

As far as I can see, nobody has responded to your post, but I have the very same problem.
It happens on two different Computers running Windows 7 / x64. I've installed the 32-bit and 64bit version of JRE 6.21 (the most recent Java Runtime system). Fortunately, I've still access to yet another computer running Vista /32 bit and there it runs without problem.
APJ, what kind of system are you running?
@gelatinbread: Any idea, what I could try?

There may be a problem with the native JOGL libraries for Windows on x86_64. I have a copy of the applet only for testing that I have configured the JOGL JNLP files to point to the latest JOGL release. There are problems with doing this in production but it works well to test. You should clear your Java and browser cache and then navigate to http://noh.ucsd.edu/~bmenrigh/gb/gb_mirror_bleeding_edge.htm. Also, see this post on how to clear the Java cache.

I think you were trying to say Gelatinbrain is the greatest thing since sliced bread. I agree!

Yeah, nice typo that
I've tried clearing the Java cache und going to your web address. No Java applet has started.
I believe that there must be a real serious problem on Windows 7 / x64.
The second computer I have problems with, has been newly installed.

Since a few days I've also been running Windows 7 x64 and I also get a white area where the puzzle should be (in Google Chrome, that is). Thankfully, there still is Windows XP mode.

I'm running Windows 7 Home Premium, XP mode is not on obvious choice on this version.

If it occurs only on Windows 7/x64, probably it's a video card driver problem, as Julian reported on page 33. Please download and install the latest version of your video card driver.
Maybe for me too, it's time to get the Windows 7, just for troubleshooting...

I'll try it out when I get home so I can try it with windows7.

I have installed the latest drivers and the second computer is completely new, delivered last Wednesday with the newest drivers and all.
As this is happening on different computers (my two and TomZ's), I do not believe that it is likely a driver problem.
I have tried both the Java applet started via IE/Mozilla Firefox and a local .exe. Nothing has worked.

Maybe the driver bundled in the offical package doesn't support penGL(to promote DirectX ). Better get the latest version from your video card vendor's site or from the MS site.

So far, I can think of 4 possibilities.

1. 64-bits mode problem
I don't have a 64-bits Windows. But there must be a switch to change 64/32 mode,
probably on the control panel or or maybe it depends on each application.

2. OpenGL problem
Do you have other OpenGL games or graphic softwares? Do these work?

3. JOGL problem
Does this applet work ?

4. JAVA problem(cache or security)
if you get "Error: Class not found:",
it's probably a browser cache problem. The cache is not completely cleared.
If you see a blank window, the security option on the JAVA control panel
is not correct. Open JAVA control panel (advanced->security->mixed code),
and check the second option(hide warning and execute with security).

Sorry for all those technical jargons. I will later put all of these together into a FAQ.

I've tried (after clearing the Java cache again) the JOGL test above.
This is the error message I've got: Error: Class not found: demos.applets.GearsApplet
I've tried IE 32bit, IE 64 bit, Mozilla Firefox.
Probably a general problem with JOGL on Windows7 x64?
I've seen several problem reports concerning Window7 x64 and JOGL via Google, but no clear resolution, so far.

1) You can't switch from a 32 bits OS to 64 bits easily. You would need to do a complete new installation, not to mention when you buy Windows you actually need to choose between 32/64 and you can't switch after (so you'd need to buy a new Windows license).

2) Yes, I tried the spheres demo from http://magnum.dimajix.de/download/demos.shtml and it works perfectly.

3) I get: "Error: Class not found: demos.applets.GearsApplet"

4) I've cleared my cache and changed the security settings but it hasn't fixed anything.

Unlike Konrad, the windows executable works fine for me. The downloadable gelatinbrain also works fine. However, neither IE, FF nor Chrome will render the online versions.

Quite correct. I could get a virtual machine and install on top of that a Windows XP SP3. But I would need a license for Windows XP I do not have.Same for me!Same for me!
I've dowloaded the Gelatinbrain V1.1 executable. When I start it, nothing visible happens. This is the error message I could find in the Eventlog (Sorry for the German, but it is a German W7 ):

EDIT: bmenrigh is trying to help me and we had contact via PM. I've produced some network traces as he had suggested. Let's see if bmenrigh can find something unusual.

"Protokollname: Application
Quelle: Application Error
Datum: 26.09.2010 14:01:23
Ereignis-ID: 1000
Aufgabenkategorie:(100)
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: AmiloPi3560
Beschreibung:
Name der fehlerhaften Anwendung: MagicPolyhedra.exe, Version: 1.0.0.1, Zeitstempel: 0x4c8feda6
Name des fehlerhaften Moduls: unknown, Version: 0.0.0.0, Zeitstempel: 0x00000000
Ausnahmecode: 0xc0000005
Fehleroffset: 0x00010053
ID des fehlerhaften Prozesses: 0x1724
Startzeit der fehlerhaften Anwendung: 0x01cb5d728a486c41
Pfad der fehlerhaften Anwendung: C:\Users\mchksass\Documents\install\GelatinBrain\MagicPolyhedraExe v1.1\MagicPolyhedra.exe
Pfad des fehlerhaften Moduls: unknown
Berichtskennung: c80a6383-c965-11df-8fd9-000df076f88f
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2010-09-26T12:01:23.000000000Z" />
<EventRecordID>19267</EventRecordID>
<Channel>Application</Channel>
<Computer>AmiloPi3560</Computer>
<Security />
</System>
<EventData>
<Data>MagicPolyhedra.exe</Data>
<Data>1.0.0.1</Data>
<Data>4c8feda6</Data>
<Data>unknown</Data>
<Data>0.0.0.0</Data>
<Data>00000000</Data>
<Data>c0000005</Data>
<Data>00010053</Data>
<Data>1724</Data>
<Data>01cb5d728a486c41</Data>
<Data>C:\Users\mchksass\Documents\install\GelatinBrain\MagicPolyhedraExe v1.1\MagicPolyhedra.exe</Data>
<Data>unknown</Data>
<Data>c80a6383-c965-11df-8fd9-000df076f88f</Data>
</EventData>
</Event>"

EDIT: bmenrigh is trying to help me and we had contact via PM. I've produced some network traces as he had suggested. Let's see if bmenrigh can find something unusual.

3.4.24 Solution Outline



Stage 1: The bigger circle pieces come in groups of 3, each associated with a 2x2x2 corner. Solve them like a 2x2x2, making a single Skewb move if faced with a single twisted group.

Stage 2: The smaller circle pieces come in groups of 4, each associated with one of the 24 Skewb cut lines on the faces. Their logical location is right on the border between the bitten pieces and the corners. As they occupy zero area in their logical locations, they can only be seen as groups of 4 small circle pieces spilling out elsewhere. These piece groups can be solved with ((3,1),1) = (8,1) commutators, where the 3 is made of distant corner and face moves back and forth.

Stage 3: Solve the corners with ((3,1),1) = (8,1) commutators. The sequence of 3 in the (3,1) is exactly the same as with stage 2.

Stage 4: Solve the bitten pieces pure with (1+(4,1)+1,1) = (12,1) commutators. The (4,1) is a Skewb algo to twist two corners.


As a guide, my solve using this method took 42 + 302 + 68 + 274 = 686 moves.

Updated hypothesis:

If one solves all of the sliced Gelatinbrain polyhedra entirely with (x-or-less, 1) commutators and setup moves, where the 1 can be a regular move or a slice move, x is 8 or smaller for all puzzles except:

x = 9 or 10
1.1.35x, 3.3.7, 3.3.10, 3.3.11, 3.5.1, 4.3.3

x = 11 or 12
1.4.3x, 1.4.7x, 2.3.1, 3.3.6, 3.4.24, 4.3.4

Additions to my previous lists are in bold. I have removed 1.2.9 and 2.1.5 because I now know they have x<=7, and I have removed 3.6.5 and 4.7.2 because I now know they have x<=8.

By the way, x=4 for 3.3.12, in case that encourages anyone else to give it a try!

Many thanks for your excellent explanation. Seeing your 1.2.1_twist.png screenshot was a moment; I also would not have noticed the connection with the FTO if you had not pointed it out.

I'm myself really glad to be here, to share insights with some guys.
I have solved the 2.1.5 yesterday, and my move count came down to 973 from 2608. I just did it the way of Julians 1.2.9 solve, wich he explained on the previous page, thanks to Julian again. The main difference to my approach is, that some move-sequences are much shorter than my own. Now I know, that such short move-sequences are possible. That I mean with sharing insights. There may be some things that I can tell you here, some of my techniques. Let's see.
Thank you Brandon for explaining your 1.2.2 corner-orientation-parity-fix. This time I understood more of it. Yes it takes some mystic out of it, but it gives new power, to continue, and it is a good thing, that you did it.

I used sometimes a different method when I played on time or on move counts. When I played on time, I solved only one piece at once so that I could remember the setup moves, without writing them.

Stefan.

And then on some puzzles somehow you get a move record and a speed record (ignoring macro solves) . I tried pretty hard last night to beat your 1.2.11 move count and failed. Most of my extra moves were in the wide-triangle/corner-triangle pieces. It wasn't until the last dozen or so that I discovered easier+fewer setups to save moves and time. By that time I didn't want to undo an hour of work. That cost me about 100 moves. What hurts the most though is that you got your record an hour faster than my crappy solve.

If I would say, it was one and the same solve I would cheat. I wanted to tell you that. It was not always one and the same solve.
Here is another commutator visualization.

Stefan

Hopefully we aren't misunderstanding each other I wouldn't accuse you of cheating; you're a great solver! With only one day of resolution it's hard to tell if the fastest time and fewest moves record are the same solve. I especially wonder with some of Michael's amazing times and move counts if they were the same solve.

Keep puzzling

My "even crappier" 1.2.11 solve (no offense taken ) took me around the same time as you, because it included walking 15 minutes across town to see a movie in the middle! The small pieces of 2.1.1-2.1.3, 1.2.3 and 1.2.11 are tricky to cycle when you aren't used to them. The more you solve them, the easier it is to fairly quickly see how to set them up.

That's good to know. I must have missunderstood you a bit.

Yes and now you must solve it again, for you know a real better way, that will even break the record, and don't worry about your time, and maybe you get the best movecount. And when you have the move-count-record, you can try to get a better time. I have done it so. My first solve was only to proof to me, that I can solve the puzzle at all. When I had won, and solved the puzzle, I started to enhance my method, to get a better movecount or a better time. I remember at my first super-pentultimate solve I used a move-sequence with 210 moves, but I solved it, and it was right, not to care for the move-count, or I would have not solved it at all. If I know a better way to solve a puzzle, I solve it again.



Wich movie did you see?
Yes, for the small pieces you must know good setups. I can now solve them like a sleepwalker, even two at once, without writing. But this is only true for 2.1.1-2.1.3.

I got a problem with Gelarin Brain, it wont let me play with any of the puzzles..
every time I try to click on one, it just show me a white screen with the "Usage" below but the puzzle it self is not working.

can anyone tell me what can I do to fix it?

I'm pretty sure a Java troubleshooting FAQ is in the works. In short, make sure you have the latest version of Java installed and that you've cleared your Java cache and browser cache.

If that doesn't work, you can run the JOGL+Java test at https://jogl-demos.dev.java.net/applettest.html. If you can get that applet working then you should be able to get Gelatinbrain's applet working.

This post discusses how to clear you Java cache. You also need to delete the ".jnlp-applet/" folder in your home directory. On Windows that could be in c:\Documents and Settings\youruser or in c:\Users\youruser

If you can't get that working, PM me and I'll do my best to help.

I'm having a similar situation right now actually, with 1.1.39; I have come up with all the commutators I would need to solve it, except some of them have the most ridiculous lengths. Two of them require more than 150 moves. I've calculated that to solve just one of the pieces types I would have to use approximately 2000-3000 moves. I would most definitely be able to finish a solve, but I think I should be able to manipulate my commutators so that they'll be shorter and more efficient (though that's not something I'm good at). But I found what you said to be rather "wise". The lengths of the sequences doesn't really matter for the first solve. I mean, the most basic thing is for me to prove to myself that I can actually solve it. I can worry about move counts later. That's some good advise right there Though I think in this case, I'll be able to come up with some better ones without too much trouble.

First of all I want to say Thanks for the help, BUT nothing is working for me..
I got the latest Java version, I have cleared my Java cache and deleted the "jnlp-applet" folder.

I will pm you for me help =) Thanks.

Yikes, you must have some complex routines! I was quite pleased with myself when I solved 1.1.39 but remembering back to how I did it now, it wasn't an elegant solve at all. I'm curious though, since I can't imagine what a 100+ move routine would look like -- do you know about ctrl+click? If you know about ctrl+click could you post your routine and some text describing what it does? I'd like to see the cycles you've built your commutators off of.

I had help from bmenrigh as well. Thanks to him!
I'm running Windows 7 x64 and had installed Java 6.21 32bit AND 64bit.
Neither of them worked! (Neither Gelatinbrain nor other test applets in a browser)
I have deinstalled all Java software and reinstalled Java 64. I have tested with Internet Explorer 64 several test applets (including bmenrigh's mirror page). This worked, still Gelatinbrain had the same problem as before.
I get a security warning in case of the test applets, but when I ignore it, they run. (e.g. the Gears applet mentioned above). Gelatinbrain shows nothing and no error messages or security warnings.

After this partial success with Java 64bit, I've reinstalled Java 32 and now Gelatinbrain works with 32 bit!
(The 64bit situation is the same: Nothing)

Very strange, I know. But my conclusion is: It may help deinstalling Java completely and reinstalling afterwards.

1.1.10 solution-construction-log
first the color scheme with letter-notation.

Now the piece types:
-corner (20)
-edge (30)
-edge-face (60)
-corner-face (60)
-edge-corner (60)
now let's see how to solve the piece-types:
-corners: (3,1)found , pure effect: solve last
-edges combine with edge-corners or with edge-faces (reduction)
-corner-faces (3,1)found , scrambles edge-faces, after that any face moves possible
-edge-corners (3,1)found , cycles 3 edge-edgecorner pairs to edgecorners, it's pure

Megaminx-reduction?
face-complete, edge-complete possible with the found move-sequences
trouble with edges (twist or parity)?: both not

solution-construction finished

now prove the solve
first practise:
-corner-face: (3-slice, 1-face) easy
-edge-face: (3-slice, 1-face) easy
edge-corner: ((slice,face,slice),face)

ok scramble
solve:
1. all white corner-faces 018 1:30
2. all light-blue cf 039 3:00
3. brown 059 5:00
4. blue 072 5:30
5. lilac 095 6:30
6. dark green - idea, stop - solve the edge-faces at the same time together with the corner-faces??
-> Elwyn's Gigaminx-solution !!

scramble, start again,
white faces: 047 5:30
light-blue f: 085 9:30
brown f: 128 13:30
blue f: 170 16:30
lilac f: 209 19:00
dark-green 251 21:30
front-side faces complete
now the edges of the front side
white edges complete and arranged 330 27:30
adjacent edges and white corners 439 42:00
face-complete 6 backside faces: 644 57:00
complete last edges : I'm tired, not today, stop.

next day:
start new
faces front-side 261 12:00
white edges: 334 16:30
next 5 edges and 5 corners 447 24:00
last 6 faces 658 50:00 with breakfast
last edges complete 942 1:06:51
finished 1112 1:13:51
8th in fewest moves
20th in time

I went a way, after a while I saw a better way, and started new. Would I have got the idea else?

sorry for the broken english
Stefan

Elwyns Gigaminx Solution

1.1.37 Outline
Recently I solved 1.1.37 and for once my move count didn't give me the lowest ranking. And I also thought it was a rather fun puzzle to solve. Therefore I thought I'd share my method:

1. Solve corners like on 1.1.12
2. Solve the center pieces using a simple (3,1) commutator to 3-cycle the pieces

I used this one:
r' u' r U' r' u r U

It's both easy to discover and doesn't use to many moves. Oh, in case it wasn't clear the lower cased letters represent slice moves.

Also I would like to mention that I did not try to solve as efficiently as possible, so I believe that you could get a much lower move count than my 900 move solve. Not sure if you could get a record with this, though

It is really worth looking for short commutators to solve 1.1.39. Brandon has asked the key question: do you know that ctrl-click makes sliced 1.1.6 moves? If you include ctrl-click moves in the mix, it is possible to solve all of the pieces except for the corners with (3,1) commutators. The edges can be cycled very non-pure like a Pyraminx Crystal; the kite pieces non-pure (small triangles are moved); and the rest pure. So the two main choices are:

1) Solve the corners and edges like a Pyraminx Crystal, then cycle the kite pieces, then cycle the other pieces. This is simple because we use complete (3,1) commutators and all the pieces are solved into position.

2) Reduce the puzzle to a Pyraminx Crystal, then solve the Pyraminx Crystal at the end. The (3,1) commutator for the kites can be shortened to 5 moves because we don't care about Pyraminx Crystal pieces being moved around. The other commutators can't be shortened, but we save moves anyway because if we use only Pyraminx Crystal moves to set up pieces we don't need to undo any of the setup moves; or, if a setup sequence at least starts with Pyraminx Crystal moves, we don't need to undo those moves, just the others. This is more efficient than method 1) above but is more confusing visually.

My estimate is that 2000 moves would be a good count for method 1, and 1600 moves would be a good count for method 2, assuming we are cycling 2-3 pieces at a time as often as possible.

Yes, I do know about the ctrl+click slice. First off: I don't really know what the meaning of pure and non-pure sequences are. But my guess is that a cycle that's pure will only more say 3 pieces at a time, no matter the set-up moves you include first. Feel free to correct me on this, as I'm really unsure.

Also, I have had no problem coming up with clean 3-cycles for all the pieces except for the tiny triangle pieces and the trapezoid pieces. However I do know how to 3-cycle these in "couples": 3 trapezoids and 3 tiny triangles. To do this I use all three move types: regular, shift+slice and ctrl+slice. Also I have a few other 3-cycles for these pieces, but: when I include some random set-up moves these pieces are no longer the only ones that gets cycled. Which I'm not happy about and therefore I don't want to solve it yet. I feel I'm getting close to understanding how to come up with better cycles, but for now I may be lacking the basic understanding of the puzzle, and also the time I need to sit down and actually do it (uni is killing me!).

I should also mention that I plan on solving this with option number two firstly. But don't count on seeing a sub-2000 solve from me just yet (or possibly never). Though I usually don't like going for reduction in cases like this.

That's right. With a pure cycle, position A moves to position B moves to position C moves to position A, with no other visible effect on the puzzle regardless of the scramble or the setups.

1.1.39 hints:

Pure cycle for the trapezoids: try making 3 shift-click moves using two non-adjacent faces, and then look carefully for a single swapped trapezoid somewhere in a ctrl-click slice.

Pure cycle for the small triangles: try making 3 moves using non-adjacent faces -- shift-click, regular move, shift-click -- and then look carefully for a single swapped small triangle somewhere in a ctrl-click slice.

I solved 1.2.6!

I solved the centers, then small triangles, then large ones.

I got a certificate and dont know what to do with it:

57c355e46bcd59a778abe38d073ba397
0d57b4920d37a69e61c9c27789ec135e
a1b6436691c2236985e30bf826a14c7a
86f20db946738ce916d32c6798c73181



-Mark-

Thanks for the hints, Julian; I feel I now have a vague feeling of how to come up with those commutators. I tried a bit last night, but with no success yet. However - once I get an evening without work and uni, 1.1.39 is going down! Also, you confirmed my theory on what a pure cycle is, which means I have a bunch of sequences already, but non of them are pure yet.

Also, it seems my solves are not being registered onto the record lists lately. A couple of days ago I did some solves of 1.1.12 that should have made the list, but they're not there. Sadly, I didn't take any screen photo, so I have no proof of this. But I have of the other solves I'v done these past days:


For some reason I see others have gotten their solves registered, but not mine. Anybody else have this problem? Gelatinbrain, if it's not any trouble I'd really like for them to be added

I finally got around to 1.1.42. The method is similar to my, as yet untested, 1.1.17 method but i'll outline it anyway.

1.1.42 reduction to kilominx

1. The hard part, group all the two colour pieces into groups of three around a corner. It's hard to see what you're doing so this is one of those "keep your pyraminx crystal or megaminx on the desk for a colour scheme reference" times. I used intuition at first then switched to an easy (1,1) commutator that can be shortened to just 3 moves. I forgot to take a screen shot of this which is annoying as it's the hardest part to understand.

2. There are two types of parity, I know because i got both two corners swapped and one corner twisted. Both are fixable by 3 cycling the two colour pieces around. Also for the single corner twisted you could use Stefan's method to look for it but i used the old "solve kilominx and then undo method out of laziness but once i found i had it fixing took 14 moves. All up this stage took 120 moves.

3. Match the small equilateral triangles to the larger isosceles ones to form kites, an easy (3,1) 3 cycle that can be reduced to 5 moves. it should now look like this

4. Place these kites in the correct spots on the corners to make it look like this using another simple (3,1) 3 cycle that can be reduced to 7 moves.

5. Who wants to guess the last step

It took me 529 moves and far too long (03:38:35) as i had a break every 20 minutes or so. I sure hope the record appears on the board.Thought it was worth adding that step 3 and 4 could be done the other way around and that julian used a similar method but cycled all the pieces instead of reduction and that took 860 moves so reduction is definitely saving moves. It does add two types of parity and a lot of confusion though. Next up 1.1.17 and hopefully (but it's going to be very difficult) a sub 1000 solve.Only the one you use last has to be pure but i suppose you knew that already.

It's always nice when you are solving and something just clicks and you think of a better way.
Also if you didn't notice at the bottom of my gigaminx solution i said

Yes, a solve of mine from early 30/09 never appeared but a later one did. (Maybe a Belgacom messaging blip?) Gelatinbrain once told us that the rankings board is updated by an hourly task running on his PC. So whenever he takes a holiday break, the board doesn't update again until he returns and fires up his PC. I submitted a 4.6.1 solve today in my own name and I have also just submitted a 3.2.8 solve in the name Test out of curiosity.

I tried myself, and got this error.

Maybe the server(or an intermediate node) is just temporary overpowerd? I don't know...
I'm sure Brandon knows much better than I of these things.

I submitted a 5 hour 21 minute solve of 4.7.2 a few minutes ago. I'll make a solution post with a solved screenshot later this evening. I see that my 3.2.8 "Test" went through this morning but my 4.6.1 from late last night didn't.

You supposed correctly Though I feel like finding pure cycles for both pieces is more useful practice than to use those easy-to-find commutators I already know and solve one piece type non-pure. I'm on a mission to get better at finding efficient cycles Also, Elwyn, you'll be glad to see (if you haven't already) that your 1.1.42 solve has been added to the record list! I enjoyed reading your solution method, as 1.1.42 is definitely on my to-solve list. After reading your post, I also decided to solve 3.2.8, which was really easy, and noticed that your test solve got submitted. Hopefully mine will too, as I got a somewhat decent move count on it.

I made a test applet which may resolve the famous "classnotfound" error.
It's a little tricky. Before testing, you need to prepare as follows.

Make a temporary folder, for example, "C:\genatinbrain" and download there following files.
http://download.java.net/media/gluegen/ ... s-i586.jar
http://download.java.net/media/jogl/jsr ... s-i586.jar
http://download.java.net/media/jogl/jsr ... s-i586.jar

Go to [control panel]->[system]->[environment variables]

Add the path of downloaded jar files to the the end of the environment variable "classpath"


I hope this works.

4.7.2 Solution



Stages 1 & 2: Solve the corners intuitively while solving some centers at the same time. Finish the centers with (3,1) commutators. From this point the rest of the solution is setups and cycling with commutators. Note that pieces 7,8, and 10 come in two sets which do not mix and must be solved separately. (If you know an algo to cycle pieces of one set, the mirror image of that algo will cycle pieces of the other set.) Example algos for the trickier commutators are in invisible ink; drag your mouse across to highlight.
Stage 3: (1,1)
Stage 4: (5,1) (B' LUF' D LUF B, LUF)
Stage 5: (6,1) (FUR (LUF', DR) FUR', F)
Stage 6: (5,1) (FL R F' R' FL, UR)
Stage 7: (7,1) (BD FU BR UR BR FU BD, R)
Stage 8: (8,1) (DR FU (FUR', DL) FU DR, FL)
Stage 9: (1,1)
Stage 10: (6,1) (DL (FU, D) DL, F or FR)

After stage 5:


After stage 8:


Solved:

My solves are still not showing up on the list. I see Julian's 4.7.2 (which was a really impressive solve, Julian!) has already been successfully added. So maybe the trouble is with my computer? I just changed to a Mac, if that may have anything to do with it?

Congratulations. Your move sequences are shorter than mine. I will look at it in more detail later. I'm curious. Maybe I can learn how you find that short move sequences. I didn't think, that my solution was ideal. One can really count with new records. My solution was shorter in moves than Doug Cubes and schumas. And yours is now the shortest.

I noticed that you changed to Mac.Very cool design as always.
But it's nothing to do with the problem. Julian's solve arrived but yours not. I can't send my socre either. I don't know why.
I will add your solves later, but PM me them rather than post here. Yo don't bother me at all. If the problem persists I will restore the certificate button...

Well at the risk of losing a fewest moves record, Julian et all, I just put up a competitive solve This isn't the absolute best I could do but it's pretty close. I only settled for placing 1 piece in a 3-cycle a couple times. I'm hoping no more than 50 moves can be shave off my technique without resorting to some other solve order. I'll be embarrassed if somebody does a sub-700 solve...