Look at Ackis Recipe List. You'll likely have to get the repository version to see the unadulterated values.
Great, thanks.
edit: If anyone else wants to see without going to the repository, there's an undocumented "key" property on @localization. Ackis Recipe List uses it like this:
## Notes: English notes
## Notes-deDE: --@localization(locale="deDE", i have no idea what goes here)@
## Notes-ruRU: --@localization(locale="ruRU", i have no idea what goes here)@
## Notes-esES: --@localization(locale="esES", i have no idea what goes here)@
## Notes-esMX: --@localization(locale="esES", i have no idea what goes here)@
## Notes-frFR: --@localization(locale="frFR", i have no idea what goes here)@
But I can't remember which addon it was, and I can't figure out how to do it from the documentation. Is there a way to make the --@localization()@ thing expand to only a single key's value? It would be nice to have the localizations in the TOC automatically generated.
I'm going to answer this even though it's over a year old, because it's the only Google match for Curse's "individual file exceptions". If there's documentation, it's buried somewhere Google isn't indexing it.
Individual file exceptions keep the client from objecting that an addon is locally "modified". They encourage the client to overwrite local changes, not discourage it. Normally the client will warn and prompt the user, asking for confirmation to update an addon that's had some of its files modified. If those modifications are in an area covered by "individual file exceptions", then the client doesn't ask the user.
It's the UnitClass argument causing the error, not the return.
edit: Actually I have no idea how the raid ids 1-num get handed out, but either way it looks like you're getting a nil result from UnitName, and passing it to UnitClass, and it complains about the nil argument.
There's nothing special with the xOffset of the BOTTOMRIGHT attach point you're using.
I'm not sure what you're trying to do. Part of the statusbar is transparent unless it's 100% full though; that may be causing some misunderstanding. How it works is that :SetValue will never change the size of the statusbar itself, but it does resize the texture you can get at with :GetStatusBarTexture().
You could try adding some lines like this to _TestValue:
This is something weird I noticed, when I asked about a good way to test the "shield" icons that appear on castbars for uninterruptable spells. Several people told me to just use my Hearthstone or a mount, and that those are considered uninterruptable casts.
It works on my 85 mage, but not my 85 druid or my 1 mage. And it's not addon-related; just this 1-line script behaves differently on different characters:
/dump select(9,UnitCastingInfo("target"))
My 85 mage gets "true", and can see casting shields on Hearthstones, not just his own Hearthstone, but anyone's. And the other 2 characters get "false", and don't see casting shields on Hearthstones.
It gets weirder. I found some mobs with real cast-immune spells, and both characters get "true" and see the shield on them, for example Blackrock Worg Captain's Steady Shot. So there the behavior is uniform, but on Hearthstones it depends on the character.
I want to implement the standard "highlight blue for magic, purple for curse" on unit frames. Most mods seem to create a separate "highlight frame" on top of the unit frame for this, and I think I know the reason. The HIGHLIGHT layer is the only way to cover fontstrings in OVERLAY. Even OVERLAY's highest sublevel won't cover a fontstring.
But HIGHLIGHT has this automatic show/hide behavior on mouseover, so it's good for mouseover-based highlights, but useless for debuff-related highlights. So if HIGHLIGHT is the only way to cover those strings, but you can't use it, then your only choice is to create another frame at a higher FrameLevel.
Am I right that there's no way to control HIGHLIGHT's behavior?
That's because ButtonFacade is not a library. LibButtonFacade is a library, and ButtonFacade is an addon that lets you change how addons interact with LibButtonFacade, much like SurfaceControl lets you change the texture used by LibSharedMedia-3.0.
I was using "ButtonFacade" to refer to the project. There is no separate LibButtonFacade project. I expect anything further is semantic.
No addons actually do it that way, though, and the generally accepted practice is to check for LibButtonFacade before trying to use it in your addon, and not embed it, since any user who wants to skin your addon will have downloaded a separate copy of the ButtonFacade addon anyway.
Ah. I really don't know anything about ButtonFacade usage; I just noticed it had the packaging issue when I was looking at Acherus Runes and seeing what would be necessary to update it for Cata. I'll have to look into this more before deciding whether to remove the embed.
It does have the same packaging issue though. As an example, Bison is embedding LibButtonFacade, and its Bison/libs/LibButtonFacade-1.0/Libs/ is full of stuff that shouldn't be there. I'm glad to hear this is a packager bug at least though, since I was at a loss to explain it myself, and at least it's not my or library authors' problem to deal with.
Regarding ButtonFacade, as far as I can tell there is no separate project for LibButtonFacade. Instead the library is in its Libs/ folder. Most libraries seem implemented this way anyway; the root directory has a .toc and some stuff for testing and standalone, and the library is in a subfolder. (ButtonFacade is named oddly though.)
ThreatPlates was a bad example; I just searched my Addons/ folder and picked 2 examples; I didn't know it wasn't made with the packager. I have many others though, each with an extra copy of AceGUI-3.0 inside of AceGUI-3.0-SharedMediaWidgets: Archy, BulkMail2Inbox, ChocolateBar, Omen, Prat-3.0, Quartz, SexyMap, Skada, WeakAuras.
Also at least in the case of AceGUI-3.0-SharedMediaWidgets, this only effects Beta and Release ZIPs; alpha ZIPs don't get the extra stuff in them. I have no idea why. For example, look at the most recent alpha and beta of my mod InterruptHelper:
Is there any way to do this correctly? The only two libraries I know pulling in externals in the .pkgmeta are LibButtonFacade and AceGUI-3.0-SharedMediaWidgets, and in both cases it causes problems for addons embedding the libraries; even when we correctly specify the project's subfolder to get only the embedded library, all the externals intended for the root folder are also packaged. This is impacting the ZIP distributions of very many addons; AceGUI-3.0-SharedMediaWidgets's embedded AceGUI is adding 60k to Grid, ThreatPlates, and many others. It doesn't impact runtime performance, but it wastes bandwidth, and making an already-big ZIP file bigger creates the false impression that Ace addons are bloated.
If there's a way to do this correctly, I want to help offer fixes for libraries doing it. Or if it's a bug in the packager, I should report that too. I tried to look to Ace3 for the "right" way of doing it, but Ace3 hard embeds LibStub and CallbackHandler, so it's not an example. Is there a way to do it right?
My best guess is that libraries simply shouldn't put externals in .pkgmeta, and that a user installing standalones is expected to get the dependencies right. Besides, users installing standalones don't want libraries embedding things so it's not even a feature.
Several people here have asked for a way to temporarily turn sounds on. I have a general-purpose mod that does this, called FixModSounds. I use this with DXE on a daily basis and it seems to work; if anyone has trouble please let me know because DXE is the whole reason I wrote it.
0
Great, thanks.
edit: If anyone else wants to see without going to the repository, there's an undocumented "key" property on @localization. Ackis Recipe List uses it like this:
0
## Notes: English notes
## Notes-deDE: --@localization(locale="deDE", i have no idea what goes here)@
## Notes-ruRU: --@localization(locale="ruRU", i have no idea what goes here)@
## Notes-esES: --@localization(locale="esES", i have no idea what goes here)@
## Notes-esMX: --@localization(locale="esES", i have no idea what goes here)@
## Notes-frFR: --@localization(locale="frFR", i have no idea what goes here)@
But I can't remember which addon it was, and I can't figure out how to do it from the documentation. Is there a way to make the --@localization()@ thing expand to only a single key's value? It would be nice to have the localizations in the TOC automatically generated.
0
Individual file exceptions keep the client from objecting that an addon is locally "modified". They encourage the client to overwrite local changes, not discourage it. Normally the client will warn and prompt the user, asking for confirmation to update an addon that's had some of its files modified. If those modifications are in an area covered by "individual file exceptions", then the client doesn't ask the user.
0
It's not always enough; sometimes you have to wait for ADDON_LOADED, then hook functions and wait on those. But it's a start.
0
edit: Actually I have no idea how the raid ids 1-num get handed out, but either way it looks like you're getting a nil result from UnitName, and passing it to UnitClass, and it complains about the nil argument.
0
I'm not sure what you're trying to do. Part of the statusbar is transparent unless it's 100% full though; that may be causing some misunderstanding. How it works is that :SetValue will never change the size of the statusbar itself, but it does resize the texture you can get at with :GetStatusBarTexture().
You could try adding some lines like this to _TestValue:
print("bar size", F:GetSize())
print("texture size", F:GetStatusBarTexture():GetSize())
0
It works on my 85 mage, but not my 85 druid or my 1 mage. And it's not addon-related; just this 1-line script behaves differently on different characters:
/dump select(9,UnitCastingInfo("target"))
My 85 mage gets "true", and can see casting shields on Hearthstones, not just his own Hearthstone, but anyone's. And the other 2 characters get "false", and don't see casting shields on Hearthstones.
It gets weirder. I found some mobs with real cast-immune spells, and both characters get "true" and see the shield on them, for example Blackrock Worg Captain's Steady Shot. So there the behavior is uniform, but on Hearthstones it depends on the character.
Is this understood at all?
0
But HIGHLIGHT has this automatic show/hide behavior on mouseover, so it's good for mouseover-based highlights, but useless for debuff-related highlights. So if HIGHLIGHT is the only way to cover those strings, but you can't use it, then your only choice is to create another frame at a higher FrameLevel.
Am I right that there's no way to control HIGHLIGHT's behavior?
0
Thanks, that's really helpful.
0
0
http://www.wowace.com/addons/grid/tickets/537-grid-lua-error-in-wow-4-1/
0
Ah. I really don't know anything about ButtonFacade usage; I just noticed it had the packaging issue when I was looking at Acherus Runes and seeing what would be necessary to update it for Cata. I'll have to look into this more before deciding whether to remove the embed.
It does have the same packaging issue though. As an example, Bison is embedding LibButtonFacade, and its Bison/libs/LibButtonFacade-1.0/Libs/ is full of stuff that shouldn't be there. I'm glad to hear this is a packager bug at least though, since I was at a loss to explain it myself, and at least it's not my or library authors' problem to deal with.
0
ThreatPlates was a bad example; I just searched my Addons/ folder and picked 2 examples; I didn't know it wasn't made with the packager. I have many others though, each with an extra copy of AceGUI-3.0 inside of AceGUI-3.0-SharedMediaWidgets: Archy, BulkMail2Inbox, ChocolateBar, Omen, Prat-3.0, Quartz, SexyMap, Skada, WeakAuras.
Also at least in the case of AceGUI-3.0-SharedMediaWidgets, this only effects Beta and Release ZIPs; alpha ZIPs don't get the extra stuff in them. I have no idea why. For example, look at the most recent alpha and beta of my mod InterruptHelper:
alpha: http://www.wowace.com/addons/interrupthelper/files/36-0-1-4b-3-g3963868/
beta: http://www.wowace.com/addons/interrupthelper/files/38-0-1-5b/
Or this Grid version from 14 March:
A: r1431: http://www.wowace.com/addons/grid/files/7330-r1431/
B: 1.40000.1432-beta: http://www.wowace.com/addons/grid/files/7332-1-40000-1432-beta/
0
ThreatPlates,and many others. It doesn't impact runtime performance, but it wastes bandwidth, and making an already-big ZIP file bigger creates the false impression that Ace addons are bloated.If there's a way to do this correctly, I want to help offer fixes for libraries doing it. Or if it's a bug in the packager, I should report that too. I tried to look to Ace3 for the "right" way of doing it, but Ace3 hard embeds LibStub and CallbackHandler, so it's not an example. Is there a way to do it right?
My best guess is that libraries simply shouldn't put externals in .pkgmeta, and that a user installing standalones is expected to get the dependencies right. Besides, users installing standalones don't want libraries embedding things so it's not even a feature.0