The project pages are back and writeable and sure enough, I got lots of issues opened about the Skillet-Classic release problem but when I try to fix it, the SVN repository, https://repos.wowace.com/wow/skillet-classic, is giving me an error (same error on Skillet, https://repos.wowace.com/wow/skillet). See the attached screenshots.
It appears like the remote repositories are in a state prior to the successful changes I made on November 30th. I can live with that if I can get things synced up again so I can continue support / development. I'd really like to get Skillet-Classic fixed ASAP because I have 2,475 downloads that will error out immediately upon logging in for those people.
My only wish is that every addon author that Curse / Curseforge pisses off moves their addon somewhere else. When all of my addons can be obtained somewhere else, I'm going to say good bye to Curse and never look back.
I'm not sure Curse Support is monitoring this forum, at least not as well as they monitor the support@curse.com mailbox. I sent them a copy of this error and got a reply within 15 minutes that someone would look into it.
Using a package manager (In my case: SVN, Skillet, WowAce), I commit a change. On the Files page, I see the update marked as New (and the size of the file is too small). Sometime later, it will move to Approved (with the file size as expected). In some cases, it moves from New to Under Review.
I'd like to know how the Status changes from state to state for alpha builds, beta builds, and releases. Is the change automatic, artificially delayed by x minutes, requires manual (human) intervention, etc.
For alpha versions, can you explain the rationale for anything other than automatic progression from New to Approved?
As a side issue, can you explain why Curse.com shows a project as updated when the results of that update are NOT available on Curse?
I have the following .pkgmeta file for Skillet. I just built a new alpha release and when I compare the files in the alpha package with the files in the last released version (2.86), I see that the LibPeriodicTable-3.1 .toc files are updated but the .lua files are not. Have I done something wrong? If so, how do I fix it?
I would like to keep track of the (non-AH) attachments sent to me by others. I'd like both a log and a summary.
I downloaded MailOutbox and discovered Postal and MailOutbox interfere because MailOutbox uses the wasRead flag from GetInboxHeaderInfo() to prevent logging the mail more than once and Postal processes the Inbox before MailOutbox sees it.
I've only found one place that Postal checks the wasRead flag and that is when the MAIL_CLOSED event fires. If this is the only place, then if I can get MailOutbox to process the inbox first, it should not effect the functioning of Postal.
Any ideas on how to get MailOutbox to see mail first?
0
In reply to michaelsp:
Thank you!
0
You are assuming I didn't search for it before I asked for a link but then you probably don't know it anyway. Thanks anyway.
0
Do you have a link for that?
0
I'd like to report this error via email to CurseForge support, but for the life of me I can't find an email address. Can anyone help with that?
0
On November 30th, I published releases for both Skillet and Skillet-Classic (which I normally access through http://www.wowace.com/addons/skillet/ and https://www.wowace.com/projects/skillet-classic). The Skillet-Classic release had a Lua error but when I tried to fix it, the WowAce page went read-only.
The project pages are back and writeable and sure enough, I got lots of issues opened about the Skillet-Classic release problem but when I try to fix it, the SVN repository, https://repos.wowace.com/wow/skillet-classic, is giving me an error (same error on Skillet, https://repos.wowace.com/wow/skillet). See the attached screenshots.
It appears like the remote repositories are in a state prior to the successful changes I made on November 30th. I can live with that if I can get things synced up again so I can continue support / development. I'd really like to get Skillet-Classic fixed ASAP because I have 2,475 downloads that will error out immediately upon logging in for those people.
How do I get this problem resolved?
0
In reply to horologue:
Hopefully, you have continued to follow Skillet-Classic as the current build (and quite a few past builds) supports Enchanting.
0
Skillet-Classic has a better "home". While builds are still labeled as alphas, it is about 85-90% complete. Download the latest alpha and report any problems at https://www.wowace.com/projects/skillet-classic/issues.
0
My only wish is that every addon author that Curse / Curseforge pisses off moves their addon somewhere else. When all of my addons can be obtained somewhere else, I'm going to say good bye to Curse and never look back.
0
I'm not sure Curse Support is monitoring this forum, at least not as well as they monitor the support@curse.com mailbox. I sent them a copy of this error and got a reply within 15 minutes that someone would look into it.
0
Me too!
0
Was this the policy on the old Curse / Curseforge / WowAce sites? If so, then I must have been white-listed on the old sites.
0.962075848303393
Using a package manager (In my case: SVN, Skillet, WowAce), I commit a change. On the Files page, I see the update marked as New (and the size of the file is too small). Sometime later, it will move to Approved (with the file size as expected). In some cases, it moves from New to Under Review.
I'd like to know how the Status changes from state to state for alpha builds, beta builds, and releases. Is the change automatic, artificially delayed by x minutes, requires manual (human) intervention, etc.
For alpha versions, can you explain the rationale for anything other than automatic progression from New to Approved?
As a side issue, can you explain why Curse.com shows a project as updated when the results of that update are NOT available on Curse?
0
0
0
I downloaded MailOutbox and discovered Postal and MailOutbox interfere because MailOutbox uses the wasRead flag from GetInboxHeaderInfo() to prevent logging the mail more than once and Postal processes the Inbox before MailOutbox sees it.
I've only found one place that Postal checks the wasRead flag and that is when the MAIL_CLOSED event fires. If this is the only place, then if I can get MailOutbox to process the inbox first, it should not effect the functioning of Postal.
Any ideas on how to get MailOutbox to see mail first?