Being able to disable blob view entirely and band in stub view would perfect, if possible. Susume may have been implying this, but I'm not sure. I don't see any advantage to blob view at all. I think QTTN banding to sidechains (stubs) would be much easier and accurate than banding to blobs or segments.
When closing cutpoints I normally use local wiggle to get the backbone better But local wiggle is not local anymore. It moves big structures outside the selected piece. Making this kind of puzzle extra extra hard. What I reported as weird behavior is endemic in this puzzle.
Clashing score is not shown in the segment scores. Is that an other score component now?
Also I dont see any bonding info in the segment scores. Even when bonds are clearly visible.
We're looking into the local wiggle issue.
The score terms for clashing are no longer computed in centroid mode. The same with bonding, those score terms don't exist so there is nothing to show.
We will be adding in some new score terms to the centroid puzzles in the future that should cover the bonding issues (but not the clashing terms as those require the full atom mode as of now).
Wiggle doesn't work. Rubber bands don't work. Clashing doesn't work. We're not allowed to touch sidechains. And yet the puzzle is still too complex for most computers to handle.
Total fail.
Throw this idea of centroids in the garbage — where it belongs — and give us a real puzzle.
Seriously. This is offensive. You will frustrate countless players into quitting the game. Stop shooting yourself in the foot.
In a normal puzzle, scoring generally tends to keep helixes intact even if they are changed to loop before rebuilding - for example, DRW changes all to loop by default and chooses rebuilds based on score, and the helixes keep their shape more often than not. In this puzzle, the rebuilds of helices that win the scoring race are often ugly and very un-helix-like - see http://fold.it/portal/files/chatimg/irc_341210_1367633602.png (shared to myself with slightly higher score under name "ugly helices")
You might want to examine the scoring and see if it is really giving you good backbone shapes.
When you check to see if we were able to match the guide, I suggest looking at lower scoring, earlier solutions - my guess is the high scoring ones started out as good matches (and therefore realistic looking proteins) but wandered far from the guide in response to score.
One major difference in the Centroid puzzle compared to regular guide puzzles:
In a regular guide puzzle, I can use shake to see how close I have my protein's sidechain aas to the guide. Turns out I used that more than I knew to judge how I was matching it.
In the Centroid puzzle, if I'm not hovering over the protein's blob, I can't see the guide blobs. There is no Shake equivalent that turns all the guide blobs on at once the way Shake did.
Puzzle 705 seems to call for lots of bands, and banding is difficult. With all the blobs, it's hard to see the target blob on the guide. Then you must rotate the view multiple times to get the band to the right spot. Usually you delete the band a couple of times by accident, and need to Ctrl-z to get it back.
Starting a band on a blob, then shift-D to hide all the rest of the (non-banded) blobs, makes banding somewhat doable, but it's still a chore.
I don't see the gain for science in what amounts to a struggle with the user interface. It seems like the interesting question is which segments to band in what order. Lots of folders have proved their ability to create a band from point A to point B despite the difficulty, so lets file that and move on.
Suggestion #1, provide a right-click context menu with a "band to guide" option. In centroid mode, a blob-to-blob band would be sufficient. Fine-tuning is left to the user.
Suggestion #2, make bands a little easier to handle. Eliminate the click-to-delete option, or make it a separate setting. You can still delete the band via its right click context menu or a global "r". If you must keep click-to-delete, make the head of the band larger and give it a safe collar to cut down on accidents.
Suggestion #3, add a note that can be displayed outside of note mode. I'm thinking of something like placemarks in Google Earth, where each placemark can be turned on or off independently. Allow placemarks on the guide as well. The placemarks could reside in a collapsing section of the cookbook.
Suggestion #4, extend the "band to guide" option, offer a "band to placemark". One possibility is to make this a context menu option on an existing band. Creating a short band to start is not a big issue.
Suggestion #5, add a "go to segment" option. Perhaps it could be added to the score box. (Or maybe just as a "g" keyboard shortcut.) As a bonus, display the number of segments in the score box. Perhaps add a toggle which would display numbered placemarks every five or ten segments.
A more powerful user interface seems a reasonable requirement for more complex puzzles.
Working on 709 after 705 is very instructive. Rebuilding a helix (all loops) goes through a similar series of poses in both puzzles. Those same weird (non-helix) poses that gain points for 705 score negative 5 figures (e.g. -30000) points for 709 and are rejected. Rebuild destroyed the helices and sheets in 705 whereas secondary structures are maintained and improved by rebuild in 709. Of course, the problem is not with rebuild which is just an optimizer and is doing its job. The centroid-mode scoring function is creating a bad error surface.