No OSX client (for now) and being forced to wait for one specific client is sad.
Kolie has said in this very thread that there will be one a few weeks after they have a stable version. They are writing it using a cross platform library so it shouldn't take that long to come out (they just need to recompile it , test it , write some graphic bits). I've seen the website for the library they are using and trust me it won't take em long to come out with a OS X Client.
You know you really should of done some research ie Googling and reading of forum topics before posting this :D
It's computer hardware specifics. No software information is pulled. No settings or information is pulled. CPU specifications are pulled using the cpuid asm instruction and also the number of processors is gotten from a call to GetSystemInfo(). Video mode, resolution and driver version are gathered using the d3d9.dll and enumerating the devices in the return. Free disk space is gotten using the GetDiskFreeSpaceEx api. Free ram is gotten using GlobalMemoryStatusEx api. The os version is gotten using GetVersionEx(&osv);
Kolie why does the updater need to know this ???
I mean the updater would know what system its running on since they will be a seperate client version for each operating system (I think). It would know by how its compiled that to move a file on OS X it's a "mv" command for windows its "MOVE"
I don't see any reasonable explanation of why you need to get that information.
I can understand Disc Space to make sure you have the room to download the addon but Video Mode ??? Free Ram ??? You're essentially downloading text files with little picture files in folders. Why the need to know video mode for that ??
The World of Warcraft client handles everything needed to make sure a computer can run it ...having this check in the updater since a little excessive to me
Unless of course you are wanting to build in functionality other than just updating addons (like building in a developer mode for beta testers of addons or maybe a runtime enviroment for addon authors). If so why don't you just say that silly :D
I mean the updater would know what system its running on since they will be a seperate client version for each operating system (I think). It would know by how its compiled that to move a file on OS X it's a "mv" command for windows its "MOVE"
I don't see any reasonable explanation of why you need to get that information.
I can understand Disc Space to make sure you have the room to download the addon but Video Mode ??? Free Ram ??? You're essentially downloading text files with little picture files in folders. Why the need to know video mode for that ??
The World of Warcraft client handles everything needed to make sure a computer can run it ...having this check in the updater since a little excessive to me
Unless of course you are wanting to build in functionality other than just updating addons (like building in a developer mode for beta testers of addons or maybe a runtime enviroment for addon authors). If so why don't you just say that silly :D
Thats what im wondering to, or rather, the updater needs some of that information to make sure it can run on the system, but why in the world does curse need the updater to send them that information (and without my consent, or even ability to check that the information gatehred and sent really is the information they say it is)?
Sure if something goes bad with the client it can requestb to send the information to assist figuring out the problem, but only request (kind of like the "send this information to Microsoft" popup), and that it in the end is up to us as users to decide if we want to send the information or not.
As I previously mentioned:
It's mainly used to correlate bugs and issues in the client, and some of the issues I've seen I would've been been hard pressed to find a solution for without such data.
Your computer specifications are kept up to date, so that any issues that arise we have quick data at hand to fix the issue. The client runs on many computers and though we do our best to fix any issues we can in house before our products go out, software bugs are a fact of life. If I see that x people are crashing when updating an addon, the first thing I would need to know is information about their computer. With that information I can build a test platform that mirrors their situation to the best of my knowledge and do some real testing. I query OS information specifically because though I know your running windows, thats not enough. I need to know what version, home premium ultimate what have you, 32 bit, 64 bit, service pack information, all of this is REALLY relevant when debugging.
Also I mentioned previously about the old addon getting overwritten question, but i'll reiterate the point.
When the CC installs an addon, it makes a listing of all files it installs relative to the interface/addons folder. This list of files is then saved, starting with a reference count of one. When the auto update feature activates, it first goes into the file listing and sets the reference count of any files of the old version to -1, now all those files have a zero reference count. Those files are then deleted. Then the new package is unzipped and its files are added to the file listing with a reference count of one.
What this means is that old files in the .zip that are no longer in the new .zip will get deleted.
As I previously mentioned:
It's mainly used to correlate bugs and issues in the client, and some of the issues I've seen I would've been been hard pressed to find a solution for without such data.
Your computer specifications are kept up to date, so that any issues that arise we have quick data at hand to fix the issue. The client runs on many computers and though we do our best to fix any issues we can in house before our products go out, software bugs are a fact of life. If I see that x people are crashing when updating an addon, the first thing I would need to know is information about their computer. With that information I can build a test platform that mirrors their situation to the best of my knowledge and do some real testing. I query OS information specifically because though I know your running windows, thats not enough. I need to know what version, home premium ultimate what have you, 32 bit, 64 bit, service pack information, all of this is REALLY relevant when debugging.
Yes, but in the end I feel it should be up to me to decide if i want to send the information or not, and that it would only ever be considered if an issue arises and at that time promt that it wants to send the information, what information and why, and then let me decide if i want to let it do that or not.
I have always been strongly against the gathering and sending of information that is not vital to the actuall running of the program, nomatter how "non personal" information it is.
But for a mod like Skinner, where you have to drag the lua file things into another folder inside the addon, this means you'd have to drag them all over again every time you update.
You have to move them after every update no matter how you do it, or else you won't have the latest versions in the SkinMe folder :p It's really a clunky design.
Quote from kolie »
Also I mentioned previously about the old addon getting overwritten question, but i'll reiterate the point.
When the CC installs an addon, it makes a listing of all files it installs relative to the interface/addons folder. This list of files is then saved, starting with a reference count of one. When the auto update feature activates, it first goes into the file listing and sets the reference count of any files of the old version to -1, now all those files have a zero reference count. Those files are then deleted. Then the new package is unzipped and its files are added to the file listing with a reference count of one.
What this means is that old files in the .zip that are no longer in the new .zip will get deleted.
Sounds like a good solution. Do you take into account the case that an addon author moves a file from one subfolder to another within the addon? (or from the addon root folder to a subfolder, or vice versa)
Yes, but in the end I feel it should be up to me to decide if i want to send the information or not, and that it would only ever be considered if an issue arises and at that time promt that it wants to send the information, what information and why, and then let me decide if i want to let it do that or not.
I have always been strongly against the gathering and sending of information that is not vital to the actuall running of the program, nomatter how "non personal" information it is.
I think people need to understand that the wow-ace forum users are not the average wow-player who may care less about his privacy. Personally i will lock down any hidden feedback if i can spot it, i am allowed (as wow forbids that).
I am hoping that there will be an API for applications like WUU to hock in and circumvent that kind of background program. I want my addons updated with a single program, and not being forced to use 3,4,5 or even 10 addons for each site they're hosted on.
And from reading the other posts the curse Client won't be aware of addons not hosted on curse, which is a killer argument for the application for me.
I think people need to understand that the wow-ace forum users are not the average wow-player who may care less about his privacy. Personally i will lock down any hidden feedback if i can spot it, i am allowed (as wow forbids that).
I am hoping that there will be an API for applications like WUU to hock in and circumvent that kind of background program. I want my addons updated with a single program, and not being forced to use 3,4,5 or even 10 addons for each site they're hosted on.
And from reading the other posts the curse Client won't be aware of addons not hosted on curse, which is a killer argument for the application for me.
If other sites offer psyn feeds for their addons the CC will support them.
However, we don't plan on scraping their sites to download their addons without authorization like many of the programs that offer that type of functionality do.
We don't like it when an application like wowmatrix or wuu scrapes from Curse, and we don't plan to do the same to the other addon sites. There is nothing good to be had there.
We don't like it when an application like wowmatrix or wuu scrapes from Curse, and we don't plan to do the same to the other addon sites. There is nothing good to be had there.
Nothing good for you, but perhaps end users don't like running a half-dozen clients (all of them ad-bloated and wanting to eat up background resources in your system tray) in order to scrape multiple addon sites. Personally, WAU is the only updater I currently use, and I watch my favorites pages on Curse and WowInterface manually in my web browser because I hate the idea of cluttering up my system with clients for every addon site.
Nothing good for you, but perhaps end users don't like running a half-dozen clients (all of them ad-bloated and wanting to eat up background resources in your system tray) in order to scrape multiple addon sites. Personally, WAU is the only updater I currently use, and I watch my favorites pages on Curse and WowInterface manually in my web browser because I hate the idea of cluttering up my system with clients for every addon site.
No, there is nothing good had by anyone who respects the work of others.
It is a lot of work, and money, to run one of these sites. Its not right for any updater to screen scrape against the wishes of the owners of a given site.
It does nothing but harm the overall for the good of the few, and in the long run teaches others that its ok to do so.
Simply becous i don't trust Curse enough to want to allow that their client gathers and sends information without me knowing what information, why/whatfor and specificly allow it to send it after seeing what it contains.
If you don't trust it, how could you trust the disable option to work?
If you don't trust it, how could you trust the disable option to work?
Heh. Not...the...point.
What the client should do, if all Kolie really wants is more information when "it crashes": like WoW, Firefox and other apps, it should bring up a frame alerting the person to the crash. As well as the option to then provide system information and/or crash dumps to Curse.
Or more simply, just throw up a frame right after a crash with a "yes", "no" & "show me what will be sent to Curse" (which brings up the dump & system information to be sent in the system's default text editor) buttons on it.
As its currently going, it sounds a lot less like a crash debug helper than a stat gathering tool for advertisers. If the client collects system data automatically and uploads it with no option not to do so, I'm not going to be using it.
Bad example, as if the individual skin files were updated, you'd still have to copy the updated ones you wanted to the SkinMe folder anyway...
I've only had to drag skins over a few times. Once when outfitter was redone, and when omen was redone. Oh, and when I had to completely reinstall it because CurseForge beta screwed it up and corrupted it by trying to install an outdated version.
I've only had to drag skins over a few times. Once when outfitter was redone, and when omen was redone. Oh, and when I had to completely reinstall it because CurseForge beta screwed it up and corrupted it by trying to install an outdated version.
o_O There's no point in updating if you're not dragging the skin files over with each update.
Wait, so it doesn't have an option to delete the current version of the addon before unpacking a new version over the top of it? I've had that cause problems before when an addon author meant for files to no longer exist in an updated version, so I have set WAU to "delete before extracting."
Glad to see this has been looked at with the new client.
This is a major issue with the current curse client (possibly combined with less tech savvy users). The latest version of Atlas does not include AtlasEntrances (it is depreciated). As such, the v1.11.0 AtlasEntrances is left in the addons directory where it tries to register incompatible data with Atlas v1.12.0. Dan and I are writing 'delete your AtlasEntrances folder' in support requests MANY times a day. It's in big bold letters everywhere for people to delete their old Atlas stuff before the upgrade on the addon sites, but those that use the updater don't see it.
o_O There's no point in updating if you're not dragging the skin files over with each update.
What if the WIM skin was updated and I don't use WIM? I would have no reason to copy over skinme files. Even if I *did* use WIM, I would only have to copy over that one skin, as the others would not have changed.
What if the WIM skin was updated and I don't use WIM? I would have no reason to copy over skinme files. Even if I *did* use WIM, I would only have to copy over that one skin, as the others would not have changed.
I found copying/moving individual skin files to be tedious, so now I just move the whole lot over to the SkinMe folder. I suppose it takes up a little more memory, but Skinner as a whole only seems to use a couple hundred kilobytes.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Kolie has said in this very thread that there will be one a few weeks after they have a stable version. They are writing it using a cross platform library so it shouldn't take that long to come out (they just need to recompile it , test it , write some graphic bits). I've seen the website for the library they are using and trust me it won't take em long to come out with a OS X Client.
You know you really should of done some research ie Googling and reading of forum topics before posting this :D
Kolie why does the updater need to know this ???
I mean the updater would know what system its running on since they will be a seperate client version for each operating system (I think). It would know by how its compiled that to move a file on OS X it's a "mv" command for windows its "MOVE"
I don't see any reasonable explanation of why you need to get that information.
I can understand Disc Space to make sure you have the room to download the addon but Video Mode ??? Free Ram ??? You're essentially downloading text files with little picture files in folders. Why the need to know video mode for that ??
The World of Warcraft client handles everything needed to make sure a computer can run it ...having this check in the updater since a little excessive to me
Unless of course you are wanting to build in functionality other than just updating addons (like building in a developer mode for beta testers of addons or maybe a runtime enviroment for addon authors). If so why don't you just say that silly :D
Thats what im wondering to, or rather, the updater needs some of that information to make sure it can run on the system, but why in the world does curse need the updater to send them that information (and without my consent, or even ability to check that the information gatehred and sent really is the information they say it is)?
Sure if something goes bad with the client it can requestb to send the information to assist figuring out the problem, but only request (kind of like the "send this information to Microsoft" popup), and that it in the end is up to us as users to decide if we want to send the information or not.
It's mainly used to correlate bugs and issues in the client, and some of the issues I've seen I would've been been hard pressed to find a solution for without such data.
Your computer specifications are kept up to date, so that any issues that arise we have quick data at hand to fix the issue. The client runs on many computers and though we do our best to fix any issues we can in house before our products go out, software bugs are a fact of life. If I see that x people are crashing when updating an addon, the first thing I would need to know is information about their computer. With that information I can build a test platform that mirrors their situation to the best of my knowledge and do some real testing. I query OS information specifically because though I know your running windows, thats not enough. I need to know what version, home premium ultimate what have you, 32 bit, 64 bit, service pack information, all of this is REALLY relevant when debugging.
When the CC installs an addon, it makes a listing of all files it installs relative to the interface/addons folder. This list of files is then saved, starting with a reference count of one. When the auto update feature activates, it first goes into the file listing and sets the reference count of any files of the old version to -1, now all those files have a zero reference count. Those files are then deleted. Then the new package is unzipped and its files are added to the file listing with a reference count of one.
What this means is that old files in the .zip that are no longer in the new .zip will get deleted.
Yes, but in the end I feel it should be up to me to decide if i want to send the information or not, and that it would only ever be considered if an issue arises and at that time promt that it wants to send the information, what information and why, and then let me decide if i want to let it do that or not.
I have always been strongly against the gathering and sending of information that is not vital to the actuall running of the program, nomatter how "non personal" information it is.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou have to move them after every update no matter how you do it, or else you won't have the latest versions in the SkinMe folder :p It's really a clunky design.
Sounds like a good solution. Do you take into account the case that an addon author moves a file from one subfolder to another within the addon? (or from the addon root folder to a subfolder, or vice versa)
I think people need to understand that the wow-ace forum users are not the average wow-player who may care less about his privacy. Personally i will lock down any hidden feedback if i can spot it, i am allowed (as wow forbids that).
I am hoping that there will be an API for applications like WUU to hock in and circumvent that kind of background program. I want my addons updated with a single program, and not being forced to use 3,4,5 or even 10 addons for each site they're hosted on.
And from reading the other posts the curse Client won't be aware of addons not hosted on curse, which is a killer argument for the application for me.
If other sites offer psyn feeds for their addons the CC will support them.
However, we don't plan on scraping their sites to download their addons without authorization like many of the programs that offer that type of functionality do.
We don't like it when an application like wowmatrix or wuu scrapes from Curse, and we don't plan to do the same to the other addon sites. There is nothing good to be had there.
Nothing good for you, but perhaps end users don't like running a half-dozen clients (all of them ad-bloated and wanting to eat up background resources in your system tray) in order to scrape multiple addon sites. Personally, WAU is the only updater I currently use, and I watch my favorites pages on Curse and WowInterface manually in my web browser because I hate the idea of cluttering up my system with clients for every addon site.
No, there is nothing good had by anyone who respects the work of others.
It is a lot of work, and money, to run one of these sites. Its not right for any updater to screen scrape against the wishes of the owners of a given site.
It does nothing but harm the overall for the good of the few, and in the long run teaches others that its ok to do so.
If you don't trust it, how could you trust the disable option to work?
Heh. Not...the...point.
What the client should do, if all Kolie really wants is more information when "it crashes": like WoW, Firefox and other apps, it should bring up a frame alerting the person to the crash. As well as the option to then provide system information and/or crash dumps to Curse.
Or more simply, just throw up a frame right after a crash with a "yes", "no" & "show me what will be sent to Curse" (which brings up the dump & system information to be sent in the system's default text editor) buttons on it.
As its currently going, it sounds a lot less like a crash debug helper than a stat gathering tool for advertisers. If the client collects system data automatically and uploads it with no option not to do so, I'm not going to be using it.
I've only had to drag skins over a few times. Once when outfitter was redone, and when omen was redone. Oh, and when I had to completely reinstall it because CurseForge beta screwed it up and corrupted it by trying to install an outdated version.
o_O There's no point in updating if you're not dragging the skin files over with each update.
Glad to see this has been looked at with the new client.
This is a major issue with the current curse client (possibly combined with less tech savvy users). The latest version of Atlas does not include AtlasEntrances (it is depreciated). As such, the v1.11.0 AtlasEntrances is left in the addons directory where it tries to register incompatible data with Atlas v1.12.0. Dan and I are writing 'delete your AtlasEntrances folder' in support requests MANY times a day. It's in big bold letters everywhere for people to delete their old Atlas stuff before the upgrade on the addon sites, but those that use the updater don't see it.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhat if the WIM skin was updated and I don't use WIM? I would have no reason to copy over skinme files. Even if I *did* use WIM, I would only have to copy over that one skin, as the others would not have changed.
I found copying/moving individual skin files to be tedious, so now I just move the whole lot over to the SkinMe folder. I suppose it takes up a little more memory, but Skinner as a whole only seems to use a couple hundred kilobytes.