Yes, Antiarc and me optimized the whole Blizzard_CombatLog to use a lot of local upvalues instead, its quite apparent that the last commit was almost a direct .diff file generated from my last commit without edits to remove some of my comments.
Hmm, Zeksie, what are you trying to do? I'll get back to Antiarc and Alexander about un-local-ing some of those things.
Inspection for talents has been fixed as of latest build, you can no longer inspect enemies that are hostile/PvP flagged and you can no longer inspect people that are outside of the inspect range, meaning no more PvP talent detection or auto inspecting people whenever you mouseover them if their outside of 30 yards.
Yes, Antiarc and me optimized the whole Blizzard_CombatLog to use a lot of local upvalues instead, its quite apparent that the last commit was almost a direct .diff file generated from my last commit without edits to remove some of my comments.
Hmm, Zeksie, what are you trying to do? I'll get back to Antiarc and Alexander about un-local-ing some of those things.
Would
function globalFunction()
end
local globalFunction = globalFunction
work?
Also, its probably best not to rely on the combatlog functions since its LoD
Yes, Antiarc and me optimized the whole Blizzard_CombatLog to use a lot of local upvalues instead, its quite apparent that the last commit was almost a direct .diff file generated from my last commit without edits to remove some of my comments.
Hmm, Zeksie, what are you trying to do? I'll get back to Antiarc and Alexander about un-local-ing some of those things.
My specific example, assuming the tokenised code is enabled in the source (it's just commented out atm) will be Grim Reaper showing the same source name that the combat log shows for non-uniquely named mobs (A frog, A frog A, A frog B etc.). In the same breath, parsers and other info tools will want to give the same name too, so that it matches what you see in the log.
So, we'd need to call the CombatLog_String_GetToken function (and/or have access to the data array this will use) to get the same result. Otherwise the user is presented with 2 completely different sets of uniquely generated names. Not matching the log.
A publicly published copy of a local function reference would do just as well, but wouldn't let mods override the token generation to user's tastes. I prefered MobName(number) for example, instead of a letter suffix.
Bam is correct. Using a local will prevent hooking of any kind. Generally speaking, locals are both used for execution speed as well as code protection. In this case, code protection is unwanted here.
In any case, I recommend Zeksie NOT to rely on any function in the Blizzard_CombatLog as it is LoD, and as with any LoD addon, they can be overriden not to ever load by another Combat Log addon that the user can choose to make (that's why it is LoD, to allow it to be overriden). Yes, this means I am recommending Zeksie to rewrite the Grim Reaper module.
For this particular reason, Antiarc and I have moved out all the combat log constants out from FrameXML\AddOns\Blizzard_CombatLog to FrameXML\Constants.lua so that other addons can use these constants without copying them or forcing Blizzard_CombatLog to load first.
A good example of this is the old SuperInspect. SuperInspect replaces the Blizzard_InspectUI and prevents it from loading.
However, the part about locals preventing function hooks to change a small behavior by a small addon to the default combat log UI is true, and I'll discuss this with Antiarc/Alexander.
A publicly published copy of a local function reference would do just as well, but wouldn't let mods override the token generation to user's tastes. I prefered MobName(number) for example, instead of a letter suffix.
Currently, CombatLog_String_GetToken() is in _G[], publicized on line 2116 of Blizzard_CombatLog. Is that insufficient? I understand the current mechanism prevents function hooking to change functionality.
Ahh. totally overlooked the later _G declaration. So yes, that would allow us to at least use the current one.
Assuming the current code is not just there as an example only, in which case it'll need to be necessary to allow overriding the default behaviour, which I had given the option to do until last patch. :) Will see how that plays out.
As for what you said about not relying on them, they're explicitly only used after an ADDON_LOADED of Blizzard_CombatLog.
ChatConfigFrame.lua line #1463 it's not a "offical" API, it's a little function they did.
function UsesGUID(direction)
if ( direction == "SOURCE" and CHATCONFIG_SELECTED_FILTER_FILTERS[1].sourceFlags ) then
for k,v in pairs( CHATCONFIG_SELECTED_FILTER_FILTERS[1].sourceFlags ) do
if ( type(k) == "string" ) then
return true;
end
end
end
if ( direction == "DEST" and CHATCONFIG_SELECTED_FILTER_FILTERS[1].destFlags ) then
for k,v in pairs( CHATCONFIG_SELECTED_FILTER_FILTERS[1].destFlags ) do
if ( type(k) == "string" ) then
return true;
end
end
end
return false;
end
looks like GetSpellLink() also works with direct id numbers. this makes me happy.
edit: just realized it says so in the consolidated changes, but not in the big list of api calls on wow wiki. there, it says just GetSpellLink(spellname)
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHmm, Zeksie, what are you trying to do? I'll get back to Antiarc and Alexander about un-local-ing some of those things.
Would
work?
Also, its probably best not to rely on the combatlog functions since its LoD
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMy specific example, assuming the tokenised code is enabled in the source (it's just commented out atm) will be Grim Reaper showing the same source name that the combat log shows for non-uniquely named mobs (A frog, A frog A, A frog B etc.). In the same breath, parsers and other info tools will want to give the same name too, so that it matches what you see in the log.
So, we'd need to call the CombatLog_String_GetToken function (and/or have access to the data array this will use) to get the same result. Otherwise the user is presented with 2 completely different sets of uniquely generated names. Not matching the log.
A publicly published copy of a local function reference would do just as well, but wouldn't let mods override the token generation to user's tastes. I prefered MobName(number) for example, instead of a letter suffix.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIn any case, I recommend Zeksie NOT to rely on any function in the Blizzard_CombatLog as it is LoD, and as with any LoD addon, they can be overriden not to ever load by another Combat Log addon that the user can choose to make (that's why it is LoD, to allow it to be overriden). Yes, this means I am recommending Zeksie to rewrite the Grim Reaper module.
For this particular reason, Antiarc and I have moved out all the combat log constants out from FrameXML\AddOns\Blizzard_CombatLog to FrameXML\Constants.lua so that other addons can use these constants without copying them or forcing Blizzard_CombatLog to load first.
A good example of this is the old SuperInspect. SuperInspect replaces the Blizzard_InspectUI and prevents it from loading.
However, the part about locals preventing function hooks to change a small behavior by a small addon to the default combat log UI is true, and I'll discuss this with Antiarc/Alexander.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCurrently, CombatLog_String_GetToken() is in _G[], publicized on line 2116 of Blizzard_CombatLog. Is that insufficient? I understand the current mechanism prevents function hooking to change functionality.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAssuming the current code is not just there as an example only, in which case it'll need to be necessary to allow overriding the default behaviour, which I had given the option to do until last patch. :) Will see how that plays out.
As for what you said about not relying on them, they're explicitly only used after an ADDON_LOADED of Blizzard_CombatLog.
No idea what UsesGUID does, it always returns false. I've tried:
UsesGUID() UsesGUID("player") UsesGUID("player",UnitGUID("player")) UsesGUID(UnitGUID("player"),"player") UsesGUID("player","player") UsesGUID(number) UsesGUID(boolean)and they all return false.
ChatConfigFrame.lua line #1463 it's not a "offical" API, it's a little function they did.
edit: just realized it says so in the consolidated changes, but not in the big list of api calls on wow wiki. there, it says just GetSpellLink(spellname)