In this developer preview update, we've added 2 new behavior sliders. One affects the behavior of Wiggle and the other affects the behavior of shake. The names are temporary, so if you think the names don't quite fit, we're willing to rename them.
Also included are bug fixes for the symmetry puzzles. If you are still experiencing issues with the symmetry puzzles after the update, we'd love that feedback.
If you're interested in helping to test in the developer preview, you can switch versions by going to your Foldit data file folder, and chaning your options file (For more information, look up the FAQ on the website).
Be aware that there almost certainly will be many bugs, and joining the developer preview can cause you to lose saves, have more client crashes, and other issues. That said, we'd appreciate anyone who's willing to help out!
give some explanation about that sliders? How it works/ what change it made?
ie: lower number = less score but faster?
We're partially interested in what you players think the sliders are doing.
That said, I can explain a little about what is going on in the backend.
Wiggle is composed of a lot of back-to-back minimizations. Each of these runs until some threshold of convergence is met. Wiggle accuracy adjusts what this threshold is.
Shake accuracy determines the number of positions of a sidechain that are considered when shake runs (the actual number displayed isn't the real number of positions).
Intuition would seem to suggest that a description of "lower number = faster, but lower scoring" makes sense. However, this isn't necessarily how it will come out in practice (at least for wiggle accuracy).
separate clash importance for sidechains and backbone?
I`m thinking about 2 sliders and a check box to join them ("move together") to work like it is now.
Sometimes I want to keep bbone shape and ignore sidechains, this way I can set ssCI=0.01 and bbCI=1.0 or something close.
That would prevent protein to blow on some ugly rebuild attempts :)
The opposite setting can gave interesting results too - sidechains prevent to bbone collision, low ci wiggle all/bbone most of time making it "compress" what not always is desirable.
"separate clash importance for sidechains and backbone"
I think that would be useful too.
I would suggest the name "Wiggle Depth" and "Shake Depth". Both imply "to what extent or level" the actions will go.
This might be a better fit than "accuracy" which implies that wiggle or shake is going to work until the backbone or side chains are closer or further away from some target value.
First impression is that the CI is the (average?) amplitude of the movements and the WA is the (average?) randomness of the movements - i.e.: how closely they match what the model predicts is likely to work.
… or maybe the other way around even. They seem to behave quite differently at different times!
Wiggle accuracy would I think be quite useful if its functionality were available in Lua through the API. Setting it to a low value while a wiggle with bands was taking place would speed up Quake-style scripts considerably.
Wiggle Accuracy as a numeric value is intuitively wrong (larger number implies more accurate) when it really means a convergence threshold.
Call it Wiggle Fuzz
A larger value maps to a larger acceptable solution space, greater tolerance allowed from the "ideal" position.
