so i was just poking around with the GetSpellLink() stuff...
it looks like you can pass it a 2nd argument. as long as that 2nd argument isn't false, then the first argument seems to be the index from your spellbook starting with the first spell on the first tab and proceeding thru pages and tabs without any gaps for non-assigned spell slots.
guid = UnitGUID("unit")
Returns a string representing a unique identifier for the given unit. This is the same string that is used in the combat log to identify a unit.
Someone who can post on the US forums should request additional combat log filter functions to query the current filters. For the moment if you want to temporarily change them and put them back, you have to put some convoluted hooks in the reset/set functions to remember what they were.
So, something like CombatLogGetNumFilters() and CombatLogGetFilter() would seem to be in order.
Really bugs me they can't share those forums. The EU forum gets totally ignored by the devs or any other blue poster with anything whatsoever to do with development. Seems to be no point posting there any more.
Then they go and break the EU ptr so noone can log in to it... another wasted day with no progress :|
Also, thought about it further, and there's no way to query the currently viewed entry number, so we'd also need a GetCombatLogEntryNumber(). I know it's not a lot of work to do a quick seek to a timestamp, but seems some wasted effort when the simpler index is stored somewhere already.
Am I right to assume that the new UnitGUID() function will possibly have the following consequences?
Threat-meters with GUID indexed tables, that will give you very accurate threat information on your current target (UnitGUID("target")) or on a leader-specified main-target (a leader-announced GUID).
DOT timers with GUID indexed debuff-tables (updated by monitoring the combat-log), that allow you to monitor very accurately the duration of buffs and debuffs on your current target. Independent of their origin.
Arena addons that will get the enemy's GUID on mouseover, with the ability to display real-time HP updates through GameTooltip:SetHyperlink("unit:" .. guid).
Just want to know if this will really be possible, and arise the question whether is actually should be.
1) Yeah Threat-2.0 and Omen2 in the branches for the 2.4 ptr already uses this extra information and can pull stunts that were completely impossible before. That is per-GUID threat attribution is a done deal which allows proper tracking of AoE aggro for example.
2) Buff and debuffs are trickier, because SPELL_AURA_APPLIED doesn't include a source. I.e. you see that the aura is applied but not by whom. Some spells preceed this by a SPELL_CASTING_SUCCESS, but currently by no means all. Slouken has advertised that an improvement in this department will happen in a future patch (not 2.4 though).
3) I don't know what the status of the tooltip linking is but it's not clear if we'll keep that functionality. In fact I haven't had a chance to test this on the latest PTR build.
maxGroup returns an int with how the maximum amount of people who can queue, 5 means you can only queue as a party, unsure if it returns nil or 10/15 for WSG/EOTS/AB.
My guess is that "mapFull" is actually "bracketMinLevel" but they did a bad job at naming it, will have to wait for PTR to come up to verify.
Had already implemented some stuff in my new Grim Reaper to do things like use the CombatLog_String_GetToken function so unique names shown match Blizzard's (when the blizz code is uncommented ofc (have[had] my own override of that so it works)). But now much of it is local and untouchable now. :|
Along with the Blizzard_CombatLog_CurrentSettings which would have been handy I think.
Looks like Xinhuan had some input on this, so perhaps you could revise what was made local. In fact it's been somewhat of a standard that Blizzard code is not localised, which has always aided mod development.
Yes, we could replace the whole combat log with another one, but when some mod wants to USE part of the blizzard code as I said in this example, to give the same result in a different view, then it's a necessary evil.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
thanks.. it's on my watchlist now :)
it looks like you can pass it a 2nd argument. as long as that 2nd argument isn't false, then the first argument seems to be the index from your spellbook starting with the first spell on the first tab and proceeding thru pages and tabs without any gaps for non-assigned spell slots.
i tried it with GetSpellInfo but it failed. it said something about a bad spell id, too.
http://forums.worldofwarcraft.com/thread.html?topicId=2968233433&postId=47749334207&sid=1#416
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHot.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSo, something like CombatLogGetNumFilters() and CombatLogGetFilter() would seem to be in order.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDone Zeksie.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThanks :)
Really bugs me they can't share those forums. The EU forum gets totally ignored by the devs or any other blue poster with anything whatsoever to do with development. Seems to be no point posting there any more.
Then they go and break the EU ptr so noone can log in to it... another wasted day with no progress :|
Also, thought about it further, and there's no way to query the currently viewed entry number, so we'd also need a GetCombatLogEntryNumber(). I know it's not a lot of work to do a quick seek to a timestamp, but seems some wasted effort when the simpler index is stored somewhere already.
Actually we have that on live (though maybe its not documented). GetQuestLogRewardTitle got added though.
Decided to see what they removed as well:
Just want to know if this will really be possible, and arise the question whether is actually should be.
anyway at this time, there is no function where GUID is a parameter, but even, I don't think it could be more exploitable than using UnitName().
2) Buff and debuffs are trickier, because SPELL_AURA_APPLIED doesn't include a source. I.e. you see that the aura is applied but not by whom. Some spells preceed this by a SPELL_CASTING_SUCCESS, but currently by no means all. Slouken has advertised that an improvement in this department will happen in a future patch (not 2.4 though).
3) I don't know what the status of the tooltip linking is but it's not clear if we'll keep that functionality. In fact I haven't had a chance to test this on the latest PTR build.
+ local mapName, mapDescription, minLevel, maxLevel, mapID, mapX, mapY, mapFull, levelMax, maxGroup = GetBattlefieldInfo();
API CHANGE! And http://www.wowwiki.com/API_GetBattlefieldInfo looks really out of date unless this isn't the first time its changed on this PTR.
I haven't updated that page in 2 years, but it hasn't changed.
Live:
mapName, mapDescription, minLevel, maxLevel, mapID, mapX, mapY, mapFull
But that doesn't make sense, because when you do a /dump it clearly indicates that the returns are actually
mapName, mapDescription, minLevel, maxLevel, mapID, mapX, mapY, bracketMinLevel, bracketMaxLevel.
Because minLevel is 51, maxLevel is 70, bracketMinLevel is 61 and bracketMaxLevel is 70 when viewing the AV queue window.
PTR:
mapName, mapDescription, minLevel, maxLevel, mapID, mapX, mapY, mapFull, bracketMaxLevel, maxGroup = GetBattlefieldInfo();
maxGroup returns an int with how the maximum amount of people who can queue, 5 means you can only queue as a party, unsure if it returns nil or 10/15 for WSG/EOTS/AB.
My guess is that "mapFull" is actually "bracketMinLevel" but they did a bad job at naming it, will have to wait for PTR to come up to verify.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHad already implemented some stuff in my new Grim Reaper to do things like use the CombatLog_String_GetToken function so unique names shown match Blizzard's (when the blizz code is uncommented ofc (have[had] my own override of that so it works)). But now much of it is local and untouchable now. :|
Along with the Blizzard_CombatLog_CurrentSettings which would have been handy I think.
Looks like Xinhuan had some input on this, so perhaps you could revise what was made local. In fact it's been somewhat of a standard that Blizzard code is not localised, which has always aided mod development.
Yes, we could replace the whole combat log with another one, but when some mod wants to USE part of the blizzard code as I said in this example, to give the same result in a different view, then it's a necessary evil.