Hot Ket to Cycle through Snap Positions

[Crashguard303]

local segment = 1
i=1
repeat
do_sidechain_snap(segment, i)
do_global_wiggle_all(1)
i=i+1
until i>get_sidechain_snap_count(segment)

is safe.

[GaryForbis]

It turns out I got an error on:

for i=1, get_sidechain_snap_count(segment)
do_sidechain_snap(segment, i)
end

in puzzle 366. It looks like the test for zero is needed.
Unless Repeat… until tests at the top of the loop it would fail as well.

My final position on 366 will reveal this error using Gary MutateAll v0.2.
I wonder why the replace_aa didn't throw the error if there are no snap positions.

[Crashguard303]

Then, do it this way:

local segment = 1 – The segment index you want
i=1
while i<=get_sidechain_snap_count(segment) do
do_sidechain_snap(segment, i)
do_global_wiggle_all(1)
i=i+1
end

[Crashguard303]

Replace only sets the sidchain shape at sets a snap position automatically, so the error can't occur then.

At which segment index # does it occur and which amino-acid shape does it have then?

It can also be that a try to snap locked (grey) segments can cause an error.
Possible, that with get_sidechain_snap_count() you get a value above 0, but if you try to execute snapping, you get an error because the segment is locked in this puzzle.

We need a function that tells lua if a backbone or sidechain is locked, similar to the do_freeze() command, but working not to set but to fetch values.

[GaryForbis]

Good replacement code. Thanks.

I tried using snapcount on sidechains to identify locked sidechains but it returns a number > 1 even though locked. I don't yet know what happens if one attempts to snap a frozen or locked sidechain.

[Crashguard303]

Under which conditions does snapcount 0 occurr?
Can somebody show how to reproduce it?
I only know that it CAN happen (had it also long time ago, but didn't investigate further then), so this is why I added zero check before I had the idea for this simpler way.

Tlaloc is right.
Lua doesn't execute a "for" loop if running range and stepsize don't fit together.
I didn't know this detail and just wanted to make sure, because there are programming languages, which do this check at the loop end (similar like a repeat-until-block), and not at the beginning.

So, I learned something more, thanks.

[GaryForbis]

OK, we're looking at a changing background.

I did this test on 367:

x=get_segment_count()
print (x)
deselect_all()
select_index(x)
do_local_wiggle(1)
print(get_sidechain_snap_count(x))
do_sidechain_snap(x,1)
for y=1,0 do
print (y)
end
for y=1,0,-1 do
print(y)
end

It went into a long pause but didn't throw an error.
When I tried it again it didn't even go into the long puase but just
returned:
490
1
1
0

So this doesn't explain the error when attempting to do the snap.

I've tried reproducing the case with snapcount=0 on 366 but haven't found it yet
and am at 8 of 17 mutable segments. I thought it failed on the 4th.

It's a mystery.

[Crashguard303]

Well, as there is 1 snap position and you do this one snap, this can't produce the error.

Let's see:
You get the number of segments and store it in x, printing it results 490.
You get the snap count of segment x=490 (last segment), it's 1 printed.
you do snapping of segment x=490 and use snap position 1, which is in an aceptable range.

for y=1,0 is skipped completely.
for y=1,0,-1 works and prints out 1 and 0.

The long pause at first run and the missing of the pause on second run is normal.
Before (a new) script starts, the code is checked for errors and translated (compiled).
Once it has been compiled successfully, this step is not done again if the script is run another time.

You can even change some values and the script will start earlier than on the first run.

[GaryForbis]

The puzzle is a ligand puzzle. The last segement is supposed to be a ligand. I thought something was suppsed to fail on the ligand. It appears to have a snap count and can be snapped. Since I cannot reproduce the error running the same script on the same puzzle with the same starting score (use by tlaloc and my derivatve scripts as seed for random) I suspect something has changed elsewhere. Though it doesn't mean much my restore to best on 367 is down one point from my creditted best and my own recollection of it. There's too many moving parts to know what's going on so I'll just write it off for now. Since the for loop tests at beginning of loop I don't know why snap would fail. I've used the same script on many puzzles. That it would fail several times at the same place but doesn't fail now is just a mystery. Not all mysteries need to be solved. At least I can rule out snap count of 0. Why snap would fail when index is in the range indicated by snap count is beyond me and doesn't really matter any more. Next time I'll document better. Maybe there won't be a next time. An error saying the index is out of range without giving the index or range isn't too helpful. As far as I know there's no debugger I can enter so as to recover the values once the program abends.

[Crashguard303]

Yes, but you could print segment index and snap position before you execute snapping.
I'll take the example above again:

local segment = 1 – The segment index you want
i=1
while i<=get_sidechain_snap_count(segment) do
print("segment:",segment," snap:",i)
do_sidechain_snap(segment, i)
do_global_wiggle_all(1)
i=i+1
end

So, if snapping fails, you will have printed out what was tried before.

As you say ligand puzzle, keep in mind that you can't change the "amino-acid" of a ligand.
On all ligand puzzles, replace_aa() of the last segment produces an error.