It's clearly obvious from the people contributing here that it's Anthropic Dreams beating up on the tiny Go Science team, in retribution for some of the AD members leaving and joining Go Science.
They couldn't stop their precious recipes leaving with the users, so they have invented a new issue as a means to annoy Go Science, and continue trying to be the 800 pound gorilla team who HAS to get what they want in their childish way.
Every wonder why they left in the first place?
Attempting to relocate this to a new forum thread - http://fold.it/portal/node/989668
Re: vixynn
While I do not like the idea of cloned accounts either, I can see why some players find them necessary. As I mentioned in http://fold.it/portal/node/989405 , workarounds do exist– but they have to be done very carefully and manually. The best one can do in a recipe/script is to use the quick-saves, and even then there's always the chance of wiping out an alternative trajectory via the restore very/recent best function.
This is exactly why I suggested a month ago that there should be an option of designating accounts as "secondary," non-scoring accounts that are linked to a main account (see http://fold.it/portal/node/989493 ), as this would allow cloned accounts to exist for ease of exploring multiple solutions without cluttering the scoreboard.
The bottom line is that a distinction needs to be made between the following:
Running multiple accounts for the purpose of abusing the system, namely bumping other players down the rankings. I think most people would agree that this should be banned.
.
Running multiple accounts for legitimate purposes, such as exploring multiple solutions. Currently, this comes with the same problem as #1 (cluttering the scoreboard), which is why I suggested the secondary account idea as a stop-gap measure. But I still believe that the best long-term solution is to remove the need for multiple accounts in the first place by revamping the way that solutions are handled. One possibility is the following:
At the start of each puzzle, one starts working with trajectory #1 by default.
At any time, the player may choose to create additional trajectories. If this function is invoked, a copy of the current structure is made, and it becomes the recent/very best solution for the new trajectory. From now on, "recent/very best" refers to the high-scoring solutions of the new trajectory.
At any time, the player may switch between the existing trajectories to work on for the purpose of defining which structures "recent/very best" refer to.
.
========================================
The actual use of this new system might look like the following:
Trajectory 001:
[Current Trajectory = 001]
.
Trajectory 001:
[Current Trajectory = 001]
.
Trajectory 002:
[Current Trajectory = 002]
.
Trajectory 001:
Trajectory 002:
[Current Trajectory = 002]
.
========================================
==> The above proposed system comes with the advantage that all trajectories stay with one account. This is a huge advantage over using multiple accounts to work with alternative solutions, as the structures from the different trajectories would stay with the same account. The main difficulty I see is the sheer extent of programming required to make this system work. After all, for those who want to work with multiple trajectories simultaneously using a multi-core computer, there needs to be a function for saving/loading solutions associated with a specific trajectory rather than just the current one. Practically speaking, I don't see the fully-automatic multi-core processing of multiple trajectories (one per core) commonly done in Rosetta 3.x becoming reproducible in Foldit any time soon.
.
Another problem is that the sheer number of autosaves involved due to having a set of autosaves for every trajectory may make it difficult for the user to find a specific solution. One possible improvement might be redesigning the interface for loading/saving solutions by grouping the solutions by trajectory, such as the following:
[Local Solutions]
Trajectory 001
— "Autosaved Very Best Soloist Solution– Trajectory 002" / Score: 9500
— "Autosaved Recent Best Soloist Solution– Trajectory 002" / Score: 9450
— "Autosaved Credit Best Soloist Solution– Trajectory 002" / Score: 9400
Trajectory 002 <=== Current trajectory
— "Autosaved Very Best Soloist Solution– Trajectory 002" / Score: 9480
— "Autosaved Recent Best Soloist Solution– Trajectory 002" / Score: 9460
— "Autosaved Credit Best Soloist Solution– Trajectory 002" / Score: 9420
Manual Saves
— T001-S9500 rebuild / Score: 9387
Let's fix the problem
It's obvious there are valid reasons for using multiple accounts. infjamc and I have both pointed out weaknesses in teh client that require separate accounts, and Hanto has reasons for using separate accounts to be able to remotely monitor the activity on his multiple cores.
Instead of banning the use of multiple accounts which will cause a lot of bad feelings, please fix the client.
And , I believe it was AD who brought up this newly invented issue on the developer chat - so yes, AD started this thing.
Why would they kick out Hanto for doing something that wasn't against the "rules" of Fold.it. For that matter, what ARE the rules of Fold.it ?
and I think that infjamc's suggestion would solve everything
Players could have multiple accounts (which they all want for different reasons) but only their top scoring one would post on the scoreboard so new Foldit players do not become frustrated as easily
Foldit is frustrating enough already for new players
I don't think it matters who brought this up or who noticed this problem first, it might have been AD in chat but the feedback posting about it that B_2 referred to was created by CFC from Contenders fold.it/portal/node/989405
I don't think that pointing fingers or asking for someone's credentials or Long Form Birth Certificate will solve the problem ;)
To be absolutely clear, my attitude toward the usage of multiple accounts is "I can tolerate the practice but would not encourage it myself." (Full disclosure: I personally have no "need" for multiple accounts since I only run Foldit on my laptop, whose CPU only has 2 cores.) Plus, the reality is that fixing the system either through the designation of secondary accounts or through my above-mentioned "work with multiple trajectories" option will require extensive programming. Practically speaking, this means that those who use multiple accounts, even for legitimate reasons, will have an unfair advantage over other players for the foreseeable future even though they might never intend to cheat the system.
==> So, for the short term, I would recommend manually implementing the concept of "recent best" and "very best" in your recipes/scripts. It's cumbersome, but at least it works. The following is an example:
====================
Set recent best
Process structure
Reset to recent best
Process structure further
Reset to recent best
.
This can be re-written by first re-inventing the wheel, namely re-creating the function of recent bests and very bests using quicksave slots.
Function initialize():
Set traj to 1 //Trajectory number, can be 1, 2, or 3
Set s1 to (traj-1)3+1
//Determines the quicksave slot to be used for the current solution; this will translate to 1, 4, or 7
Set s2 to (traj-1)3+2
//Determines the quicksave slot to be used for the recent best solution; this will translate to 2, 5, or 8
Set s3 to (traj-1)*3+3
//Determines the quicksave slot to be used for the very best solution; this will translate to 3, 6, or 9
Quicksave to slot s1 //Further processing will be done on this structure
Quicksave to slot s2 //Set recent best
Quicksave to slot s3 //Simulates the "very best" solution
Score structure, then store the result as current_score, score_recentbest, and score_verybest
.
.
Function set_recentbest():
Quickload slot s1 //Current structure
Score structure and store the result as current_score
Quicksave to slot s2 //Overwrite recent best
Set score_recentbest to current_score //Update score of recent best
.
.
Function load_recentbest():
Quickload slot s2 //Recent best slot
Score structure and store the result as score_recentbest
Quicksave to slot s1 //Overwrite current structure
Set current_score to score_recentbest //Update score
.
.
Function load_verybest():
Quickload slot s3 //Recent very best slot
Score structure and store the result as score_verybest
Quicksave to slot s2 //Overwrite recent best
Quicksave to slot s1 //Overwrite current structure
Set score_recentbest to score_verybest
Set current_score to score_verybest
.
.
Function update_recent_and_verybest():
Quickload slot s2 //Recent best slot
Score structure and store the result as score_recentbest
Quickload slot s1 //Current structure
Score structure and store the result as current_score
If current_score > score_recentbest:
—- Quicksave to slot s2, and set score_recentbest to current_score
—- //Update the recent best if the current structure scores better
Quickload slot s3 //Very best slot
Score structure and store the result as score_verybest
Quickload slot s1 //Current structure
If current_score > score_recentbest:
—- Quicksave to slot s3, and set score_very to current_score
—- //Update the very best if the current structure scores better
// Note that this ends up with the current structure being loaded last whatever happens.
// This is intentional, to ensure that you're working on the current structure.
.
.
.
While cumbersome, this is a one-time investment; for future purposes, one only needs to copy and paste the above functions.
The main part of the program is actually very short:
set_recentbest()
process_structure()
update_recent_and_verybest() //Insert one instance of this function every time before saving or loading the recent best or very best
load_recentbest()
process_structure_further()
update_recent_and_verybest()
load_recentbest()
There is an error in one of the functions. The correct version is given below:
====================
Function update_recent_and_verybest():
Quickload slot s2 //Recent best slot
Score structure and store the result as score_recentbest
Quickload slot s1 //Current structure
Score structure and store the result as current_score
If current_score > score_recentbest:
—- Quicksave to slot s2, and set score_recentbest to current_score
—- //Update the recent best if the current structure scores better
Quickload slot s3 //Very best slot
Score structure and store the result as score_verybest
Quickload slot s1 //Current structure
If current_score > score_verybest:
—- Quicksave to slot s3, and set score_verybest to current_score
—- //Update the very best if the current structure scores better
// Note that this ends up with the current structure being loaded last whatever happens.
// This is intentional, to ensure that you're working on the current structure.
For those of you who want to use the pseudocode I've posted above, please note the following:
Before calling any function that deals with the quicksave-simulated versions of recent bests and very bests, *make sure that you have saved your current structure by adding the line "Quicksave to slot s1." I didn't add that to the functions listed above based on the assumption that this will be done in the "process structure" step, but you might want to consider adding that line (even if this creates redundancy) to prevent over-writing your current solution by mistake. Again, debug thoroughly…
A very simple option would be a button in the advanced UI which lets you completely reset a puzzle (including absolute best, quicksaves, undo timeline). It would effectively let you start the puzzle over from scratch. The only things that would remain would be your score on the scoreboard, and any manual saves you had done.
Is this a desirable option?