As I've learned, the standard lua library also has a function to get the system time, called os.time()
So, a vote again for the standard Lua library.
Tlaloc wrote sometime before, that some library functions should be disbled because they could do something bad.
To my opinion, it would do, if all functions according to file writing access (which a virus needs) would be disabled.
All other functions wouldn't do any harm, only crashing the system at worst case.
I was getting ready to do some script work.
A missing feature is to open a dialog box with arbirary controls
such as buttons and sliders. I was thinking a simple vb program
could do the trick using two files for communication between them.
Since it appears one can't create true process threads one could
just have the called thread be the communicator to the external
process that handled the dialog box.
While I could hijack the files fold it writes I'd have to learn
the verification algorithm that generates a number like:
verify: xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Tlaloc's concern about virii makes sense. Restricting IO to
file names generated by foldit would be a good compromise.
This would allow fold it to restrict io to the ProgramData/foldit
directory.
I updated the list of standard Lua library functions in the wiki (http://foldit.wikia.com/wiki/Lua_Standard_Libraries) to show the ones that are available in World of Warcraft (WOW). WOW also uses Lua as its scripting language. Since WOW is a much larger potential potential for being a virus vector, I think you can assume that if they allow a function it is safe.
I'm still investigating what is the right way to allow me to share a library of code across scripts a set of scripts.
Nice work, now the developers of FoldIt will have an idea which functions seem to be okay to be included.
Any word from the foldit team on when we can expect to see some new Lua features? I keep finding new things to add to the list on the wiki as I have new ideas for scripts that I can't write.
I'm curious, too.
A simple but effective change would be allowing a higher maxmimum bandwidth, this would make a big difference even for banding recipes which already exist.
I hate to point to a dead link, but http://thewarwiki.com/wiki/WAR_API (defunct) used to point to the Warhammer Online lua api information. As a dig on google found nothing, best I can say is it had all the functions of WoW, as well as a few other things, in a slightly different implementation, different names for functions etc…
Regardless, it had the string, math, and tables libraries implemented.
Its sad that the feedbacks that would be the most benefit to scripting have been downvoted SO much by the people shouting everything should be done by hand. I mean really… I got the feedback for those 3 libraries to get several upvotes today, and others came in and downvoted it. To implement them is a few hour (if things go wrong, which they always do) task.
I really wish they would open the source up. Sure, its sort of available to players, who, if they aren't a research institute can acquire for the low low sum of the price of a luxury car. Even then, all indications are its not the client. If source were opened, and a git or even regulated svn system were added, people could write patches, and take a large load off the devs, and help bring all these features to the client.
We are aware of how important this is for many Foldit players, but we just currently do not have the resources to work on this immediately.
As for the Open Source, we have set up everything for non-academics to be able to download the source files but it is currently stuck in the bureaucracy stage. I really hope that this will be completed soon.
Thank you for your patience.
I'm generally not a patient person, beta_helix. I admit it. I know its a fault.
The 'big red flag' I see in your statement is 'non-academics to download the source'. Downloading the source is one thing. Look at SecondLife, which was a closed source turned open source. It wasn't until it started ACCEPTING source it really began to benefit.
My notes on using git or a supervised svn weren't so much for the download-to-build as it was for the submitting patches. There's thousands upon thousands of hours of volunteer development hours waiting to be expended to help improve the game. Most of those willing are likely more skilled than I. I'd love to see them given the chance to really push fold.it forward. An open system to support user-made patches would be the best way to forward it.
Right now, its probably a small group of students who work in the lab, getting a small salary and/or some tuition as well as a few professors who oversee and throw in the occasional patch working on the source. All of them cost X amount of dollars for Y work put in.
Open source means the university pays nothing to improve it, but the results, and thereby the science improves.
Sigh… I should stop now. I've said my bit. Opening would allow lua to be improved easier, so this is all relevant. I'm sure you can see the benefits. I wish others would see it as quickly and decisively so as to allow it.
Open source means the project people would still have to be involved with analyzing and approving every change submitted to maintain the scientific integrity of the results. Remember, even though this is advertised as a "game", this is serious scientific research, and needs to be controlled as such.
Also, since this project awards points making this a competition, opening the source for changes will attract the usual crop of people who want to bypass the security of the game and submit fraudulent results to "game" the scoreboards. Don't say it doesn't happen - SETI and the other DC projects have all had to fight those battles.
I'm happier having this tightly controlled.
I'm also suspicious that this frantic push to add more functionality to lua for more powerful scripts is all about making the few script writers all-powerful, leaving the rest of the 99.9% of the users unable to compete. that caution could be alleviated by making ALL scripts public - none of these private personal or team-only scripts.