Authors CurseForge

set the tooltip (probably want to use your own so that other mods dont tack their stuff on - unless you need that to happen) via whichever method you want to use, then check the contents of each line (both left and right) one by one.

noting that the OnUpdate (possibly) wont trigger in time (if you leave it in place) so you may or may not get all the data (eg no data at all if its not cached, or you may get the pattern info but nothing on what it makes)

Here's an example to parse the tooltip from a trainer when you are interacting with it.

local _G = getfenv(0) -- Corrected my syntax error
local DataMiner = _G.CreateFrame("GameTooltip", "SyllabusDataMiner", UIParent, "GameTooltipTemplate")

_G.GameTooltip_SetDefaultAnchor(DataMiner, _G.UIParent)

-- Get some information from the trainner tooltip
DataMiner:SetUnit("npc")

local trainer_name = _G["SyllabusDataMinerTextLeft1"]:GetText()
local trainer_line2 = _G["SyllabusDataMinerTextLeft2"]:GetText()
local trainer_line3 = _G["SyllabusDataMinerTextLeft3"]:GetText()
-- Some trainers like the DK Class trainers do not have a line 3 i.e. a trainer role
-- Let's take line 3 for reputation if there is no line 4
local trainer_rep = _G["SyllabusDataMinerTextLeft4"]:GetText() or trainer_line3
DataMiner:Hide()

SetUnit() will allow you to set the tooltip to any other units. You can also use any of the Setxxx methods available for GameTooltip.

local _G = getfenv(0) has nothing to do with the example but since I copied actually code and I wanted it to work, I needed to include it.

Hope that helps

Quote from egingell

Syntax error (unexpected "=" on line 1).

Also, getfenv() is obsolete as of ... I don't even know when. If you want a local _G variable, just set your local _G equal to _G. Order of operations for assignment goes right to left.

local _G = _G -- assign global _G to local _G.

Therre was indeed a syntax thanks but to my knowledge getfenv() is not deprecated, only getglobal() and setglobal() are. I also was under the impression that getfevn() was deprecated for some reason but right now WoW is based on Lua 5.1 and it is very mush alive.

To quote Tholval:

Using getfenv(0) will always grab the Lua global environment - it's not likely, but some idiot could overwrite _G or nil it out.

The only reference to getfenv() deprecation I found was that in Lua 5.2, it and setfevn() will be included in the debug API and that there will be a new concept to environment altogether in 5.2. At that point, there will be a new _ENV but I guess we have to wait and see. (Ref.: http://lua-users.org/wiki/LuaFiveTwo, http://lua-users.org/lists/lua-l/2010-02/msg00753.html)

I might have miss something though. Any reasons why local _G = getfven(0) should not be used?

Using getfenv(0) will always grab the Lua global environment - it's not likely, but some idiot could overwrite _G or nil it out.

Oh yeah? And how you'll get to getfenv at all if it is in _G and it is already overwritten then? And what stops anyone from overwritting or deleting getfenv too?

Quote from Xchg

if not _G then
	[B]--what goes here?[/B]
else
	local _G = _G   ---btw, this does nothing, as the local disappears when the if-then closes
end

IIRC, unless you use the API by calling it from with in your localized _G reference, then this optimization is quite useless. Simply putting local _G = _G at the top of the file has no functional bennifit.

Quote from Xchg

if not _G then
	[B]--what goes here?[/B]
else
	local _G = _G
end

It doesn't matter what goes there. If that happens, a WoW client session is irrecoverably f*cked.

Just for fun, try making a backup copy of your WTF folder, then log into the game and run /script _G = nil. After you pick up the smoking pieces, be sure to restore your backup.

Not every error condition needs to be recoverable from. We're writing a UI mod to a game, not coding fuel pump controller software for a 747. :-)