Scriipts changes by author

Started by spmm

spmm Lv 1

Sciipts in foldit can be changed by the author at any time without the user knowing about the change, results of the change may be inadvertent, or may be gaming.
Unless you made a script copy you are at their mercy.
Which is why its a bug.

spmm Lv 1

Unless that is not clear, any change to a script needs to be made explicit to a user, in that they need to access a new version. Which may or may not be better for their purpose.

Angus Lv 1

Are you trying to say that scripts in the all.macro file auto-update themselves from the web site without the user downloading a new copy ?

gitwut Lv 1

I think he saying that something needs to be done about recipe sharing as regards version handling. The problems arising from an author "overwriting" an existing recipe–intentionally or not. It would probably introduce changes without any indication to a user who might be downloading it again either to a different computer or re-downloading it because their all.macro file got trashed. Two people could be talking about a recipe with the name "script1.2.3" (e.g.)but it could be two different versions of the same script that behave differently(e.g., one is designed for NC and the other isn't).

OTOH, he could be talking about something entirely different. If so, what I've mentioned above is something I've considered before but never bothered to write up and may be worth discussing.

jeff101 Lv 1

In the all.macro file, each recipe has an mid and an mrid. For example, Tvdl enhanced DRW 1.2.4b has mid 45032 and mrid 99740. scriptlog.default.xml files made with this recipe begin with the following:

<Foldit:MacroID>45032</Foldit:MacroID>
<Foldit:MacroRevisionID>99740</Foldit:MacroRevisionID>

Finally, the recipe itself can be downloaded from http://fold.it/portal/recipe/45032

Does the mrid (MacroRevisionID) change when the original author uploads a new version of the recipe to the Foldit site?

AsDawnBreaks Lv 1

Yeah, how about implementing some actual version control? It's probably more difficult and a lower priority, but it would be cool to see at some point.

Angus Lv 1

OK, so it's only going to overwrite if I delete it from all.macro and re-download.

I'm OK with that, that comes with the territory of free and loose scripting. I don't expect anything to be static except what I have already downloaded.

Angus Lv 1

OK, so it's only going to overwrite if I delete it from all.macro and re-download.

I'm OK with that, that comes with the territory of free and loose scripting. I don't expect anything to be static except what I have already downloaded.

Bruno Kestemont Lv 1

I don't think it's a bug. A suggestion, yes.

Indeed, track of latest version is possible through the date on the recipe list:
http://fold.it/portal/recipes
(recent updates are on top)

But we do not see it on our client. The only way to be sure we have the latest version is to delete the recipe from our client and load it again from the server.

Usually, authors change version number and sub-nummer when there are big changes, and inform the players (in the recipe comments and within the script). Personal versioning (before the release) is not very interesting for the final user.

Personally, I now try to follow tvdl usage (he whrote it somewhere in the feedback, but i don't find the topic):

  • ver 9 = big changes (including dialog changes), same overall strategy. New recipe id and name.

  • ver 9.9 (first digit) = bug fixes, enhanced sub-routines (e.g. in wiggle strategy), no change in the dialogs or in the options. New recipe id and name.

  • ver 9.9.9 = invisible changes (e.g. log changes, language errors in dialog etc), or marginal modifications that do not fundamentally change the recipe behavior. Small marginal bug fixing (bugs that occurs rarely in very specific situations). Same recipe ID and name. Version and modifications displayed on the recipe comments and within the recipe code. Recipe keeps it's stars.

-ver 9.9.9(label). e.g. ver 9.9.9 (NC) or 9.9.9FR = new ID and name in case of adaptation to something (e.g. NC) or translation to another language. Or labels like ver 9.9.9beta or 9.9.9test for private or group share only for testing. Even if the recipe strategy do not change, there is a new ID and name here.

-simple new save, no new version number (recipe appears on the server with new date, on top of recipe list): very minor changes without implication for the user. For example cleaning of the recipe (variable duplicates), small log changes (better English etc), marginal reorganization of the internal structure of the script (separate function replacing internal code) etc. Recipe keeps its stars. In this case, I usually do not document the changes, neither within the code neither on the server.

spmm Lv 1

Imo this last example should be an explicit point change, not just a save which is invisible to the user (unless they ferret about for dates which may be several pages back in the recipe list) and may introduce errors or unexplained changes:

'-simple new save, no new version number (recipe appears on the server with new date, on top of recipe list): very minor changes without implication for the user. For example cleaning of the recipe (variable duplicates), small log changes (better English etc), marginal reorganization of the internal structure of the script (separate function replacing internal code) etc. Recipe keeps its stars. In this case, I usually do not document the changes, neither within the code neither on the server.'

As it is identical to:
'- ver 9.9.9 = invisible changes (e.g. log changes, language errors in dialog etc), or marginal modifications that do not fundamentally change the recipe behavior. Small marginal bug fixing (bugs that occurs rarely in very specific situations). Same recipe ID and name. Version and modifications displayed on the recipe comments and within the recipe code. Recipe keeps it's stars.'