When projects were being managed on curse.com directly, we could set specific files as being the default download. This has apparently vanished with curseforge, and while the default (no pun) behavior is almost always the right thing to do, sometimes it isn't. And when it isn't, the author is boned.
Hawksy's comment on that ticket gives a concise description of why this is needed; when things go wrong, manually setting the default download is the only solution, but that's not available anymore, and there are no functioning workarounds.
Why are you uploading older versions or making new tags of old versions? If this is allowed then people will abuse it again to upload multiple different projects on the same Curse project.
I'm doing neither of those. I'm uploading more than one file at a time (a basic version and an extended version, for example, but there are other scenarios). Curseforge is picking one of the uploads apparently at random to be the default. This has nothing to do with making tags; I don't use wowace repos.
Me thinks you need to rework your methods to accomidate the system that is in place.
If your addon has 2 versions of it, then use the .pkgmeta to move the files around and setup your extended addon to be disabled by default. This will allow for "2 addons" to work on one repo but in practice they are the same thing. Look at Prat or Xperl works in how their addons are packaged.
They use the .pkgmeta to move folders out to the root addon listing. Those "stub" addons then when enabled load additional / optional files that enhanse the addon.
Again, this isn't for a wowace repo, so .pkgmeta doesn't apply. It's just a zip file upload to curseforge. My addons are kept in a home svn, alongside non-WoW projects.
If the previous feature is just going to be abandoned wholesale, perhaps one of you would be so kind as to explain why in the ticket above, and then please close it so that we're not hanging around waiting?
if this home svn repo is available from the internet, setup your pkgmeta to pull from it as an external. Then use the move-folders attrib to move the files around accordingly.
I've given up on trying to offer variants of addons. The working simple system has been replaced by something which tries to be smarter than the author. For now I've just deleted all the other versions of the addon, and uploaded a new generic version to force it to be treated as the latest.
This has prevented me from uploading optional goodies for my addons on Curse as well. I'm sure Curse fans don't really appreciate having to click a link to WoWI in my addon description to get the extra stuff. :|
If this is allowed then people will abuse it again to upload multiple different projects on the same Curse project.
Since every single upload still has to be approved by hand, this strikes me as something of a strawman. If you don't like the file, don't approve it -- but don't prohibit us from managing the files which are approved.
Why are you uploading older versions or making new tags of old versions? If this is allowed then people will abuse it again to upload multiple different projects on the same Curse project.
When I push a project to aceforge, all the old tags get pushed as well. I'm not MAKING new old tags, they're just, ya know, part of the repo's history...
I'm doing neither of those. I'm uploading more than one file at a time (a basic version and an extended version, for example, but there are other scenarios). Curseforge is picking one of the uploads apparently at random to be the default. This has nothing to do with making tags; I don't use wowace repos.
I believe you need to make 2 projects. One for your "normal" version, and one for your extended" version.
A project cannot really have "2 latest zips" for the purposes of displaying the latest one to be downloaded, and will mess up updaters as well.
Unfortunately this also means that Curse cannot offer -nolib zips, so it's easier for me to subscribe to file updates on WoWAce/CurseForge that it is to just mark addons as favorites on Curse. I don't generally need the latest dev version, and for addons like BigWigs this means I get messages listing 20+ new files for the same project on a daily basis, but it takes longer and is bothersomely wasteful to download 200kb in libs for a 20kb addon to fix a typo on a single line... and before anyone points it out, no, I don't use the Curse Client.
..wasteful to download 200kb in libs for a 20kb addon to fix a typo on a single..
Sorry, when i read stuff like this I just have to put in perspective that 200kb is so insignificant it's not funny. Your computer every few hours spends about 200kb to update the time on your compter. Every few days it spends prolly 1.5mb to download an update index from microsoft.com.
Just to put in perspective how small and insignificant 200kb really is. However I will give in on this point if your on a throttled bandwidth connection. But you only really see that outside the US.
---------
As for what your trying to do Farmbuyer, Phanx, you might want to re think how your doing your distribution.
@Farmbuyer, one solution if you don't want to seperate out your addon and use a different repo then I've got a few options.
-Package the 2 addons as one zip, and setup the extended version as disabled by defualt & Accomidate the setup that way...
-Setup a firewall rule for your SVN server there. Then setup .pkgmeta to pull the addon as externals and to arrange the addon correctly. You can do a lot of magic with .pkgmeta
@ Phanx. You say you have alot of "Extras" for your addons? Add them to the repo as seperate folder in the svn trunk. Then use the .pkgmeta to move these folders out and setup these addons as disabled by default or a reasonable set of defaults. Then adjust the paperwork accordingly.
These ideas while they might not be optimal, are in fact functional.
It is insignificant, and nowhere did I say anything was funny, but that's not the point. The point is that it's idiotic to download something when I'm just going to delete 90% of it.
As for your suggestion, I, like the OP, do not use a WoWAce or CurseForge repo, so .pkgmeta does not apply... funny how the OP has clearly stated that he's talking about manual file uploads and everyone keeps giving suggestions based on .pkgmeta functions. :lol:
well the .pkgmeta has alot of options that would provide for the needs stated. The manual-file upload dosn't have the same features. This entire method with wowace and curseforge is designed specifically for the use of the Repo's, so that's why alot of sugestions say to use it.
WoWI is, in my experiance, more suited for file uploads and not using a repo. Although WoWI does have their own repo system, the bulk of their tools IIRC are for files and not repos
Sorry, when i read stuff like this I just have to put in perspective that 200kb is so insignificant it's not funny.
For a single addon and a single user, yes. But when you take that insignificant size times the average number of users downloading the file times the average frequency it's updated... well if it was still an insignificant amount of bandwidth, all the wowmatrix shit wouldn't have been an issue.
When I push a project to aceforge, all the old tags get pushed as well. I'm not MAKING new old tags, they're just, ya know, part of the repo's history...
I think Ckknight knows about this and acknowledged its a bug that he wants to fix. Since git tags are timestamped he wanted to make them be placed in chronological order on the files page by creation instead of time pushed.
That or I am mixing this up with one of the keyword replacements using tag push time instead of the timestamp from the tag. In that case you'll have to poke him about this issue and see if it could and would be fixed.
Aye, timestamp would be better to use than push time for anno tags. It's not a huge deal though... was just saying there is valid reason for pushing up old tags.
well the .pkgmeta has alot of options that would provide for the needs stated. The manual-file upload dosn't have the same features. This entire method with wowace and curseforge is designed specifically for the use of the Repo's, so that's why alot of sugestions say to use it.
Right, but when people are consistently saying, "I don't use the repo, I upload files by hand", and other people keep saying "just put _____ in your pkgmeta!", it feels like the "other people" just aren't reading. :p
WowAce does not allow you to upload files by hand. This is a WowAce forum.
However the irony is, I was just looking at that ticket and saw this thread.
I'm not familiar with the kinds of "extras" that would added to the project, but I do think you may want to consider a redoing your processes. The way I'm looking at it, could these extras be treated as modules?
If not, then maybe the ticket should be to add support for the extras you're talking about and not setting a file as default.
On a side note, there is a bit of a "hack" you can use to get around this.
If you mark your extras as beta/alpha, the release version will be the default download IIRC.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
There's been a ticket open on this problem since last July:
http://www.curseforge.com/projects/curseforge/tickets/367-set-a-file-as-default/
Hawksy's comment on that ticket gives a concise description of why this is needed; when things go wrong, manually setting the default download is the only solution, but that's not available anymore, and there are no functioning workarounds.
It's still in "New" status after 10 months.
If your addon has 2 versions of it, then use the .pkgmeta to move the files around and setup your extended addon to be disabled by default. This will allow for "2 addons" to work on one repo but in practice they are the same thing. Look at Prat or Xperl works in how their addons are packaged.
They use the .pkgmeta to move folders out to the root addon listing. Those "stub" addons then when enabled load additional / optional files that enhanse the addon.
If the previous feature is just going to be abandoned wholesale, perhaps one of you would be so kind as to explain why in the ticket above, and then please close it so that we're not hanging around waiting?
if this home svn repo is available from the internet, setup your pkgmeta to pull from it as an external. Then use the move-folders attrib to move the files around accordingly.
Just an idea.
I've given up on trying to offer variants of addons. The working simple system has been replaced by something which tries to be smarter than the author. For now I've just deleted all the other versions of the addon, and uploaded a new generic version to force it to be treated as the latest.
Since every single upload still has to be approved by hand, this strikes me as something of a strawman. If you don't like the file, don't approve it -- but don't prohibit us from managing the files which are approved.
When I push a project to aceforge, all the old tags get pushed as well. I'm not MAKING new old tags, they're just, ya know, part of the repo's history...
I believe you need to make 2 projects. One for your "normal" version, and one for your extended" version.
A project cannot really have "2 latest zips" for the purposes of displaying the latest one to be downloaded, and will mess up updaters as well.
Sorry, when i read stuff like this I just have to put in perspective that 200kb is so insignificant it's not funny. Your computer every few hours spends about 200kb to update the time on your compter. Every few days it spends prolly 1.5mb to download an update index from microsoft.com.
Just to put in perspective how small and insignificant 200kb really is. However I will give in on this point if your on a throttled bandwidth connection. But you only really see that outside the US.
---------
As for what your trying to do Farmbuyer, Phanx, you might want to re think how your doing your distribution.
@Farmbuyer, one solution if you don't want to seperate out your addon and use a different repo then I've got a few options.
-Package the 2 addons as one zip, and setup the extended version as disabled by defualt & Accomidate the setup that way...
-Setup a firewall rule for your SVN server there. Then setup .pkgmeta to pull the addon as externals and to arrange the addon correctly. You can do a lot of magic with .pkgmeta
@ Phanx. You say you have alot of "Extras" for your addons? Add them to the repo as seperate folder in the svn trunk. Then use the .pkgmeta to move these folders out and setup these addons as disabled by default or a reasonable set of defaults. Then adjust the paperwork accordingly.
These ideas while they might not be optimal, are in fact functional.
As for your suggestion, I, like the OP, do not use a WoWAce or CurseForge repo, so .pkgmeta does not apply... funny how the OP has clearly stated that he's talking about manual file uploads and everyone keeps giving suggestions based on .pkgmeta functions. :lol:
WoWI is, in my experiance, more suited for file uploads and not using a repo. Although WoWI does have their own repo system, the bulk of their tools IIRC are for files and not repos
For a single addon and a single user, yes. But when you take that insignificant size times the average number of users downloading the file times the average frequency it's updated... well if it was still an insignificant amount of bandwidth, all the wowmatrix shit wouldn't have been an issue.
I think Ckknight knows about this and acknowledged its a bug that he wants to fix. Since git tags are timestamped he wanted to make them be placed in chronological order on the files page by creation instead of time pushed.
That or I am mixing this up with one of the keyword replacements using tag push time instead of the timestamp from the tag. In that case you'll have to poke him about this issue and see if it could and would be fixed.
Right, but when people are consistently saying, "I don't use the repo, I upload files by hand", and other people keep saying "just put _____ in your pkgmeta!", it feels like the "other people" just aren't reading. :p
WowAce does not allow you to upload files by hand. This is a WowAce forum.
However the irony is, I was just looking at that ticket and saw this thread.
I'm not familiar with the kinds of "extras" that would added to the project, but I do think you may want to consider a redoing your processes. The way I'm looking at it, could these extras be treated as modules?
If not, then maybe the ticket should be to add support for the extras you're talking about and not setting a file as default.
On a side note, there is a bit of a "hack" you can use to get around this.
If you mark your extras as beta/alpha, the release version will be the default download IIRC.