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.
For me, PallyPower currently seems to only rarely notice when people in my group are missing the configured buff.
Seems like some event is not being watched anymore or got renamed?
I have no idea what you're asking. Please try again using comprehensible English. If English is not your native language, post your question in your native language, and I'm sure I can find a machine-translation service that will give a more comprehensible result than what you posted.
He's saying he only has a 40y range check status now, should be pretty obvious since you're the one who implemented that. :P
So Paladins are from now on going to be forced to use GridStatusMultiRange? Meh. Hands have 30y range :(
So you're trying to cater to the case where someone (the user, probably) installed A without the libs A needs in either form (embedded or stand-alone, which is a broken install to begin with)?
A might already fail in that scenario, if C does not load before A.
Doing what you suggested creates three clear scenarios:
it works because A has B embedded (and thus not specified as a dependency)
it works because A's no-lib zip includes B as a stand-alone lib (and has it specified as a dependency, this is what no-lib is for)
it breaks because either someone packaged an addon without its required libs or a stupid user decided to mess with stuff he doesn't understand
I find the sane way to go to be:
Making sure the first and second scenarios work and making sure that the third scenario results in a (readable, clear) error message pointing out to the user that addon A is incomplete and then bailing. Said error message only necessary in the case where it's the lib version of A without the libs, since the no-lib version will refuse to load anyway, clearly saying which dependency is missing.
I fail to see how catering to the "it works for some reason" scenario is in any way desireable. It only makes things more complicated when there's a bug report or when the user one day decides to get rid of addon C. ;-)
I think you're misreading both him and me (or it's just me misreading him^^):
I thought the question was if it made sense to add libs that an addon normally embeds into that same addon's .toc as dependencies inside the no-lib-strip block, so that they get loaded if the user fetches the no-lib package.
I find that to be sane and logical, and also the way it should already be - thus I just corrected the, what I perceived to be only mistake, in his train of thought. :)
BadBoy is now once again a nice and simple gold/hack/phishing/casino blocker & reporter. However I will adapt this addon if people find new ways to get past Blizzard's code.
0
This works as described, but somehow it affects my background in an ugly way:
I'm not sure how to remedy this, there is no way to configure texture insets, or am I doing something else wrong? :o
0
At least since 5.0, probably even before that, it's better to use
preferredIndex=STATICPOPUPS_NUMDIALOGS
than 3. STATICPOPUPS_NUMDIALOGS is 4, currently.
0
0
Seems like some event is not being watched anymore or got renamed?
0
0
Fixed!
0
I didn't ask you to, either. *shrug*
0
If you don't want the inevitable bug reports, set your project to not package alphas in the first place.
0
He's saying he only has a 40y range check status now, should be pretty obvious since you're the one who implemented that. :P
So Paladins are from now on going to be forced to use GridStatusMultiRange? Meh.
Hands have 30y range :(
0
A might already fail in that scenario, if C does not load before A.
Doing what you suggested creates three clear scenarios:
I find the sane way to go to be:
Making sure the first and second scenarios work and making sure that the third scenario results in a (readable, clear) error message pointing out to the user that addon A is incomplete and then bailing. Said error message only necessary in the case where it's the lib version of A without the libs, since the no-lib version will refuse to load anyway, clearly saying which dependency is missing.
I fail to see how catering to the "it works for some reason" scenario is in any way desireable. It only makes things more complicated when there's a bug report or when the user one day decides to get rid of addon C. ;-)
0
What you suggested in your first post should work just fine.
Use no-lib-strip to make your addon depend on the libraries it needs (which will be present in the no-lib zip, because that's what they're for).
What part of the puzzle am I (or are you) missing?
0
I thought the question was if it made sense to add libs that an addon normally embeds into that same addon's .toc as dependencies inside the no-lib-strip block, so that they get loaded if the user fetches the no-lib package.
I find that to be sane and logical, and also the way it should already be - thus I just corrected the, what I perceived to be only mistake, in his train of thought. :)
0
Your work is very much appreciated. :-)
0
WoW is not aware of that, it just loads the addon and all the files it includes.
0