the packager didn't start for a new tag (a new release) last night:
Could you please check on it?
Thanks in advance
- Curse Premium
Member for 11 years
Last active Tue, May, 22 2018 13:25:57
- 0 Followers
- 11 Total Posts
- 0 Thanks
Jan 6, 2015Posted in: General ChatQuote from gamemaster128Unless I'm mistaken, the inactive/abandoned status was only applied to addons that hadn't received an update for the 90 days prior to patch 6.0.2 going live. I don't believe it's supposed to be recurring.
Yes, it's not every 90 days, it's related to patch version numbers.
Quote from TorhalIt's supposed to be 90 days from a new version. Not every 90 days.
Do you mean "new version hits + 90 days" or "if new version and last update < 90 days"? Because the latter seems to be true.
What's wrong with taking the interface version that the WoW client uses to recognize out-dated addons? This at least requires an TOC update and thus a status change is justified. In this case, there is also no need to wait 90 days.
Jan 5, 2015This is indeed annoying. The version check seems not be related to the Interface version in the TOC which is checked by the WoW client, but rather to some maintenance patch version number. At least this should be changed.Posted in: General Chat
Loaded w/o complaints by the WoW client, so no need to update the addon, not even for a TOC update.
Oct 15, 2011True, the hidden addon-channel is way too intrusive. The whispers and tracking characters is also too complex given the simplicity/purpose of the addon. The more I think about counting emotes, the more I like it, since it is simple, generic, and effective ;)Posted in: Lua Code Discussion
Thanks for your thoughts!
Oct 15, 2011Hi,Posted in: Lua Code Discussion
I'm currently writing an addon that randomly emits auto-emotes. While this is fun when it doesn't happen too often, it could be annoying, when sitting in SW or OG and many players have it installed (the chat window gets polluted by those emotes).
Thus, I need some kind of rate control that takes into account the number of nearby players that have installed the same addon. SendAddonMessage, however, only works in your group. Is there another way to communicate with (or to detect) the addon on nearby players?
The only other way that came into my mind is counting recent emote messages and use a backoff based on this.
Thanks in advance,
Dec 8, 2010Hi,Posted in: General Chat
today, I received a Blizzard scam mail (which was impressively well made). I only recognized it as scam when I discovered that it was sent to a mail address which I solely use for Curse / WowAce.
AFAIK, the mail address should not be visible to other users or non-users, right? Or did I mess up something in my settings (didn't find an option, though).
Nov 16, 2010Yep, that would be an option. The only problem with calling it manually is, that AceAddon:InitializeAddon() and AceAddon:EnableAddon() will be then called *twice* since the module is added to the AceAddon.initializequeue and there is no way to prevent NewModule (or rather NewAddon) to do so.Posted in: Ace3
Calling AceAddon:EnableAddon() twice is no problem, since it does a check.
Calling AceAddon:InitializeAddon() does no check and will call OnInitialize() of the module/addon twice. In my OnInitialize() methods, I can set a flag to avoid double-initialization. However, there might be a potential problem with OnEmbedInitialize() of embedded libraries since this is also called twice for the same module. I will browse through the libs in question and check if there might be problems there.
However, it would be nice to have some control over this auto-initialization for dynamically created modules to ensure this is only done once. Maybe a new parameter to NewModule()?
Nov 16, 2010Yes, Adirelle, its as you explained. The module is created dynamically on behalf of the main addon after everything is loaded.Posted in: Ace3
The reason I want to create modules dynamically is as follows:
The addon (a HUD, ArcHUD3) provides a framework which is used by its modules to create rings for various purposes (e.g., to display a health bar, power bar etc.). Every single ring is realised by a single module with the ability to enable/disable them as required. Most rings are already predefined and thus can be loaded under the condition which Xinhuan described as scenario A (so no problem with those).
Now, I want to add custom rings that show the durations or stack sizes of user-defined buffs or debuffs. For each ring, a new module is created manually by the user the first time he or she defines it. After each login then, the definitions of the custom modules are extracted from the config DB and instantiated by the main addon. This also has to happen after the ADDON_LOADED event, i.e. in the OnInitialize() routine of the main addon.
That was the easiest way to go in the first place, since I didn't need to change much for the module prototype and still have the possibility to enable/disable user-defined rings separately without implementing a special case for those user-defined modules.
Perhaps I missed something and this behaviour is not supposed to be realised as modules?
Nov 15, 2010Hi,Posted in: Ace3
I'm using modules with my addon which works really well for predefined modules (i.e., for modules being loaded during the addon-loading process). Now, I want to create user-defined modules after regular login (i.e., after the main addon is already loaded and enabled) and basically use the same procedure with NewModule().
The problem, however, is that those modules are not initialized and enabled immediately. Initialization and enabling only happens upon a ADDON_LOADED event caused by a Load-on-Demand addon (thus, quite randomly).
My current workaround for this is to extract the OnEvent() function with AceAddon.frame:GetScript() and to call it manually. This, however, is certainly not the way to go.
Is there an accepted way to initialize new modules manually if they are created after the main addon has been enabled?
Thanks in advance!
- To post a comment, please login or register a new account.