AreConditionsMet()

Case number:845813-997093
Topic:Game: Tools
Opened by:MurloW
Status:Open
Type:Question
Opened on:Saturday, February 22, 2014 - 19:31
Last modified:Thursday, January 19, 2017 - 03:10

Why don't any of those calls work?
current.AreConditionsMet() returns true, anytime, anywhere, any which way.

I used move tool to get Ebola ligand waaaay, waaaaaayyyyy out of line, still returns true.
I mangled the dimer design so that every filter was screaming minus thousands of points, still returns true.

When I cut up a protein, the client distinctly says: 'Condition not met: cutpoint(s) need closing.';
current.AreConditionsMet() will still return true.

I realize those calls may have been implemented to check against RMSD constraints, but shouldn't they check against ALL conditions, except perhaps the design filters? Instead of, you know, NONE of them.

Something to ponder, devs.

This feedback would get a dirty workaround, at the very least.

(Sat, 02/22/2014 - 19:31  |  9 comments)


MurloW's picture
User offline. Last seen 17 weeks 4 days ago. Offline
Joined: 11/21/2012

Huzzah ! Puzzle 851 got me a false return, at last! So, it is indeed to check against exploration constraints.
Also, slightly unrelated, un-evolved solutions return true as well.

Should I foster any hopes that these lua calls will get more functionality, like checking against cutpoints and/or ligand constraints ?

KarenCH's picture
User offline. Last seen 26 weeks 3 days ago. Offline
Joined: 07/14/2012

It would be very helpful in scripts if I can know when structure.DeleteCut() fails, so I can restore to previous state rather than continue forward. I don't care how I know it - either AreConditionsMet fails or it returns a Boolean....

spvincent's picture
User offline. Last seen 13 hours 28 min ago. Offline
Joined: 12/07/2007
Groups: Contenders

I agree: DeleteCut() should return a boolean and so should RemixSelected ()

Joined: 07/21/2013
Groups: Beta Folders

When you make a cut and wiggle and cut ends get far apart the cut turns blue.

If you put a band on the cut and wiggle and the cut ends get close enough, the cut turns yellow.

Could it be that the cut has to be yellow in order for structure.DeleteCut() to work?

You might be able to put a band across the cut. Wiggle until the distance across the cut is small enough. Small Enough is something to determine by experimenting. Then do the DeleteCut().

Why do you exempt design filters. I am looking for a way to detect if the filters are enabled and if their conditions have been met or not.

MurloW's picture
User offline. Last seen 17 weeks 4 days ago. Offline
Joined: 11/21/2012

Yes, the cut has to be yellow before DeleteCut(i) will work, but without boolean return or a workaround a recipe can't know if successful or not.

Your other question:
Because the point of current.AreConditionsMet() should be to see if the current pose/fold is able to get onto the scoreboard; period. A fold with design filters keeping your score low will still be registered on the scoreboard, although a lua call to check against these filters would be handy as well. ( a workaround is using current.GetScore() vs current.GetEnergyScore() )

Say you have a fold at 8000pts; you make a cutpoint, wiggle some and get a scorejump of +500 pts (this is an extreme example but bear with me), closing the cut and fuzing results in a net loss (7950).
recentbest.Restore() and absolutebest.Restore() will always revert back to that pose having a cutpoint, since it scores better than without the cutpoint; but that pose will not register on the scoreboard, because: not all conditions are met, even though AreConditionsMet() returns true.

Any recipe trying to use cutpoints will encounter this to some degree, and there is no way to differentiate between a pose with or without cutpoints. At the moment we have to script using creditbest.Restore() in a fresh track to avoid this.

imho, we should be able to do something like this:

if currentscore>bestscore then
if current.AreConditionsMet() == true then
save.Quicksave, bestscore=currentscore
end end

without ending up with a pose with cutpoints, or a ligand constraint that's completely out of whack.

MurloW's picture
User offline. Last seen 17 weeks 4 days ago. Offline
Joined: 11/21/2012

Derp. I figured GetEnergyScore() would return the score without the bonus/penalty from the filters, but it seems it doesn't. Excuse me, there is no workaround. Should have tested before posting. x]

jeff101's picture
User offline. Last seen 4 hours 59 min ago. Offline
Joined: 04/20/2012
Groups: Go Science

It would be nice to have more LUA commands related to cut points; for example, cutpts.GetCount() similar to the already-existing band.GetCount() and structure.GetCount().

jeff101's picture
User offline. Last seen 4 hours 59 min ago. Offline
Joined: 04/20/2012
Groups: Go Science

Since a puzzle can have multiple conditions to meet, instead of just returning a boolean, why not let current.AreConditionsMet() also return a character string or list of numbers telling which conditions are actually met by the current structure?

LociOiling's picture
User offline. Last seen 2 hours 30 min ago. Offline
Joined: 12/27/2012
Groups: Beta Folders

It's been nearly three years with no answer to this question.

Just to recap, take this simple recipe:

print ( "conditions met = " .. tostring ( current.AreConditionsMet () ) )

First, open a shared solution to a design puzzle. It might say "conditions satisfied: 1 of 2", since the "evolver" condition is not met.

The recipe returns "true" in this case.

Second, add a cutpoint. It's now "conditions satisfied: 1 of 3". But the recipe still returns true.

Third, use "toggle filters" to turn off filters, or selectively disable one filter. You're still at "1 of 3" if you don't perform an action, and the recipe still returns true. If you run a brief shake, the count goes to "0 of 3". The recipe finally returns "false" in this case.

So it seems like the only condition that's actually detectable is whether the filters are disabled, and even then current.AreConditionsMet is not a very reliable guide.

But wait, there's more! If you disable filters in a recipe, AreConditionsMet picks up it immediately. It's only when you disable filter in the Foldit user interface that detection lags.

Try this code:

behavior.SetFiltersDisabled ( true )
print ( "filters disabled = " .. tostring ( behavior.GetFiltersDisabled () ) )
print ( "conditions met = " .. tostring ( current.AreConditionsMet () ) )

On a filter puzzle, it returns "true" for the filters being disabled and "false" for the conditions being met.

The inconsistent behavior seems like a genuine bug to me, but we'll keep this as a question.

Sitemap

Developed by: UW Center for Game Science, UW Institute for Protein Design, Northeastern University, Vanderbilt University Meiler Lab, UC Davis
Supported by: DARPA, NSF, NIH, HHMI, Amazon, Microsoft, Adobe, RosettaCommons