Add-ons listed by number of downloads by default?

[Dugi]

I know this is a bit close to frequently denied idea number 32, but the reply to it does not seem to answer to this.
I really think that listing the add-ons by age by default is absurd. Add-ons that were uploaded sooner are far more downloaded because of this, because they are at the beginning of the list, and thus people mostly download what is older, and not what is better.

As an example to justify what bothers me - the most downloaded add-on is Nightmares of Meloen, no offence to the authors, but I really doubt that people enjoy it so much. Second on the list is Love to Death, an unfinished campaign, apparently abandoned (read the description). Third is Era of Myths, that is an unanimated era, required by two unported campaigns. It has far more downloads than Archaic Era, that is almost animated and is required by at least two campaigns that were ported and are far more elaborated (BMR is IMO far better than Kromire).
Before, on 1.8, it was okay, as IftU was the first and it had the 100K downloads it deserved, but now...

[Iris]

I really think that listing the add-ons by age by default is absurd. Add-ons that were uploaded sooner are far more downloaded because of this, because they are at the beginning of the list, and thus people mostly download what is older, and not what is better.

That will not be the case in 1.11.0, amongst other things.

[Dugi]

What is the purpose of this? Well, the add-ons will not be rushed, uploaded even unported and so on, it makes the whole thing neutral, but I think that people will name everything 'A something something blablabla', to have an A at the beginning, or maybe even numbers.
You know that newbies don't give a damn about these filters when they venture to the add-on list for the first time.

[Hulavuta]

@dugi I sort of agree, but what alternative did you have in mind?

[Crow_T]

Can some kind of formula that takes into account important factors such as downloads, commit rate, last commit, stable, etc. be a default? Call it sort by active or something along those lines.

Edit btw new addon manager looks nice, I think more filter options would be good

[Dugi]

My former suggestion was to base it only on the download count, but when thinking about it, I would suggest to take into consideration also age (new things with the download count quickly increasing would go higher), completedness (this may be a problem, some incomplete things are pretty decent too, '7 scenarios, complete' and '90 scenarios, incomplete, though fully playable' is quite a problem to be compared, maybe length should be there instead), number of downloads that were just updates to new versions (not sure if this is needed, this actually motivates creators to develop their add-ons further). Last update is not the best thing to add, because complete campaigns and abandoned campaigns would be considered the same in this factor.

My suggestion is something like this:

Code: Select all

(number of downloads + A * number of downloads in the last week/month + B / age in weeks/months)*C

where A and B are some coefficients based on some statistics and C is another factor, that is 1.5 if the add-on is complete (I think it is really sad that IftU has only ~4500 downloads on the 1.9 server at the moment) and 0.5 if it is not much playable yet.
This should also motivate add-on creators to upload stuff that is complete to get as much as possible from the new add-on bump, to prevent the players from being bothered by downloading incomplete and unplayable things that would just frustrate them.

[ancestral]

I don’t think it needs to be complicated at all. All we need a “downloads in last month” criterion. This gives up and coming add-ons more attention. It’s not perfect (it favors add-ons which are updated more frequently as opposed to higher quality) but it’s a start.

[Iris]

Edit btw new addon manager looks nice, I think more filter options would be good

If you want more filter options, I’d love to hear of them in a separate topic in this section.

My suggestion is something like this:

Code: Select all

(number of downloads + A * number of downloads in the last week/month + B / age in weeks/months)*C

where A and B are some coefficients based on some statistics and C is another factor, that is 1.5 if the add-on is complete (I think it is really sad that IftU has only ~4500 downloads on the 1.9 server at the moment) and 0.5 if it is not much playable yet.
This should also motivate add-on creators to upload stuff that is complete to get as much as possible from the new add-on bump, to prevent the players from being bothered by downloading incomplete and unplayable things that would just frustrate them.

There are a few problems with this (besides the fact that you left the A and B coefficients unspecified and that the most maths I can do is adding 1 and 1):

• We don’t currently have a way to track whether an add-on is complete or not, and authors may decide an add-on is complete when it actually isn’t, or even the other way around. I know I’m guilty of this in a way, because AtS was supposed to be completed with two episodes in version 1.0.0 and the third one would be a bonus extended epilogue for version 2.0.0; that plan changed when I realized 1.0.0 would be unfeasible for longer than it would take Ep. III to be completed.
  I have seen a lot of proposals to address this, but none seem really convincing to me—being pretty much the only developer who gives a crap about the in-game add-ons client since 1.5.x—and I have never seen anyone from the user community submit patches on the matter.
• The add-ons server only tracks the number of downloads and uploads, and nothing else about them; so, things like the amount of downloads per week aren’t available at this point. However, we do have a timestamp, which is the time of the last upload.

The primary reason I chose to use alphanumerical title sorting as the fallback method is because it feels the most natural for me after using Synaptic Package Manager (a graphical front-end for apt on Debian systems) for so many years. There, packages are initially sorted by their id, which is guaranteed to be unique (incidentally, add-on titles are not).

The secondary reason is that it felt like the only option where users would obviously notice (unless they don’t know how the Latin alphabet works) that there are no implicit warranties of any kind, such as quality, popularity or otherwise, unlike the previous method (or lack thereof, in fact). The other reason is that it was the easiest to implement at the time.

[Dugi]

We don’t currently have a way to track whether an add-on is complete or not, and authors may decide an add-on is complete when it actually isn’t, or even the other way around. I know I’m guilty of this in a way, because AtS was supposed to be completed with two episodes in version 1.0.0 and the third one would be a bonus extended epilogue for version 2.0.0; that plan changed when I realized 1.0.0 would be unfeasible for longer than it would take Ep. III to be completed.
I have seen a lot of proposals to address this, but none seem really convincing to me—being pretty much the only developer who gives a crap about the in-game add-ons client since 1.5.x—and I have never seen anyone from the user community submit patches on the matter.

The version number says nothing, I agree, my add-on has also pretty much defunct numbering, I finished it with 1.0.0, but then I decided to work on it again after some time, and...
But I meant something like adding one more information required to the pbl files, and that would be whether it is complete or not (missing values considered as incomplete?). This was already suggested.

The add-ons server only tracks the number of downloads and uploads, and nothing else about them; so, things like the amount of downloads per week aren’t available at this point. However, we do have a timestamp, which is the time of the last upload.

So the downloads per week could be simply calculated by dividing the download count by the amount of time it is on the server, no?

The primary reason I chose to use alphanumerical title sorting as the fallback method is because it feels the most natural for me after using Synaptic Package Manager (a graphical front-end for apt on Debian systems) for so many years. There, packages are initially sorted by their id, which is guaranteed to be unique (incidentally, add-on titles are not).
The secondary reason is that it felt like the only option where users would obviously notice (unless they don’t know how the Latin alphabet works) that there are no implicit warranties of any kind, such as quality, popularity or otherwise, unlike the previous method (or lack thereof, in fact). The other reason is that it was the easiest to implement at the time.

Anyone can see that in Synaptic, it is visible that it is ordered in alphabetical order, but on the 1.11 add-on listing, it is not easy to notice it. Several first add-ons are not listed in alphabetical order (Multiplart Campaign, 18th century warfare, Infection Era, Overworld are the first add-ons on the list, only 18th century warfare seems to be in a proper position; not sure how it is on the latest versions, I have a relatively old version, 1.11.0-svn 53685), and thanks to this, I haven't even noticed they were ordered alphabetically.

But generally, I agree that it is not so bad to do it like that, to make it obvious that the player has to list the add-ons in a different way, but what would 90% players do then (supposing they aren't in search of a particular one)? List them by number of downloads, or by time upload and see what has more downloads than average.

[Pentarctagon]

The add-ons server only tracks the number of downloads and uploads, and nothing else about them; so, things like the amount of downloads per week aren’t available at this point. However, we do have a timestamp, which is the time of the last upload.

So the downloads per week could be simply calculated by dividing the download count by the amount of time it is on the server, no?

That would give the average number of weekly downloads, not the number of downloads in the last week.

[Iris]

Anyone can see that in Synaptic, it is visible that it is ordered in alphabetical order, but on the 1.11 add-on listing, it is not easy to notice it. Several first add-ons are not listed in alphabetical order (Multiplart Campaign, 18th century warfare, Infection Era, Overworld are the first add-ons on the list, only 18th century warfare seems to be in a proper position; not sure how it is on the latest versions, I have a relatively old version, 1.11.0-svn 53685), and thanks to this, I haven't even noticed they were ordered alphabetically.

As a rule of thumb, if you are testing trunk, you must test the latest revision before reporting bugs or providing feedback. I changed the sorting algorithm again some weeks ago in [rev]54224[/rev] because I was aware of the issue with add-on titles not matching—or resembling, at the very least—their identifiers more often than I’d personally prefer. The only reason I didn’t use titles from the very beginning was that it would involve a lot of additional or reinvented wheels, as the commit shows; there’s a lot of room for cleanup in that area at the moment, but I wanted to get the user-visible details finished as soon as possible for 1.11.0. (Not to mention that I’m still making a Wesnoth add-on, which is an absurdly energy-consuming task compared to mainline programming.)

[Dugi]

...

That would give the average number of weekly downloads, not the number of downloads in the last week.

You don't say?

The meaning of this was to tell how frequently was the add-on downloaded, not just how many people downloaded it. It is not really important if it was in the last week or in average. In fact, the average value is better, because an add-on that is newly updated would jump very high otherwise.

As a rule of thumb, if you are testing trunk, you must test the latest revision before reporting bugs or providing feedback.

That is why I told which version I had, for the case if you had fixed it.

But generally, I agree that it is not so bad to do it like that, to make it obvious that the player has to list the add-ons in a different way, but what would 90% players do then (supposing they aren't in search of a particular one)? List them by number of downloads, or by time upload and see what has more downloads than average (this is actually better, but...).

Can I get an answer why you don't agree with this?
Alphabetical order is nicely neutral, and would make people use filters, but I suppose that most people would list them in the way I said, and listing them by download count would make it just more comfortable.

[JaMiT]

I really think that listing the add-ons by age by default is absurd. Add-ons that were uploaded sooner are far more downloaded because of this, because they are at the beginning of the list, and thus people mostly download what is older, and not what is better.

I fail to see how an initial sort by number of downloads would change the situation. When a new add-on is added, it has no downloads, so would still be at the end of the list. By your own reasoning, being at the end of the list would result in fewer downloads, keeping it towards the end of the list until newer add-ons take over the end of the list. Even if you look at just downloads over the past month, a brand new add-on faces the same sort of hurdle, just one that is a bit smaller.

If your reasoning is correct, then an initial sort by downloads should be little different than an initial sort by age. In theory, at least. Is there something else affecting things?

The meaning of this was to tell how frequently was the add-on downloaded, not just how many people downloaded it. It is not really important if it was in the last week or in average. In fact, the average value is better, because an add-on that is newly updated would jump very high otherwise.

For an updated add-on, if you assume people are eagerly looking for such an update, I suppose there could be a spike in downloads (if updates are included in the download count). On the other hand, is that bad, given your goal of more exposure for overlooked add-ons? Downloading an update would indicate that the add-on was not outright deleted, so it must have some sort of redeeming value.

For a new add-on, however, the situation is reversed. An add-on that is newly added would jump very high with the average per week, not so much with the number of downloads in the past week. If an add-on has 100 downloads in its first day, then it has had 100 downloads in the past week, but is averaging 700 downloads per week. (100 downloads / (1/7 of a week since it was added) = 700.) Again, this might be desirable, except you presented jumping very high as being the less desired option.

[Anonymissimus]

I have doubts about download count being an important factor to sort addons.
Firstly, someone who uploads frequently small changes will get a higher download count or rate due to his players updating their addons than someone who rather seldom uploads many changes. None of these methods is better or worse than the other in the first place.
Secondly, imagine someone uploads a major new version, but then a lot of fixes to it are required causing a lot of updates; this versus another one with the same amount of changes but which works out of the box without additional uploads. The first gets the higher count, but the second is obviously better in that aspect. (I also notice this kind of "punishment" in addon threads where people with buggy addons get bug report posts and thus their thread gets more attention.)

I think that the addon order should be randomized, which I consider fair and perhaps is not too complicated to implement.

[Dugi]

If your reasoning is correct, then an initial sort by downloads should be little different than an initial sort by age. In theory, at least. Is there something else affecting things?

No. This was my point. It would start at the end, but would ascend higher and higher, until it gets a position it deserves.

For an updated add-on, if you assume people are eagerly looking for such an update, I suppose there could be a spike in downloads (if updates are included in the download count).

It would be better if there were not counted, but updates should move the add-on higher, just to motivate authors to look for things to improve in their add-ons, even if they are finished.

For a new add-on, however, the situation is reversed. An add-on that is newly added would jump very high with the average per week, not so much with the number of downloads in the past week. If an add-on has 100 downloads in its first day, then it has had 100 downloads in the past week, but is averaging 700 downloads per week. (100 downloads / (1/7 of a week since it was added) = 700.) Again, this might be desirable, except you presented jumping very high as being the less desired option.

Ideally, new add-ons should jump high, but not so high to get before the most popular add-ons.

I have doubts about download count being an important factor to sort addons.
Firstly, someone who uploads frequently small changes will get a higher download count or rate due to his players updating their addons than someone who rather seldom uploads many changes. None of these methods is better or worse than the other in the first place.
Secondly, imagine someone uploads a major new version, but then a lot of fixes to it are required causing a lot of updates; this versus another one with the same amount of changes but which works out of the box without additional uploads. The first gets the higher count, but the second is obviously better in that aspect. (I also notice this kind of "punishment" in addon threads where people with buggy addons get bug report posts and thus their thread gets more attention.)

I think that updates should not count into the download count, like I said before.
I agree that the download count does not indicate too much at the moment, but I believe that it might if it was done like I said.

And as I said, if it was listed randomly by default, most people would list it then by download count or age then anyway.