> "In the 1st, adding a constant to all playcounts will not effect the ordering, so this does nothing."

Sure, it doesn't do anything to the animations that I have already downloaded. My concern is rather that when new animations appear, they have playcounts that are much lower than the already downloaded animations. (As background, my perspective is as someone for whom the screensaver has been running for a while, so that playcounts are quite high.) As a result, when new animations are downloaded, they get played over and over again until I recognize them immediately and am sick of them. I want to see more of my beloved older sheep! If we lower the playcounts of the existing animations by subtracting a constant, this solves the problem.

To summarize, my basic reply is that adding a constant to all of the playcounts doesn't do anything to effect the ordering between the existing animations. However, because new animations come in with a playcount of 0, it will greatly affect where they fit in the ordering.

Another solution to preventing the very heavy repetition of the new sheep for people who run the screensaver a lot is what you included in this release. Rather than subtracting a constant, you multiply playcounts by a number less than 1. I prefer subtracting a constant because suppose I have an two animation. One of them, because of the structure of edges, has run 100 times. The other doesn't have as favorable edges and hasn't been in my library as long, so it has only run 40 times. The second one, (let's call it the runt) must be played 60 time before parity is achieved. I like that, because I want to see it many times to make up for the number of times I've seen the other one, which I'm probably tired of. If we multiply the playcounts by a number less than one, say .5, then the gap between the runt and the other one (alpha sheep, perhaps? :-) ) narrows from 60 to 30. I don't want the gap to decay like this, because parity will be achieved with far fewer plays of the runt. I'd much rather that we simply subtracted 30 playcounts from both of them, so that the playcounts become 10 for the runt and 70 for the alpha (gap is still 60). That way the runt will need to be played heavily AND the new sheep will also get played heavily. However, the alpha, whom I'm sick of, won't get played as heavily.

> "In the 2nd, replacing a constant by the difference between two constants changes nothing."

Sorry, my hands were on autopilot. I meant
NewPlayCount := PlayCountDecayZ * ( OldPlayCount - PlayCountConstant )
It's isomorphic to the first version, but I think it might be more intuitive for people to see that "PlayCountConstant" should be between 0 and the average number of times each animation gets played between the PlayCountDecay equation being applied.

For simplicity, you can always constrain the PlayCounts to be positive. I.e.
NewPlayCount := Max(PlayCountDecayZ * ( OldPlayCount - PlayCountConstant ), 0)
That seems like a good way to avoid bugs.

Also, to keep the system stable, people would probably want to set PlayCountDecayZ strictly less than 1 if PlayCountConstant was positive, so that any weirdness decays over time.

Anyone who messes with config files had better be both smart and careful, but if they do these two things, this should compensate for any errors that they make.

It's a percent, which means multiplication by a value less than one, which is decay.

50 = 50/100 = 1/2 means the playcounts are divided by 2.

Hey Spot, No worries about it being broken, I found the file to change it myself. Looking forward to the next release! Also, out of curiosity, is the login function also not working? When I go back to the E-Sheep settings dialog, it always shows me as not yet logged in, even if I had the last time I was there? Is there a way I can manually edit that as well?