@Pointifix, both the sounds and images folders are empty. And you can see how much code is in the Puzzle and Piece classes. The only other code is in the Text class which can be viewed from my TextFile Viewer World Class scenario. As of right now, the project folder is just under 86 KB. I use a 12-character string to store any solution. The index of each character is the same as the piece number, so only its location needs stored, and there are only 60 possibilities for that. The 'turn' and 'flip' do not need saved as they can be determined after the pieces are placed on the grid. Each pieces location can be stored using just upper and lowercase letters and 8 number characters (26+26+8 = 60).

@Pointifix, what exactly do you mean by 'it stops'? is this something you can re-create (having it 'stop' in like manner)? was it on the last piece being brought over to the mainboard area, the first piece or just some random piece in between?

@Pointifix, if it happens again, please let me know (with specifics so I can narrow down where the problem may reside). Also, being able to duplicate the unwanted behavior might help.

Got this bug again when i pulled in piece number 9, as you can see on this photo its inside the mainboard but still it is small as on the sideboard. Greenfoot stopped again: http://s14.directupload.net/images/140309/nuvximu2.jpg

@Pointifix, I cannot say what might be causing this. I looked over the code and am baffled. The only thing I found 'wrong' with the code is that a 'setColor' statement could be moved to outside a loop (so it would set the color just once instead of multiple times).

@Pointifix, ok I was able to duplicate it. I think it deals with how fast you pass the piece from the one side to the other. I will see what I can do with it now.

@Pointifix, I belive I have fixed the problem. Evidently the order the act method of the classes were (1) handle controlled movement of piece (and itself); (2) world checked for completion; and (3) piece checks size;. Because the check for completion was occurring before the resizing, an error crept in. It was happening on the last piece because all 12 pieces had to be in the puzzle area for the next phase of the completion check occurred and that is where it determines where the blue part of the pieces are (with the piece not being full size, it was looking outside the bounds of the image).

mhhm maybe you fixed that bug, but now i got this: http://www.fotos-hochladen.net/view/solutiona3si796pdx.jpg i won with this

It seems to have determined that you had found a solution before the location of the piece was updated on the display. It did save your solution properly. Next time that happens, try clicking on the 'Run' button to view the stats, then click on it again and see if it adjusted. Inform me of results.

@Pointifix, I took the puzzle completion check out of the world act method and the Piece resizeing out of its act method, created separate methods for both and called then anytime a piece handle was dragged and moved. That should fix the moving of pieces after solution was found.

At least 18 solutions (without rotating and mirroring). Is there not anyone else who can come up with just one? So far, only one person has come up with a solution -- Pointifix.

'Added the missing ranking numbers in with high score stats.' Oh sry understood this the false way, thought that missing would be counted as well ;D good thing :)

Had to re-size the app window (I have to solve the puzzle each time and get to the Stats screen before uploading or the Stats screen will end up with scrollbars).

@nolttr21, the images are smaller when in the tray; they become normal size when in the placement area. This was done to reduce the size of the tray (which would need to be around two to three times the size of the rectangle, otherwise).