Upgraded items and GetItemInfo()
I'm having an issue when getting the itemlevel values of specific items for the player or whatever you are /inspecting and the item has been upgraded (the feature added in patch 5.1).
Using GetAverageItemLevel() is not an option here since that only returns the values for what the player is currently wearing and will not work with /inspected players. If you call GetItemInfo() or GetItemStats() they will just return the base itemlevel and stats for the item even if you use a itemlink for your specfically upgraded/enchanted/gemmed item. Example: Code:
function foo() In my head, the fact that GetItemStats() and GetItemInfo() returns the same data for 2 different links is a bug that Blizzard should fix (but how likely is that to happen). Yes; the link is refering to the same itemID, but it should consider enchants, gems, reforge, upgrades and so on. So; Anyone got a suggestion for how to get the correct itemlevel for items, or is there no way to get this done? (edit: parsing tooltips to get the itemlevel isnt an option) |
Quote:
|
You can pull the "upgraded item" information out of the hyperlink, it's the last number after a colon. Each upgrade type has its own ID kind of like the enchant IDs.
I generated a table of which IDs were for what but.. I don't have it any more. If I get around to it I'll try and do it again. I can tell you they were all between 350 and 500. |
Quote:
|
Quote:
I'll look into that. |
Something like:
Code:
-- Construct your saarch pattern based on the existing global string: |
Maybe this will help, I'm copying it here in case something happens to the original.
From Ro on http://us.battle.net/wow/en/forum/topic/7199032730#9: Lua Code:
|
In the end my solution was to simply scan the itemlevel from the tooltip.
http://www.wowwiki.com/UIOBJECT_GameTooltip was really helpful, as well as Phanx's example with regards to using patterns. That should make it work with localized versions of the game. Credit to you Phanx in the latest version of IfThen |
Quote:
Ok... wow... Having to do this amount of testing & work just to return the itemlevel tells me that Blizzard really need to get GetItemInfo() and GetItemStats() fixed so that they work as you should expect when passing in itemlinks to them. It would reduce the overhead of lua code in addons as well as the need for tooltip scanning that should only go to improve the general performance of the game too (doing less is really, really efficient). |
If you're using the tooltip scanning method, I'd recommend keeping a cache of items you've previously scanned, so you don't scan them again. Store them in a table with the item links as keys and the levels as values, and then have GetItemUpgradeLevel return the stored value if it exists, or if not, set the value before returning it so it's cached for next time.
|
Hi,
I'm using a workaround that is pretty crude but is accurate except for rounding issues. Its simply scaling stats proportional to spellpower on caster weapons; I wonder if the actual scales used in the game are anywhere in client data. lua Code:
|
I did a bit of spreadsheet magic to approximate the spellpower values you were using into an exponential function - https://docs.google.com/spreadsheet/...2hwaFBwUEVmLXc
So you could do something like this instead of using your spellpower table: Lua Code:
Edit: Tested ingame and seems to be working pretty well. The only exception I found so far was armor, which seems to scale differently. I have a Sixteen-Fanged Crown, upgraded once. It has 3208 unupgraded armor and 3250 after the upgrade, scaling it like the other stats yields 3330 armor... |
I'll try to bring back this discussion - with the new patch, upgraded stats now compensate for sockets (which aren't upgraded, obviously), so the formula changes.
Since item data now appears to be stored client-side (Item-sparse.db2), you can get stat allocation and socket multipliers for every item, so the formula is something like this: Code:
statAfterUpgrade = (statBeforeUpgrade + socketMultiplier * 160) * upgradeFactor - socketMultiplier * 160 Anyway, the obvious problem is that socketMultiplier is not available in lua code, and there's no general rule to calculate it - e.g. if some items have 1 for primary stat and 0.5 for both secondary stats, some would have 1 for primary, and 0.25/0.75 for secondary (assuming 2 sockets). By the way, here's the new upgrade id to item level table: Lua Code:
|
Quote:
[offtopic]Mirroar, when can we expect a TopFit update for 5.3 please :banana: [/offtopic] |
Edit: found the formulas that gives the precise results. The general scaling formula is 15% every 15 levels, but the exact values are found in RandPropPoints.dbc, for every item level there are 15=5x3 values for different slot types/item qualities. Item data has two extra values for every stat: stat allocation and socket multiplier. Item allocation is in 1/10000ths of the value obtained from RandPropPoints.dbc, and gives the value of the stat before socket penalty. Subtracting (socketMul * 160) from this value gives the exact value of the stat, and makes it easy to calculate stats for different iLevels. 160 comes from gtItemSocketCostPerLevel.dbc, though its always 160 for upgradeable items.
|
Any updates on this? I'm using Ro's version but I no longer play and don't want to have to keep updating my code every patch. The current table I used is below for 5.4
Lua Code:
|
I've been using LibItemUpgradeInfo-1.0 for my !SyLevel addon.
The libarary has also been updated for the changes in 5.4 |
All times are GMT -6. The time now is 09:55 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI