Macro language/API suggestion: separate the UI from Foldit engine

[jas0501]

There has been some chat regarding open source of FoldIt and the proprietary nature of the "folding" keep it from becoming "open Source"

I think it would be excellent if FoldIt could be overhauled to permit the UI interaction portion to be Open Source. Kind of a UI skin.

UI Handler Event API events===> FoldIt Engine Event Handler

This would permit all kinds of possible User Interface. As an extreme example a voice activated UI. The user would say

"UnLock All"
"Lock segment 21"
"Lock Segment 25"
"Local Wiggle Segment 22"

and the voice activated open source UI skin would package and send the appropriate events th FoldIt display engine.

This would require a formal specification events supported by Foldit. Clearly some interaction don't translate well to verbal commands or event scripting. The unattached bands and the pull operation are vectors and this can be a bit tricky.

Another example might help illustrate my point. In structure mode on can select a segment and then drag to another segment changing all segments in between the starting and ending segment. This is a number of operations caused by (down-click, mouse move events over segments, mouse up-click event).

1. set Structure mode event
2. Select starting segment event (down-click)
3. begin change struct mode event
4. select ending segemt event ( this changes the elements when the mouses passes over a segment)
5. repeat 3 for each segment "touched"
6. end change mode event (up-click)
7. set Pull Mode event

One could just as easily implement a double click select start segments, double click select end segment interaction model.

1. set structure mode event and select starting segment event and begin change mode event(double click)
2. select ending segment event and end change mode event and set Pull Mode event (double click)

Or write a script interface that would post the same events with some language specification

set S-Mode __(set structure mode event)
pick 21 __(select starting segment)
begin change ____(begin change mode event)
pick 37 ____(select ending segment event )
end change ___(end change mode event )
set P-Mode __(set Pull Mode event)

---

The key point being a clear separation of the UI from the FoldIt display and compute engine proving support for all possible interaction events.

[admin]

A good idea, but not exactly urgent, so I am demoting its priority.

[jas0501]

Well I think priority 4 places likely action on this item a couple days before Hell freezes over.

I would argue that it deserves a higher priority for the following reasons:

1. It would open a portion of the system to the open source community thereby increasing progress and innovation.
2. The development a formal spec would go a long way toward hardening the existing product code and making it less bug prone and easier to enhance.
3. It would improve that quality of the discussion around existing features and possible enhancements and the addition of new features.
4. It would go hand-in-hand with the Scripting effort and imprive the scriptings implementation.
5. It would make user modifiable hot-key assignemnt simpler to implement.
6. It would make macro recording and playback a very simple feature to add.
7. It would provide a formalism regarding the current API that does not yet exist and permit easier consideration of incorporation of possible new feature enhancments.
8. It would make test case development and test script writing easier to accopmplish. Proper test coverage would be easier track with the existance of a formal API.

[axcho]

Not sure if this is exactly what you're asking for, but we're actually working on something very similar. That is, abstracting all tools and changes that can be performed in the game into Actions, which will be used by the macro language currently under development. It will make hotkey assignment easier, as well as making a flexible Inventory system possible.

Players will be able to save, share, and edit macros they create. Once this is implemented I imagine would be cool to go a step further and completely separate out the interface from the engine and from the graphics. And if I might have my way, from the game logic as well, so I can improve the game aspects of Foldit.

I'd be interested in hearing your specific suggestions for how this open source separation might occur. I'm new to this sort of thing so I can't exactly visualize how it would work. Thanks. :)

[Steven Pletsch]

Well, I'm not sure on the model you are using for the macro, I assume it's going to based on some sort of already available language ?

What I would think is ideal, is probably far more complicated that what you will end up doing, but I would like to see a stripped down C style interface. I would recommend taking a look at the scripting portion of the source for the video game Second Life. It is an open source video game with a fully robust scripting language such as described below. You may get some ideas from seeing how they strip out the translation between user defined code, and game executed code, as well as means to present otherwise difficult data in an easier context.

Obvious functions would be the tools such as:

Wiggle(integer x, integer y, integer z) //where x is the segment to start, and y the segment to end, setting 0,0 would do global wiggle, and z would be the length of time (seconds).

Tweak(integer v, integer w,integer x, integer y, list z) // where v would be the starting segment, w would be the ending segment, x would be the length of time (in seconds), y would be the type of function (rotate, straighten, etc.) z would be the list of required variables for the chosen y, be it direction, vector, or empty.

Other functions would be helpful, such as

Get_Rotamer_Positions_Available(integer x) //where x is the segment number, this would return a list of available positions. (not sure if you use vectors or quaternions, so this may need to return a value which marks a column in an array, such as 1,2,3, and setting a sidechain to position list[(1)] would transparently load the complete list of vectors for that position?)

Get_Type(integer x) // where x is the segment and it returns the letter designator for the amino acid for that segment

Get_Current_Postion_Sidechain(integer x) // where it would return a series of vectors for the position of the sidechain.

Set_Sidechain_Position(integer x, list y) // where x is the segment to choose, and y is vector list for the segments. This function should return TRUE/FALSE for whether it succeeded or not.

Set_Recent_Best($SlotA) // it would be helpful to have access to 3 or more slots for comparisons. It would also be helpful if there was a variable associated with it like $SlotA_Score

most of these items should be already variables in the game, with the ability to add user defined functions, and full use of logic and loops, it would really give us the opportunity to try just about anything.

if, else, for, while, string, etc.

[Steven Pletsch]

And I'll even go on record as stating, I truly believe that given full access to all variables in a logical form, and an interface like described above, with full access to all tools currently available through that interface, within 6 months to 1 year, I would no longer need to fold, because everything I do now can be 100% automated.

[admin]

The initial version of the macro language will probably not be quite that powerful, but it won't be dumb either, and we do intend to give the players full range of expression with the macros. It might take a few versions before we get there. All the suggestion here have been noted.

[Steven Pletsch]

Well, I don't expect that it would be released a finished product, but it's good to know that you are taking these into consideration. It would be very helpful if we could get a short blog post describing:

the form of the macro language used, is it a custom language, a stripped down version of an existing language, or an already available language with additional tools for working with the foldit core.

the commands you intend to unveil initially. Perhaps we could give feedback based on any perceived oversights, or suggest minor modifications (unicorns and ponies)

Will this be event based, batch based, or recording through the gui ?

have you considered using an already available lisp or macro system that is compatible with other available software ?

will this be completely client side, or do you intend to interface running macros with the server in some form?

——————————————————————————————————–

As we get closer to the release, I think an additional blog posting should be made addressing other topics as well, such as:

When created, will we be able to upload macros to team shares, public shares, or some other type of sharing be allowed through foldit? Would you make sharing mandatory, or can macro creators choose whether or not to share them?

Will shared macros be subjected to any kind of copyright, or usage rights? Will creators retain rights, the project, or will they be public so that developers of other programs may implement some of the ideas?

Will the source of these macros be made public, or simply a compiled or encrypted form ?

Will use of macros be disclosed publicly? For example if we create something we want to let run overnight, will it show our name in an alternate color in the chat windows and score lists  to indicate a macro is running on that account? Will final results indicate that a macro has been used, perhaps naming the macro and pointing to it in a public share ?

[jas0501]

Some disconnected thoughts….

I think one additional model to consider is the way macros are recorded in Excel into legitimate compilable code. One can record an operation and then look and the code to see what is being done. Then one can "adjust" the code to generalize it into a function.

---

It may be benificial to have 2 address models,

1. absolute, as in freeze(27), meaning segment 27,
2. releative as in freeze_offset(-2) meaning freeze the segment 2 down from the current selection.

---

One thing that is unclear to me a in a macro to walk the backbone how one will know when to advance the walk.
Here is a backbone walk that I hope the macro language could accommodate:

Maybe an atypical walk approach, call it the rocking chair. Rock back and forth between cell selections until no more gain is forthcoming then advance and rock again.

RockingChair(1,6)
// is something like this
locking all 1-6
unlock 3-4
wiggle 3-4 until done
unlock 2
A:
wiggle 2-4 until done
lock 2
wiggle 3-4 until done
unlock 5
wiggle 3-5 until done
lock 5
wiggle 3-4 until done
unlock 2
unlock 5
wiggle 2-5 until done
lock 5
if still progressing
goto A
else
lock 2,3,4
exit
endif
—————————
// One would then define a loop for the chain

for i = 1 to segmentCount -6
rockingChair(i,i+6)
next i

Some questions arise:

1. "until done": How does the wiggle know to terminate?
2. Will it restore the best score?
3. "still progressing": In the example above you know your done with a rocking cycle make no progress.
   a. How will this be accomplished?
   b. One could declare a local varialbe to keep the beginning score and then exit if it has not improved by some threshold.

This example illustrates the slippery slope between a maco language and a "programming language" that seme would find philosophically out of bounds as far a foldit is concerned.

I think the "progamming language" would permit easy expermimantation by the foldit community with excellent prospects of good discoveries.

---

Backto my initial point. I too think using a compilable language and a library of macro calls for the operations will pay dividends in the long run. But given that diverse operating systems supported a "tiny" susbet of a full blown language my be more realistic given the licensing of a full blown language compiler. Maybe something similar to Tiny-C, or Java or some such. Not a simple problem…..

---

[axcho]

Maybe the guy who's working on the macro language doesn't go on fold.it very often, and the people who do go on fold.it don't know enough to say anything that won't end up being completely wrong the next week. I personally don't know much about the macro language, or the person who's implementing it, or what it will be like beyond what has been described publicly.

The actions (such as Tweak, etc.) are still being refactored into the encapsulated style you describe, and any descriptions given out now will probably change.

That said, I have access to all the source code, so if there is a particular thing you want me to dig up, I'd be willing to do that for you. Just let me know. ;) The more specific, the better.