CC can't update from WoWUI, so it won't find any download link from there.
I did not say that CC should update from wowui. I did not say that CC should find any link on wowui. I only said where I (again, I, and not CC) downloaded it. CurseClient should download it from Curse. And not only it failed to check its version (again, via Curse site, where this addon does exist). It even did not find it among its addons list.
I installed CC only today. Which means that I installed all addons before CC's first launch.
CC's "scan" feature doesn't work that well. You'll get much better results if you kill all your add-ons and reinstall them using the CC. It will then match them up correctly and there will be no ambiguity. This is also a good time to verify that each of your add-ons has indeed been updated to 3.0.2, as many of them won't have been. This is standard procedure for a major WoW version upgrade (remember this is only the second time this has ever happened in 4 years).
CC's "scan" feature doesn't work that well. You'll get much better results if you kill all your add-ons and reinstall them using the CC. It will then match them up correctly and there will be no ambiguity. This is also a good time to verify that each of your add-ons has indeed been updated to 3.0.2, as many of them won't have been. This is standard procedure for a major WoW version upgrade (remember this is only the second time this has ever happened in 4 years).
Yes, seems you are right relating reinstall via CC. There are only two questions left:
1) Since I have more than 300 addons (some of them are enabled, some are not), I prefer some automatic way. Otherwise I'll spend the rest of my life for distinguishing between those addons, which can be installed via CC, and those, which can't.
2) I did not have (if I remember right) such problems with WAU. It recognized addons versions properly, and updated those, which should be updated. It left intact those addons that had their latest versions installed, or those which WAU did not recognize (such as non-ACE addons).
What do we see with CurseClient? (1) does not work (no automatic way to update addons that were installed not via CC). (2) also does not work, while it worked in WAU.
So why break something that works?
Yes, I saw those famous threads about the [traditional] financial reasons. But if Curse wants to eat WowAce, and if WowAce wants to be eaten by Curse, maybe it would be more simple to only change hosting base - providing format compatibility? WAU would work by the same way, but referring to Curse site instead of WowAce site. Why not?
Now let's assume there were reasons to do it by that way, which we all see. But in this case why some people try to convince us that CurseClient provides the same - or even better - functionality than WAU did?
1) Since I have more than 300 addons (some of them are enabled, some are not), I prefer some automatic way. Otherwise I'll spend the rest of my life for distinguishing between those addons, which can be installed via CC, and those, which can't.
Turn off "Scan for Addons" in CC. Empty your add-ons folder (back it up first). Use CC to install all add-ons you can find on Curse. This will include every Ace add-on. Make a list of the add-ons you couldn't find on Curse and install them manually from another site. These manually installed add-ons will never be touched by CC. I have 180 add-ons and only 3 of them did not have brand new, up-to-date versions on Curse. Those 3 I subscribed to as favorites on WoWI. YMMV.
2) I did not have (if I remember right) such problems with WAU. It recognized addons versions properly, and updated those, which should be updated. It left intact those addons that had their latest versions installed, or those which WAU did not recognize (such as non-ACE addons).
What do we see with CurseClient? (1) does not work (no automatic way to update addons that were installed not via CC). (2) also does not work, while it worked in WAU.
So why break something that works?
Yes, I saw those famous threads about the [traditional] financial reasons. But if Curse wants to eat WowAce, and if WowAce wants to be eaten by Curse, maybe it would be more simple to only change hosting base - providing format compatibility? WAU would work by the same way, but referring to Curse site instead of WowAce site. Why not?
Now let's assume there were reasons to do it by that way, which we all see. But in this case why some people try to convince us that CurseClient provides the same - or even better - functionality than WAU did?
WAU was able to tell versions due to an extra XML file it placed in the add-on folder. Every WowAce add-on used one unified versioning system because they were all part of a single SVN repository. This is no longer the case, and there is no longer a unified versioning system. WAU did not look into add-ons you had installed manually and figure out their revision. You had to install it using the updater or update it once for it to know what you were running.
Nobody here has ever said that CC is the same or better than WAU. Certain things cannot be done better or differently in CC. Certain other things will be done better as the developers have more time to fine tune it. Going forward, your constructive thoughts on ways to improve the updater would be appreciated. No, it cannot at this time determine the exact version of every add-on you manually installed yourself. That will almost definitely never happen. There are some other threads on this forum discussing possible ways to embed metadata in every add-on to achieve this. You would have seen if you read them, however, that such a notion is a long shot at best, and probably won't happen.
What you didn't realize when you posted this, is that simply changing hosting providers wouldn't have helped the myriad of issues the WowAce developers were facing. Most if not all of the changes to the hosting platform have been done in such a way as to improve the developer experience on WowAce. I think most developers would agree that they have been successful with this for the most part. Leaving WowAce as it was may have benefited you, but it certainly did not benefit us. That is why you'll see so many devs on this forum complaining about user entitlement attitudes.
...Every WowAce add-on used one unified versioning system because they were all part of a single SVN repository. This is no longer the case, and there is no longer a unified versioning system...
Why?
In other words - why changing hosting/sponsor/whatever should break version handling? Was it bad?
2) Found strange bug (?) (don't know if this is the proper thread): as I said I installed all addons before CC. Now I decided to reinstall all Bigwigs addons via CC. I selected all of them in "Find an Addon", then clicked on install. Success. Now we return to the "World of Warcraft" tab, and see only some of the "Bigwigs*" addons. E.g., "Bigwigs Bossmods" is not in the list, and I think "BigWigs_DispelResist" also was not there. Repeated - got the same situation. But manual install of each of them through "Find an Addon" tab - without using selection - helped.
Edit because of Allara's edit: Users will always have some complains if something that worked becomes broken. Users will have much more complains if such spoil was done deliberately. Users will overflow with complains if they don't understand the reason of this deliberate spoil.
In other words - why changing hosting/sponsor/whatever should break version handling? Was it bad?
Yes. Every single addon project was in the same repository - which had an open-access policy. This enabled files.wowace.com, and therefore the WAU, to exist as they did. It also allowed ANYONE to edit the addons.
Every time someone in Czechoslovakia (and other non-English-speaking countries) decided the translation in an addon needed updated (and sometimes there were competing translators), the file packager marked the entire addon as being updated. Every time an Ace library was updated, every addon which used it was re-packaged as being updated. This created bandwidth-usage for no reason. The addon wasn't actually updated - yet thousands of people downloaded it anyway. And there were those who updated several times a day.
New system: A single repository per addon. Only the author (or those he/she chooses) has access. There will eventually be a system in place for translators, but they will not be able to touch the addon itself.
Thanks Torhal. Also: now each project gets it's own wiki and ticket tracker. Comments are segregated by project instead of massed into a forum. Multiple types of source control are supported (this is a BIG one). Three types of releases are now supported (alpha/beta/release). The list goes on and on, and I'm tired of defending it.
"Tickets" 818 through 821 are the same issue, so I didn't create a duplicate ticket.
-neo
My results are similar to yours.
I do actually get some responses from the server (can't read 'em 'cuz it's using gzip), but the interesting thing is: If I snoop a firefox connection, I see real data for headers, but then it goes to gzip for page bodies. When I snoop the client, it starts out sending gzipped stuff from the beginning, and gets back only more stuff which looks gzipped.
I do actually get some responses from the server (can't read 'em 'cuz it's using gzip), but the interesting thing is: If I snoop a firefox connection, I see real data for headers, but then it goes to gzip for page bodies. When I snoop the client, it starts out sending gzipped stuff from the beginning, and gets back only more stuff which looks gzipped.
I can't remember the options for snoop, I really kind of hate Solaris ;D. Can you pipe the packet capture through zcat? I'm not getting anything past syn_sent.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Does that mean "No, it won't update from a beta to a releaseversion"?
--
Is there an ETA for a new Version?
edit: tjista: I think it means "if there is a newer release version, it will update the beta; if there isn't, it won't".
...because you said this.
CC can't update from WoWUI, so it won't find any download link from there.
edit: if an author has posted an update to WoWUI, it doesn't mean that s/he has posted that to Curse too.
It says its pricessing addons, buut it refuses to anything to the list once generated unless yu install it with the CC.
Then you have to reinstall them from CC.
CC's "scan" feature doesn't work that well. You'll get much better results if you kill all your add-ons and reinstall them using the CC. It will then match them up correctly and there will be no ambiguity. This is also a good time to verify that each of your add-ons has indeed been updated to 3.0.2, as many of them won't have been. This is standard procedure for a major WoW version upgrade (remember this is only the second time this has ever happened in 4 years).
1) Since I have more than 300 addons (some of them are enabled, some are not), I prefer some automatic way. Otherwise I'll spend the rest of my life for distinguishing between those addons, which can be installed via CC, and those, which can't.
2) I did not have (if I remember right) such problems with WAU. It recognized addons versions properly, and updated those, which should be updated. It left intact those addons that had their latest versions installed, or those which WAU did not recognize (such as non-ACE addons).
What do we see with CurseClient? (1) does not work (no automatic way to update addons that were installed not via CC). (2) also does not work, while it worked in WAU.
So why break something that works?
Yes, I saw those famous threads about the [traditional] financial reasons. But if Curse wants to eat WowAce, and if WowAce wants to be eaten by Curse, maybe it would be more simple to only change hosting base - providing format compatibility? WAU would work by the same way, but referring to Curse site instead of WowAce site. Why not?
Now let's assume there were reasons to do it by that way, which we all see. But in this case why some people try to convince us that CurseClient provides the same - or even better - functionality than WAU did?
Turn off "Scan for Addons" in CC. Empty your add-ons folder (back it up first). Use CC to install all add-ons you can find on Curse. This will include every Ace add-on. Make a list of the add-ons you couldn't find on Curse and install them manually from another site. These manually installed add-ons will never be touched by CC. I have 180 add-ons and only 3 of them did not have brand new, up-to-date versions on Curse. Those 3 I subscribed to as favorites on WoWI. YMMV.
WAU was able to tell versions due to an extra XML file it placed in the add-on folder. Every WowAce add-on used one unified versioning system because they were all part of a single SVN repository. This is no longer the case, and there is no longer a unified versioning system. WAU did not look into add-ons you had installed manually and figure out their revision. You had to install it using the updater or update it once for it to know what you were running.
Nobody here has ever said that CC is the same or better than WAU. Certain things cannot be done better or differently in CC. Certain other things will be done better as the developers have more time to fine tune it. Going forward, your constructive thoughts on ways to improve the updater would be appreciated. No, it cannot at this time determine the exact version of every add-on you manually installed yourself. That will almost definitely never happen. There are some other threads on this forum discussing possible ways to embed metadata in every add-on to achieve this. You would have seen if you read them, however, that such a notion is a long shot at best, and probably won't happen.
What you didn't realize when you posted this, is that simply changing hosting providers wouldn't have helped the myriad of issues the WowAce developers were facing. Most if not all of the changes to the hosting platform have been done in such a way as to improve the developer experience on WowAce. I think most developers would agree that they have been successful with this for the most part. Leaving WowAce as it was may have benefited you, but it certainly did not benefit us. That is why you'll see so many devs on this forum complaining about user entitlement attitudes.
Why?
In other words - why changing hosting/sponsor/whatever should break version handling? Was it bad?
2) Found strange bug (?) (don't know if this is the proper thread): as I said I installed all addons before CC. Now I decided to reinstall all Bigwigs addons via CC. I selected all of them in "Find an Addon", then clicked on install. Success. Now we return to the "World of Warcraft" tab, and see only some of the "Bigwigs*" addons. E.g., "Bigwigs Bossmods" is not in the list, and I think "BigWigs_DispelResist" also was not there. Repeated - got the same situation. But manual install of each of them through "Find an Addon" tab - without using selection - helped.
Edit because of Allara's edit: Users will always have some complains if something that worked becomes broken. Users will have much more complains if such spoil was done deliberately. Users will overflow with complains if they don't understand the reason of this deliberate spoil.
Do you care whether people reverse-engineer the API?
Yes. Every single addon project was in the same repository - which had an open-access policy. This enabled files.wowace.com, and therefore the WAU, to exist as they did. It also allowed ANYONE to edit the addons.
Every time someone in Czechoslovakia (and other non-English-speaking countries) decided the translation in an addon needed updated (and sometimes there were competing translators), the file packager marked the entire addon as being updated. Every time an Ace library was updated, every addon which used it was re-packaged as being updated. This created bandwidth-usage for no reason. The addon wasn't actually updated - yet thousands of people downloaded it anyway. And there were those who updated several times a day.
New system: A single repository per addon. Only the author (or those he/she chooses) has access. There will eventually be a system in place for translators, but they will not be able to touch the addon itself.
netstat shows
TCP 192.168.1.152:51651 69.57.184.211:80 SYN_SENT 5584
TCP 192.168.1.152:51652 69.57.184.211:80 SYN_SENT 5584
PID 5584 is CurseClient.exe
Lose a server?
"Tickets" 818 through 821 are the same issue, so I didn't create a duplicate ticket.
-neo
Thanks Torhal. Also: now each project gets it's own wiki and ticket tracker. Comments are segregated by project instead of massed into a forum. Multiple types of source control are supported (this is a BIG one). Three types of releases are now supported (alpha/beta/release). The list goes on and on, and I'm tired of defending it.
My results are similar to yours.
I do actually get some responses from the server (can't read 'em 'cuz it's using gzip), but the interesting thing is: If I snoop a firefox connection, I see real data for headers, but then it goes to gzip for page bodies. When I snoop the client, it starts out sending gzipped stuff from the beginning, and gets back only more stuff which looks gzipped.
I can't remember the options for snoop, I really kind of hate Solaris ;D. Can you pipe the packet capture through zcat? I'm not getting anything past syn_sent.