Ideas for Scripting Interface

I picture the scripting interface working in the following manner.
The player chooses a puzzle and has it displayed graphically as is currently done.
The player can then click on the script button and choose a script to run.
For instance, the script “Christmas Tree” would change all pairs to GC.

In this case, the script would be used to initialize the puzzle sequence.
The outcome of the script would be to color the graphical representation
of the puzzle with the desired sequence. This particular script should run
very quickly, with no noticable delay.

The player may also wish to solve a particularly difficult puzzle with a script.
For instance, the script “Solve it by Brute Force” would try all combinations
until the script has successfully found a solution. This script may take a long
time to run. It would be desired to have the script button change to “Stop Script”
to allow the player to use the best solution that has been found by the script
up until this point.

So, the script process would need to periodically update the graphical display
with its latest “best solution” that has been found. For instance, a script may
first stabilize a puzzle, then it would try to remove GC pairs until it has met
the GC maximum constraints, then it would add as many GU pairs as possible
to meet the minimum GU constraint. The player should have the option to Stop
this process if the player feels it has taken too long or that the displayed solution
is good enough for player to continue on his/her own.

This idea uses the concept of a puzzle context. If the script makes a call to
getStructure(), then the current puzzle structure that the player is working on
will be returned. The following scripting api’s would be necessary to accomplish
this interface.

getStructure(shapenum); // where shapenum = 0 to return the first shape of a
switch or return the shape of a single state puzzle.
shapenum = 1 to return the second shape of a switch.
getConstraint(shapenum, type); // where shapenum is defined above and type =
maxGC, minAU, minGU, maxConsecutiveA, etc…
getLockedBases(); // return a list of the bases that are locked
getClickedBases(); // return a list of bases that have been selected (with
control click) by the player, this can be used by
the script to only operate on those bases if desired
getBeginSequence(); // return the sequence that the player currently
has entered for the puzzle
hasTail(); // This is an indicator to tell if a switch puzzle (actually
any puzzle) needs to add the 5 starting bases and 20 ending
bases, since the structure may not contain this information.
applyToPuzzle(sequence);// display the sequence graphically in the puzzle,
this can be called many times while the script is running
isStopped(); // indicator that the player has pressed the stop button,
the script will need to periodically check this

Using puzzle id = 1643548, [Switch] FMN Switch 2 as an example:
getStructure(0) returns …(((((…(((.(((…))))))…((((…))))…((((((…))))))…)))))
getStructure(1) returns …(((((…(((((.((((…))))…((((…))))…)))))…)))))…
getConstraint(0, 'maxConsecutiveA,) returns 4
getConstraint(0, 'maxConsecutiveC,) returns 4
getConstraint(0, 'maxConsecutiveG,) returns 4
getConstraint(1, 'maxConsecutiveA,) returns 4
getConstraint(1, 'maxConsecutiveC,) returns 4
getConstraint(1, 'maxConsecutiveG,) returns 4
getLockedBases() returns oooooooxxxxxxxooooooooooooooooooooooooooooooooooooooooxxxxxxooooooo
hasTail() returns 1
if I control click on bases 24,25,26,27 then
getClickedBases() returns ooooooooooooooooooxxxxooooooooooooooooooooooooooooooooooooooooooooo

Great ideas jnicol.

I agree some graphical display similar to current in-game (or not just similar,but using same) experience will be needed.

Good forethought to incorporate Switches into your ideas as well.

I agree with the comments above.

I think we need a UI similar to Foldit Cookbook (LUA script)

The script I would like to start with would be “AU Fill” would change all pairs to AU on the stems.

I was thinking the same as Mat with alternating AU’s. From endloop, lowest nts having having the uracil on it proceeding up the chain.

It would be nice if we could chose between this or a GU fill on the stacks.

I would like the script interface to be able to compete with the existing Bots, not
just solve puzzles for player.
I would like to see on the Dev side is a puzzle framework where stacks, loops,
and bulges can be identified and manipulated with a series of puzzle sweeps
(if this pattern, do this). This would mean the specific location of unstable pairs
within this framework need to be identified so that additional sweeps can be added to the routine (chase over the puzzle if necessary) to stabilize. It also means
for example stack start,end, bulge type, loop characteristics (with energy) no less
should be available from this framework.
The player builds a series of sweeps over the puzzle into a routine to solve each puzzle. If the routine is good enough, it gets Bot status.

From Design of Multistable RNA:…

Using an intersecting graph theory algorithm–

"The procedure defined…was implemented using the scripting language Perl. This allows easy modifications…
On the other hand, the program makes use of the C routines of the Vienna RNA Package (via a Perl extension module)
, and thus has access to fast routines for computation of RNA secondary structures and base-pairing probabilities.

For the small example [33-nt]…the program takes about 1.3 s per sequence on a 333 MHz Pentium II.
While manual design is not too hard for such an example, the optimization procedure yields significantly
better sequences. For the 115-nt SV11 example…it designs one sequence in about 10 min."

So, a 3 GHz dual or quad processor should do our switch labs in 15-60 seconds by my estimation.

Got my attention!

These algoithms look great, but I don’t want to rely on any one particular algorithm to globally solve the puzzle (do my work). Locally, yes, but only to optimize a specific area of the puzzle. What I have seen with these bots, they are GC happy, they overload the puzzle with GCs, solve the puzzle, but will
get poor synthesis results.
So building up the structure in a series of layers, and THEN using these fancy
algorithms as a localized optimizer I think will give a higher synthesis output.

All these scripts in other languages could be converted to javascript by Emscripten LLVM , if I understand correctly.