Yes, the effects of gems are handled as enchantments. Enchantments also contains a free form string to represent the content of the tooltip.
For the context of tooltips, they work like spells, and are subject to the same flaw (typos, variants), except it's a little bit harder to get the content of the string than spells.
The way I see it, if someone wanted to absolutely use the new API, they would still need to get the Gem itemlinks by using GetItemGem, at which point there are 2 choices, get the GemID and check against a locale independent gem table which will provide the bonuses automagically OR set a tooltip and scan against predetermined, localized patterns (more or less the same as it is now). None of these solutions are particularly elegant or attractive.
Ultimately what can be done about handling enchants ? Sniff the itemlink for the enchant ID and then what ? Check against an independent table of enchant ID's ? Set a tooltip and scan it anyway and how are you going to differentiate between the enchant line and other lines ? Checking for green color won't work properly. What about active socket bonuses ? What about (countable) set bonuses ? I haven't really seen any of these covered by the new API, in a sense that it can safely replace (even parts of) a full parser.
I have recently introduced into LIB a small lists of enchants that have very specific names that have no direct relation to heir effects, and I match the enchantId of the itemlink with this database.
For other effects that uses known spell data, I construct a pattern from the content of a tooltip, to get the value independant of the locale.
I used to do the same for enchants, before doing what I described above. It's really difficult to generalise this idea, as there is no API that gives the spells that are "attached" to items, either directly, through sets, or through socket bonus.
10046 finally made LibBabbleClass obsolete. see FillLocalizedClassList() API and the LOCALIZED_CLASS_NAMES_MALE and LOCALIZED_CLASS_NAMES_FEMALE global tables.
Does anyone have an idea of the purpose of the new "nonBlocking" XML attributes to textures ? I haven't been able to guess what it's meant to describe.
They also added a third comparison tooltip, which is also strange. How could 3 comparison tooltips be necessary ?
The third tip has been there for a while, it's for comparing glyphs... which they never implemented. Just like how they added an "always compare" cvar, then never exposed it in the config panels.
In the latest build, "Normal" and "Heroic" dungeon difficulty labels in the globalstrings have been replaced by "5 Player" and "5 Player (Heroic)" as I expected in my original post.
Moreover, the GetSavedInstanceInfo(index) call has been extended, in regards to its return args and is now :
index has the usual range of 1 to GetNumSavedInstances().
instanceDifficulty: Should vary from 1 to 4, isRaid must be checked as well to determine the instance type. locked: Not 100% sure but should return whether current player is locked or not in the specific instance (ID). extended: Whether the specific instance (ID) has been extended beyond its original expiration time (afaik + 1 week ?). instanceIDMostSig : Not sure. It is an instance ID in a different format, most likely. isRaid: true (or 1 not completely sure) if the instance is a raid instance.
Heirloom items show 2 tooltips on ptr:
"player level" stats
(assuming this.. it shows 80 on my lvl80 chars, don't have a lower lvl on ptr to check)
and lvl1 stats.
We need more people moaning to have the level returned from the GUID info fetch!
The GUID has a fixed representation for class and race. However Level is a dynamic value. IMO they'd be more likely to have the level as a event arg. Now that'd be cool :)
Character name auto-completion for the chat frame, pop-ups, and mail interface can be enabled through an interface option in the Development settings.
Character names can now be colorized according to class in the chat frame through an interface option in the Development settings.
Where can I find these development settings? Or is it just cvars?
Classcolored names in the chatframe can be switched on for each channel in the chatoptions where you normally select which channel is shown for the current chattab
In the latest build, "Normal" and "Heroic" dungeon difficulty labels in the globalstrings have been replaced by "5 Player" and "5 Player (Heroic)" as I expected in my original post.
Moreover, the GetSavedInstanceInfo(index) call has been extended, in regards to its return args and is now :
index has the usual range of 1 to GetNumSavedInstances().
instanceDifficulty: Should vary from 1 to 4, isRaid must be checked as well to determine the instance type. locked: Not 100% sure but should return whether current player is locked or not in the specific instance (ID). extended: Whether the specific instance (ID) has been extended beyond its original expiration time (afaik + 1 week ?). instanceIDMostSig : Not sure. It is an instance ID in a different format, most likely. isRaid: true (or 1 not completely sure) if the instance is a raid instance.
Had the chance to verify a few things today, after killing the Twin Val'kyr in 25 man and getting saved.
'instanceDifficulty' : 1 - 4 as expected.
'locked' seems to return either 1 or nil.
'extended' is the same.
'instanceIDMostSig' is indeed a mysterious instance ID (need to check the RaidInfoFrame lua again tbh).
'isRaid' is a normal true/false boolean.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
For the context of tooltips, they work like spells, and are subject to the same flaw (typos, variants), except it's a little bit harder to get the content of the string than spells.
Ultimately what can be done about handling enchants ? Sniff the itemlink for the enchant ID and then what ? Check against an independent table of enchant ID's ? Set a tooltip and scan it anyway and how are you going to differentiate between the enchant line and other lines ? Checking for green color won't work properly. What about active socket bonuses ? What about (countable) set bonuses ? I haven't really seen any of these covered by the new API, in a sense that it can safely replace (even parts of) a full parser.
For other effects that uses known spell data, I construct a pattern from the content of a tooltip, to get the value independant of the locale.
I used to do the same for enchants, before doing what I described above. It's really difficult to generalise this idea, as there is no API that gives the spells that are "attached" to items, either directly, through sets, or through socket bonus.
Does anyone have an idea of the purpose of the new "nonBlocking" XML attributes to textures ? I haven't been able to guess what it's meant to describe.
They also added a third comparison tooltip, which is also strange. How could 3 comparison tooltips be necessary ?
Gear linked to dual spec ala crossdresser? At least that's what I hope.
Yep, when comparing an item to something you can equip in two places, it needs to compare to what you have in both.
But that only requires 2 comparison tips, not 3.
Moreover, the GetSavedInstanceInfo(index) call has been extended, in regards to its return args and is now :
index has the usual range of 1 to GetNumSavedInstances().
instanceDifficulty: Should vary from 1 to 4, isRaid must be checked as well to determine the instance type.
locked: Not 100% sure but should return whether current player is locked or not in the specific instance (ID).
extended: Whether the specific instance (ID) has been extended beyond its original expiration time (afaik + 1 week ?).
instanceIDMostSig : Not sure. It is an instance ID in a different format, most likely.
isRaid: true (or 1 not completely sure) if the instance is a raid instance.
"player level" stats
(assuming this.. it shows 80 on my lvl80 chars, don't have a lower lvl on ptr to check)
and lvl1 stats.
Maybe it explains the extra tooltip?
The GUID has a fixed representation for class and race. However Level is a dynamic value. IMO they'd be more likely to have the level as a event arg. Now that'd be cool :)
Where can I find these development settings? Or is it just cvars?
Had the chance to verify a few things today, after killing the Twin Val'kyr in 25 man and getting saved.
'instanceDifficulty' : 1 - 4 as expected.
'locked' seems to return either 1 or nil.
'extended' is the same.
'instanceIDMostSig' is indeed a mysterious instance ID (need to check the RaidInfoFrame lua again tbh).
'isRaid' is a normal true/false boolean.