There're some very weird things going on with wiggle.
Sometimes it just won't budge at all, or only by micropoints, even with strong bands and/or 0.0(zero) CI.
Select all and wiggle seems to work more often, but not always either.
I've seen many complaints, in group & global chat.
Also, the question. The start point given is definitely not the solution I flagged/shared for devs/scientists.
The screenshots I included are of the solution I shared on 691.
As u can see: the helix is 2segs shorter, the sheets are a bit prettier and everything is packed a bit tighter.
My question: why or on what grounds was the current start chosen over my fav?
Did u desperately need the slightly longer helix? What do u know that I don't? :p
If needed I'll open a separate question-type feedback for this, but I would REALLY like to know.
MurloW, perhaps YOU can help diagnose this wiggle issue.
If you are still able to load in your 691 solutions into that expired puzzle, can you tell us if the "wiggle-sticking" issue still happens on that puzzle (using the current client) or not?
Even if it's not with this identical solution, you should hopefully be able to tell if the issue is present in that puzzle or not. Although that does require playing 691 again (and I know how slow it was!).
Thank you for any help you can provide with this nasty wiggle bug!
I am looking into your second question right now…
Omg I totally forgot exactly HOW slow it was, disable slow filters ftw..
Ontopic: it seems to work fine with the disable checked.
I moved the structure away from the symmetry, and 1.0 CI wiggled it back into place.
Then I squeezed with a wiggle at 0.10 CI for 1 iteration before moving up to full CI in that same wiggle.
I did a mutate & shake after moving it away again, and again after moving it back together.
Everything behaved fine. A bit slow, even with disable checked, but it's a tetramer and I have 4 clients scripting in background so no wonder. The moment a band is introduced, even at 0.5 strength, it clearly pulls, which is not always the case in 725.
So 691 is pretty perfect without the filters. With them very very slow, but still in working order.
By keeping an eye on 725 for a while, I've noticed it seems very random when it happens.
With gab bis scripts, gentle/shudder/whatever, sometimes wiggle doesn't have any effect, but often does.
For example: it's being pulled with very strong bands at 0.3CI, but no movement greater than 0.1 pts. Script removes bands, shakes at 0.1, and then wiggles at full CI, but that time it does move, vigorously.
And with the very next set of bands, it got pulled all over the place, bands are deleted, shake at 0.1, and wiggle at full again, but then it doesn't move to "restore" itself whatsoever so the script thinks the bands were no good, and moves on.
Thank you so much for your help, MurloW, as this indicates that the major difference is in the filters used in these newer puzzles (compared to the slower filters from 691) and not something in the latest update.
If the latest update to devprev & main had introduced the wiggle-sticking-bug, then it would show up when you play 691.
Thanks again!
(and sorry that you had to play slow 691 again :-)
Hi MurloW, I'm assuming this is the case, but I just want to be clear—wiggle is just as sticky in 725 when you disable slow filters?
Yes indeed, disabling slow filters does not help.
You're welcome beta, everybody wants this fixed :/
except maybe those without any trouble :p
I took screenshots of the recipe output window during GAB BiS Shudder.
The numbers after : (colon) represent loss of points due to pulling by bands,
all the 0s and -0.001s are instances when Wiggle was unable to move the structure.
This just illustrates the seeming randomness yet frequence about it all.. :/
Thank you for all your help in diagnosing this issue.
You can help us with this by trying out this devprev puzzle and telling us if the same issues occur:
http://fold.it/portal/node/992823#comment-23390
Thank you for your help and patience with this nasty bug!
Glad to be of service.
I'm still a bit unhappy due to the 725 starter chosen,
markm gave me a bit of text from the blogpost regarding the Share button that might explain how it got overlooked.
Though in any case, the share chosen for 725 had to have been picked out of an auto-save or something because it's definitely not something I manually saved, since I had a much better looking solution with same topology design.
Which is probably very counterproductive towards the share button, because I thought those saves would actually be looked at and chosen from, instead of just filtered for highest FoldIt score.
FoldIt scoring system =!= perfect.
Sorry MurloW, there must have been a solution file mixup somewhere on our end. This all happened before we had the "Upload for Scientists" button working, so we were retrieving solutions manually; there's no telling what might have happened. We were unaware that you had a better-looking solution (we were pretty excited even about this one). Rest assured, we've been looking at all the solutions shared with the new Upload for Scientists button, regardless of Foldit score.
Could you tell me again which solution you meant to share? I'd definitely like to check it out, and maybe run another folding test on it.
