if the global string is obviously used for something else, e.g. minimap tracking as in this case, and not for the situation you're looking for, I wouldn't count on the translation matching in all languages though...
Yeah, I had some misgivings about recommending this route when I pasted that code.
Edit 2:
I suppose if I really needed to, I could go get the ID of an item that matches the class I want, then use that as a base with GetItemInfo() to compare against the class/subclass localized strings... Storing those initial "base" strings at the start of the addon for use later.
This is the kind of thing that I personally prefer. The code is essentially self-correcting in the face of changes. For example, if Blizzard announces to make the game more accessible to the Facebook image-meme generation, the labels "food and drink" will all be replaced by "noms" then your code won't need any changes. You'll still be getting a known-to-be-good string extracted from your base item, and comparing against that string in the wild. Same if Blizzard releases a game client localized for a new language.
The only hitch is that GetItemInfo will return nils for items which aren't in the client's local cache. Basically, as long as your base food has been seen by any of the player's toons previously in this game session, or is in the bags/bank of the first toon to log in, then the item will be in the cache.
The chances of that happening may be slim, so you might have to have a list of several "known to be food" item IDs, and GetItemInfo on all of them. This certainly isn't the only way to handle this situation, it's just a starting point for thinking.
Another thing you might do is, once you've extracted the string to use for comparisons, store it in your SavedVariables along with the current client locale. For future logins, you continue doing the scan-and-extract thing (because the strings might have changed for some locale), but even if GetItemInfo returns nil for everything, you can still fall back on a previously extracted string as "this is better than nothing".
Nothing immediately jumps out at me, but try a couple things (not solutions, just to get more information): what happens when you only add the ListInteractionsGroup at the end, and none of the others? (That is, comment out the other lines). If it becomes visible, start uncommenting the other "scroller:AddChild" lines; at what point do things go wrong again?
It's been a while since I looked at AceGUI code, but I seem to recall needing to set some layout options to each container before things operated smoothly.
You might also look for boss units "boss1" through "boss5" and report the results of UnitName() on each unit, perhaps only starting the work after you detect an INSTANCE_ENCOUNTER_ENGAGE_UNIT event.
The 'namespace' object is just a table like any other. It's created for you, but it's not special other than that. I don't understand the rest of your question.
I've been having only one problem with SUF all this time, but it's been consistent since late 6.0 or early 6.1. For the first few seconds after joining a raid, everything is fine. After that, new players joining the raid aren't shown in the raid frames, maybe 90% of the time. Existing raid frames, including MT and MA, continue to update their own units (displays of health, mana, debuffs, etc), but new people simply aren't shown.
The problem is unique to SUF, as the new people show up just fine in the Blizzard raid roster, chat, other combat events, etc.
It doesn't seem to matter if they join while I'm in combat or out. Doesn't seem to matter how long I wait, they never appear. Trying a /reload introduces an ugly variant of the problem: all players in groups 2 through 8 are properly updated, but all of group 1's frames simply vanish.
The only workaround I've found is to open /suf, toggle off the "Lock Frames" option (which swaps all units to the fake placement-only units), and then toggle it back on. This forces a refresh of everything, and properly displays all current players, the MT/MA frames, and so on. It does not however solve the problem going forward; even after doing this, if a player joins, is replaced, etc, the raid frame will typically not be updated.
I've been unable to even guess as to why it only happens most of the time, and not all of the time. Or what's causing it to happen in the first place. I've tried tracing the handlers for GROUP_ROSTER_UPDATE in modules/units.lua and it's greek to me.
Not sure if this is the right place but keep getting this error
Message: ...nterface\AddOns\ShadowedUnitFrames\modules\runes.lua:87: attempt to perform arithmetic on local 'startTime' (a nil value)
Time: 07/26/15 16:07:07
Count: 6
Stack: [C]: ?
...nterface\AddOns\ShadowedUnitFrames\modules\runes.lua:87: in function `?'
...nterface\AddOns\ShadowedUnitFrames\modules\units.lua:225: in function <...nterface\AddOns\ShadowedUnitFrames\modules\units.lua:222>
Locals:
This is ticket 885, largely ignored. There's a bit of a kludge fix posted there, which will at least avoid errors.
It's not under active development or maintenance as far as I know, but it still works the same as it ever did. I use it in a couple of my addons, and it definitely takes some getting used to, but works fine.
I really like your unit frames, however, unless I am being challenged... I dont know how to get the raid frames to work. They dont even show up. Im not sure what Im doing wrong. Help, please? :(
/suf -> Enabled Units -> Raid
There's a bug in that initially joining a raid, or doing a /reload, will quite often cause one of the raid's subgroups to not display at all. Most reliable workaround is /suf and then on the general tab, toggle "lock frames" off and back on.
0
No.
0.946067949631742
Be aware that curse.com displays them according to the phase of the moon, sometimes, maybe, not the same as how this site does it.
0
You want www.deadlybossmods.com but read the "how to report bugs" sticky there first.
0
Yeah, I had some misgivings about recommending this route when I pasted that code.
This is the kind of thing that I personally prefer. The code is essentially self-correcting in the face of changes. For example, if Blizzard announces to make the game more accessible to the Facebook image-meme generation, the labels "food and drink" will all be replaced by "noms" then your code won't need any changes. You'll still be getting a known-to-be-good string extracted from your base item, and comparing against that string in the wild. Same if Blizzard releases a game client localized for a new language.
The only hitch is that GetItemInfo will return nils for items which aren't in the client's local cache. Basically, as long as your base food has been seen by any of the player's toons previously in this game session, or is in the bags/bank of the first toon to log in, then the item will be in the cache.
The chances of that happening may be slim, so you might have to have a list of several "known to be food" item IDs, and GetItemInfo on all of them. This certainly isn't the only way to handle this situation, it's just a starting point for thinking.
Another thing you might do is, once you've extracted the string to use for comparisons, store it in your SavedVariables along with the current client locale. For future logins, you continue doing the scan-and-extract thing (because the strings might have changed for some locale), but even if GetItemInfo returns nil for everything, you can still fall back on a previously extracted string as "this is better than nothing".
0
So your example becomes
and now will "auto-localize" between clients.
0
It's been a while since I looked at AceGUI code, but I seem to recall needing to set some layout options to each container before things operated smoothly.
0
Working like a charm here. Thanks!
0
0
0
local bgframe = { ...... } namespace.bgframe = bgframeor
namespace.bgframe = { ....... }0
The problem is unique to SUF, as the new people show up just fine in the Blizzard raid roster, chat, other combat events, etc.
It doesn't seem to matter if they join while I'm in combat or out. Doesn't seem to matter how long I wait, they never appear. Trying a /reload introduces an ugly variant of the problem: all players in groups 2 through 8 are properly updated, but all of group 1's frames simply vanish.
The only workaround I've found is to open /suf, toggle off the "Lock Frames" option (which swaps all units to the fake placement-only units), and then toggle it back on. This forces a refresh of everything, and properly displays all current players, the MT/MA frames, and so on. It does not however solve the problem going forward; even after doing this, if a player joins, is replaced, etc, the raid frame will typically not be updated.
I've been unable to even guess as to why it only happens most of the time, and not all of the time. Or what's causing it to happen in the first place. I've tried tracing the handlers for GROUP_ROSTER_UPDATE in modules/units.lua and it's greek to me.
0
0
This is ticket 885, largely ignored. There's a bit of a kludge fix posted there, which will at least avoid errors.
0
0
/suf -> Enabled Units -> Raid
There's a bug in that initially joining a raid, or doing a /reload, will quite often cause one of the raid's subgroups to not display at all. Most reliable workaround is /suf and then on the general tab, toggle "lock frames" off and back on.