Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
I've got a ticket from an user about the (Ace3) libs not being correctly embeded in ReadySetDing, without actually providing me his error log...
But It got rather long and more confusing in the end...
My question is: if the embeding is done OK, and if not, what might be going wrong.
I'm pointing to the libraries from the .TOC file instead of from an .XML file because of this post
I just plainly copied these .TOC tags from the old Ace3 Tutorial, and never looked back again.
I've not done anything in the direction of no libs versions, or anything yet with repositories
(even though I'm still in the process of setting it up, but only afterwards I received this ticket)
Since I just manually packaged ReadySetDing (like the noob I am :D), my guess was that something (Curse Client?) forcefully deleted the "hard embeded" Ace3 libs. Although I'm not sure how/if those libs ever could be deleted out of the .ZIP file
I told him that I was correctly pointing to the Ace3 libs, and saw nothing going wrong, after I did some thorough testing
His response was, and I quote:
I'm not sure why this would be occuring, but you're right that the code should be point to your libs below RSD.
The error was not occuring before I re-installed RSD
The error occured after I installed RSD.
The error disappeared after I installed Ace3 at root level.
Thus either,
The libs under RSD are out of sync with the latest version of Ace3
The code was not pointing to the right location
Something else was occuring ...
Because it seems that option 3. is more likely ... therefore, I was just suggestion that the mention that users needed the standalone version of Ace3 installed seemed the best course of action. Hope that helps.
TLDR: I did my own testing, without getting any errors, but he seemingly does get an error, and is suggesting me to tell the users of this addon they need to have Ace3 installed, indirectly saying I need to add ## RequiredDeps: Ace3 to the .TOC tags
This is really just a simply zipped up addon, with it's own libs in the \ReadySetDing\Libs\ folder
My question, again, is: if the embeding is done OK, and if not, what might be going wrong?! e
Nothing seems obviously wrong from what I can see. That all looks like a perfectly normal setup. The user is going to have to provide an actual error message if anything's going to get solved at his end, IMHO.
I'm not doing anything in the direction of Revision Control systems / repositories, so there is no .pkgmeta involved .. (Completely unrelated: I only set up an empty one, after I received this ticket, and I'm still RTFM "reading the fucking ToirtoiseSVN manual")
I just dumbly copied the X-Embeds: Ace3 from the old Ace3 Tutorial
Edit:
I'm actually still "hard embeding" the Ace3 libs, since I'm not using a repository (yet)
Edit2:
Since it seems nothing is actually wrong, I'm waiting for his actual error log then ..
You should really try to use a rev. control system. It will be little step to take in the beginning, but it is worth it because you will save time and get better control when you a hang of it :-)
I downloaded your addon through the link in your post. The TOC is perfectly fine and correct (though I'll recommend removing colors from #Title because its not really needed).
Then I installed your addon through the Curse Client and looked at the installed addon. The addon installed correctly, has the exact same TOC file, and even though I had specified all addons of mine to be installed nolibs, the Libs folder is present and intact (because you do not have a nolibs version of the addon, the Curse Client just extracts the whole zip as-is, it doesn't do voodoo and remove the Libs folder. Incidentally you don't even have to call the Libs folder "Libs", you could call it "Voodoo" if you like as long as you also change all the paths in the TOC to point to Voodoo\Blah\Blah.xml instead of Libs\Blah\Blah.xml, its just that... well convention sticks huh).
Conclusion: There is nothing wrong with your addon.
However, you should move line 1710 of your addon (the line that calls GetClassColor()) into the sanity check because classFileName is nil if name is nil (duh) and an error would result on line 1270 when that happens.
I downloaded your addon through the link in your post. The TOC is perfectly fine and correct (though I'll recommend removing colors from #Title because its not really needed).
Then I installed your addon through the Curse Client and looked at the installed addon. The addon installed correctly, has the exact same TOC file, and even though I had specified all addons of mine to be installed nolibs, the Libs folder is present and intact (because you do not have a nolibs version of the addon, the Curse Client just extracts the whole zip as-is, it doesn't do voodoo and remove the Libs folder. Incidentally you don't even have to call the Libs folder "Libs", you could call it "Voodoo" if you like as long as you also change all the paths in the TOC to point to Voodoo\Blah\Blah.xml instead of Libs\Blah\Blah.xml, its just that... well convention sticks huh).
Conclusion: There is nothing wrong with your addon.
However, you should move line 1710 of your addon (the line that calls GetClassColor()) into the sanity check because classFileName is nil if name is nil (duh) and an error would result on line 1270 when that happens.
I just really, like, the coloring in the addon's name when they show up in the addon list ..
(at least for the green color for the version number, since my "bad habits" are to include the version number next to the title name)
I actually couldn't test this addon out myself with the Curse Client (wont bother you people on the details), so I had no idea what was going on that part. I have to admit I was suspecting it for doing some "voodoo" though
About that line with the custom GetClassColor() function: Thanks. I will move it into the sanity check now~ :)
Since everything looks OK, and Xinhuan even did some quick testing with the Curse Client, and now I also received the actual error report from the ticket (had to do some digging/guessing in that particular one though), it seems there wasn't actually any error involving the (lack of) Ace3 libs ..
You should really try to use a rev. control system. It will be little step to take in the beginning, but it is worth it because you will save time and get better control when you a hang of it :-)
I will continue RTFM'ing now =) (in my case, ToirtoiseSVN)
Lastly, I'm really sorry to you all, for prematurely making a thread, since he and I didn't provide any proof to back it up yet.
I was jumping to conclusions too early without having an error log, and maybe he was just guessing ...
what if its related to that last acelocale update that forces the silent flag
if RSD has the latest ace3 libs then for that user its essentially forcing all their mods to have an updated acelocale lib and if one of the users other mods hasnt been updated its going to barf - and probably blame RSD.
all our mods have probably been updated (or didnt need to be) so we wont even notice the problem. but if that user has just one mod that needs to be updated then theyre going to have issues.
simple test is to get them to disable every single mod except RSD. if they do that then they most like wont encounter any ace errors at all which should show its not RSD related.
heh... I see your user got the error that Xinhuan pointed out. ;) I also see that your user is getting tons of errors related to other addons. Including FriendsFu. Perhaps they should ditch that and FuBar (since it's been long dead)... You also seem to require a nil check for variable a at line 1121 (or figure out why it's coming up nil).
I don't see anything relating to your libraries in there. And, as mentioned, you are fine with how you are embedding them.
/edit: oh, I see a few more errors for RSD - hate that they just pulled the entire Swatter saved variable file out for you...
But It got rather long and more confusing in the end...
My question is: if the embeding is done OK, and if not, what might be going wrong.
This is really just a simply zipped up addon, with it's own libs in the \ReadySetDing\Libs\ folder
My question, again, is: if the embeding is done OK, and if not, what might be going wrong?! e
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorSomeone will have to enlighten me, but is the X-Embeds: Ace3 line in your toc necessary? Just throwing it out there, but would that pose a problem?
(Completely unrelated: I only set up an empty one, after I received this ticket, and I'm still RTFM "reading the fucking ToirtoiseSVN manual")
I just dumbly copied the X-Embeds: Ace3 from the old Ace3 Tutorial
Edit:
I'm actually still "hard embeding" the Ace3 libs, since I'm not using a repository (yet)
Edit2:
Since it seems nothing is actually wrong, I'm waiting for his actual error log then ..
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI downloaded your addon through the link in your post. The TOC is perfectly fine and correct (though I'll recommend removing colors from #Title because its not really needed).
Then I installed your addon through the Curse Client and looked at the installed addon. The addon installed correctly, has the exact same TOC file, and even though I had specified all addons of mine to be installed nolibs, the Libs folder is present and intact (because you do not have a nolibs version of the addon, the Curse Client just extracts the whole zip as-is, it doesn't do voodoo and remove the Libs folder. Incidentally you don't even have to call the Libs folder "Libs", you could call it "Voodoo" if you like as long as you also change all the paths in the TOC to point to Voodoo\Blah\Blah.xml instead of Libs\Blah\Blah.xml, its just that... well convention sticks huh).
Conclusion: There is nothing wrong with your addon.
However, you should move line 1710 of your addon (the line that calls GetClassColor()) into the sanity check because classFileName is nil if name is nil (duh) and an error would result on line 1270 when that happens.
(at least for the green color for the version number, since my "bad habits" are to include the version number next to the title name)
I actually couldn't test this addon out myself with the Curse Client (wont bother you people on the details), so I had no idea what was going on that part. I have to admit I was suspecting it for doing some "voodoo" though
About that line with the custom GetClassColor() function: Thanks. I will move it into the sanity check now~ :)
Since everything looks OK, and Xinhuan even did some quick testing with the Curse Client, and now I also received the actual error report from the ticket (had to do some digging/guessing in that particular one though), it seems there wasn't actually any error involving the (lack of) Ace3 libs ..I will continue RTFM'ing now =)
(in my case, ToirtoiseSVN)
Lastly, I'm really sorry to you all, for prematurely making a thread, since he and I didn't provide any proof to back it up yet.
I was jumping to conclusions too early without having an error log, and maybe he was just guessing ...
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumif RSD has the latest ace3 libs then for that user its essentially forcing all their mods to have an updated acelocale lib and if one of the users other mods hasnt been updated its going to barf - and probably blame RSD.
all our mods have probably been updated (or didnt need to be) so we wont even notice the problem. but if that user has just one mod that needs to be updated then theyre going to have issues.
simple test is to get them to disable every single mod except RSD. if they do that then they most like wont encounter any ace errors at all which should show its not RSD related.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI don't see anything relating to your libraries in there. And, as mentioned, you are fine with how you are embedding them.
/edit: oh, I see a few more errors for RSD - hate that they just pulled the entire Swatter saved variable file out for you...
and yes, I had no real clue which one was actually the error since he just uploaded his whole swatter savedvars dump
He sure got a lot of Ace3 errors~
Edit:
There were 2 other errors for this addon, but they were from previous versions that I already fixed (v0.77 - v0.79)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI actually still use FuBar (and a number of plugins, some converted by Broker2FuBar) without any errors. Lol.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator