GlueStrings.lua from ingame

[Rainrider]

Is there a way to access the contents of GlueStrings.lua from ingame? I'm particularly interested in CHARACTER_SELECT_INFO_GHOST to get translations for 'Ghost' but

/dump CHARACTER_SELECT_INFO_GHOST

returns nothing.

[Gethe]

Try this:

/run print(CHARACTER_SELECT_INFO_GHOST)

[Vlad]

It would still return nothing, i.e. "nil" if that global doesn't exist.

[Phanx]

Originally Posted by Rainrider I'm particularly interested in CHARACTER_SELECT_INFO_GHOST to get translations for 'Ghost' ....

You can use GetSpellInfo to get translations for anything that gives you a debuff, including Ghost:

/dump (GetSpellInfo(8326))

The extra parentheses are so you'll only get the first return (the localized name) rather than the whole list of returns. If you're using it in another context you don't need them:

local GHOST = GetSpellInfo(8326)

print("You are a " .. GetSpellInfo(8326))

[Rainrider]

The problem is that the german translation for the spell is "Geisterscheinung" which actually means "ghost appearance" and that's kind of lengthy. Funny enough they translated it "Geist" for CHARACTER_SELECT_INFO_GHOST. I'd rather not truncate based on client locale if I could avoid that.

So no way to access GlueStrings.lua from an addon?

[Vlad]

Rainrider, no no, if it's in globalstrings.lua then it's a global variable accessible from all lua related code.

Phanx was just trying to provide an alternative way to obtain the translation of the word "Ghost" if "CHARACTER_SELECT_INFO_GHOST" is not defined, i.e. is nil. Like I said if using "/dump CHARACTER_SELECT_INFO_GHOST" returns nil then chances are it's not a defined variable, maybe the globalstrings.lua you are looking at is outdated?

Actually, by the look of the string itself it appears you might have looked at the "glue" folder, those files are only used at login and not when in-game, so those are simply not loaded when you are in-game, only at the login screen. That explains why CHARACTER_SELECT_INFO_GHOST doesn't exist when dumping, hehe.

There is no alternative for the word "Ghost" but like Phanx said, you can use a spell for instance, to obtain the word as spells are localized too! Just look at Phanx' post.

[Rainrider]

@Vlad

Yes, I do look at GlueXML/GlueStrings.lua, never said something about GlobalStrings.lua. I also found out it is not in _G, that's the reason I came here to ask. If something is in not in _G it doesn't mean it is not somewhere else or accessible in some other way.

Based on Phanx proposal my code currently looks like this:

if (UnitIsDead(unit)) then
    return _G["DEAD"]
elseif (UnitIsGhost(unit)) then
    local ghost = GetSpellInfo(8326)
    if (GetLocale() == "deDE") then
        ghost = ghost:sub(1, 5)
    end
    return ghost
elseif (not UnitIsConnected(unit)) then
    return _G["PLAYER_OFFLINE"]
end

I'm still interested in accessing what's in GlueStrings.lua though if this is possible.

[SDPhantom]

To further clarify what Vlad said, WoW runs two completely isolated Lua systems. GlueXML is what is used to display and run everything up to and including the Character Select and Character Creation screens. The GlueXML system has its own API to handle these related screens. The other system is FrameXML and this is what handles the game itself after you login and have chosen your character. Since addons are loaded into FrameXML, there is no way to modify or even access the GlueXML system.

[Rainrider]

Originally Posted by SDPhantom Since addons are loaded into FrameXML, there is no way to modify or even access the GlueXML system.

Thank you Thanks to Phanx for the proposal and to Vlad for the patience too

[SDPhantom]

Originally Posted by Rainrider Based on Phanx proposal my code currently looks like this: if (UnitIsDead(unit)) then     return _G["DEAD"] elseif (UnitIsGhost(unit)) then     local ghost = GetSpellInfo(8326)     if (GetLocale() == "deDE") then         ghost = ghost:sub(1, 5)     end     return ghost elseif (not UnitIsConnected(unit)) then     return _G["PLAYER_OFFLINE"] end

Instead of truncating the string, you can have your code override the translation on load. The following example uses the localized spell name, then checks for specific locales to see if it needs to be changed. Replacing the entire string with a new one is less taxing on the system and if they ever decide to change the translation, it won't be screwed up.

local GHOST,Locale=GetSpellInfo(8326),GetLocale();
if Locale=="deDE" then
    GHOST="Geist";
end
 
local function UnitDeadText(unit)
    if UnitIsDead(unit) then
        return DEAD;
    elseif UnitIsGhost(unit) then
        return GHOST;
    elseif not UnitIsConnected(unit) then
        return PLAYER_OFFLINE;
    end
end

Another performance issue I fixed; unless the table field is an invalid variable name or you need to access a series of names based on a looping mechanism or any dynamic method, you should avoid using _G[].

To better understand this problem, Lua operates by looking through locals first, upvalues (locals in a higher scope), and finally global. When accessing a global by _G[], you're telling Lua to access the global list for a copy of itself, then access your variable.

[Rainrider]

Nice to know, thanks for the advice. I use _G[] to skip local checks, as I thought it would be wasted search time, and to emphasize those are global constants to make code more readable. I also saw some addons defining local _G = _G and a search on wowinterface idicated this is to speed up global access. If I understand you correctly using _G[] is kind of the same as using local _G = _G in a local scope (not as upvalue), isn't it?

[semlar]

I don't think using _G would skip any steps because lua would still look up _G in the local scope before moving to the global one.

[Phanx]

Originally Posted by Rainrider I also saw some addons defining local _G = _G and a search on wowinterface idicated this is to speed up global access. If I understand you correctly using _G[] is kind of the same as using local _G = _G in a local scope (not as upvalue), isn't it?

local _G = _G is totally useless unless you are looking up dynamically constructed keys like:

for i = 1, 5 do 
    local chatFrame = _G["ChatFrame"..i]
    -- do something with chatFrame
end

Doing things like _G.UnitName("player") is useless and just makes your code more cluttered. If you know that you want to use UnitName just use it directly.

Upvaluing functions is not really that useful as a general rule, and just adds code clutter. The only time the speed difference is even possibly meaningful is if you are calling the function inside an OnUpdate script, COMBAT_LOG_EVENT_UNFILTERED handler, or other context where it is called potentially dozens or hundreds of times per second. If you're calling a function once each time PLAYER_ENTERING_WORLD fires, for example, upvaluing that function doesn't realistically add anything.

Remember, the first rule of program optimization -- don't do it -- and the second rule -- don't do it yet. Get your code working first, and then you can go over it to optimize, but even then don't go overboard.

[Rainrider]

Thank you very much for all the advises, I really appreciate it. I only upvalue API functions I use in code reacting to UNIT_{HEALTH|POWER}_FREQUENT in my oUF layout, as I use those events on a lot of frames (which is probably a waste and is on my todo list to check and change). I don't have any experience in CPU profiling in WoW or in general and would be glad to get some pointers in that direction, though I believe I have some way left to go until my code reaches a satisfying level of functionality and readability.

Thanks again for all your help!

[SDPhantom]

Since locals and upvalues are registry entries in Lua, the lookups for them are negligible. Relatively, all of the time spent is the table indexing operation used to find a value in the global environment. Accessing _G[] effectively doubles the time spent accessing a global since it requests an indexing for _G in the global environment, which is a copy of itself, then requests an index of that copy. If you had stored _G in a local pointer and used that instead, past the setup, it would offer no difference to performance since it would still be using an index operation to look up a value.