Upgraded items and GetItemInfo()

Jarod24 · 12-06-12, 10:18 AM

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()
	--lookup the players mainhand weapon (slotid==16)
	local slot		= 16;
	local _, itemBasic	= GetItemInfo( GetInventoryItemID("player", slot) ); --get the basic itemlink just using itemID
	local itemUpgraded	= GetInventoryItemLink("player", slot); --get the itemlink for the specific item that the player has equipped with enchants, gems, upgrades, everything.
	
	print("basic:"..itemBasic);
	print("upgraded:"..itemUpgraded);
	--if you just compare the two links you see that their info is different, and clicking on them they show different info.
	
	local infoBasic		= GetItemInfo(itemBasic);
	local infoUpgraded	= GetItemInfo(itemUpgraded);
	--these two will return the exact same results even tho the itemlink-data isnt the exact same
	
	local statBasic		= GetItemStats(itemBasic);
	local statUpgraded	= GetItemStats(itemUpgraded);
	--these two will also return the exact same results even tho the itemlink's are not the same
	
	local delta = GetItemStatDelta(itemBasic, itemUpgraded);
	--this will return an empty table; presumably it thinks the items are identical aswell.
	
	return itemBasic, itemUpgraded, infoBasic, infoUpgraded, statBasic, statUpgraded, delta;
end

I have been looking into the Blizzard_ItemUpgradeUI.lua and PaperDollFrame.lua for ideas on how to solve this but it seems that whomever coded that did not think of non-UI options, (functions like GetItemUpgradeItemInfo() do not accept input arguments but instead is hardcoded to only return stats for the item currently placed in the upgrade-UI).

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)

Phanx · 12-06-12, 08:34 PM

Originally Posted by Jarod24

(edit: parsing tooltips to get the itemlevel isnt an option)

Even if you're not displaying a tooltip, if you have an item ID you can always send it to a hidden tooltip and scan that.

semlar · 12-07-12, 12:13 AM

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.

Jarod24 · 12-07-12, 03:21 AM

Originally Posted by semlar

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.

Yes i did see that. Looked like they're using a bitpattern of sorts, and i did find a very large list at wowwiki (i think). However that list wasnt up to date (wrath or cata used the 300 series of numbers afaik)

Jarod24 · 12-07-12, 03:22 AM

Originally Posted by Phanx

Even if you're not displaying a tooltip, if you have an item ID you can always send it to a hidden tooltip and scan that.

Hmmm, hidden tooltip you say.
I'll look into that.

Phanx · 12-07-12, 05:00 AM

Something like:

Code:

-- Construct your saarch pattern based on the existing global string:
local S_UPGRADE_LEVEL   = "^" .. gsub(ITEM_UPGRADE_TOOLTIP_FORMAT, "%%d", "(%%d+)")

-- Create the tooltip:
local scantip = CreateFrame("GameTooltip", "MyScanningTooltip", nil, "GameTooltipTemplate")
scantip:SetOwner(UIParent, "ANCHOR_NONE")

-- Create a function for simplicity's sake:
local function GetItemUpgradeLevel(itemLink)
    -- Pass the item link to the tooltip:
    scantip:SetHyperlink(itemLink)

    -- Scan the tooltip:
    for i = 2, scantip:NumLines() do -- Line 1 is always the name so you can skip it.
        local text = _G["MyScanningTooltipTextLeft"..i]:GetText()
        if text and text ~= "" then
            local currentUpgradeLevel, maxUpgradeLevel = strmatch(text, S_UPGRADE_LEVEL)
            if currentUpgradeLevel then
                return currentUpgradeLevel, maxUpgradeLevel
            end
        end
    end
end

-- Now you can just call the function to get the levels:
local currentUpgradeLevel, maxUpgradeLevel = GetItemUpgradeLevel(itemLink)

semlar · 12-07-12, 11:56 AM

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:

function GetActualItemLevel(link)
  local levelAdjust={ -- 11th item:id field and level adjustment
    ["0"]=0,["1"]=8,["373"]=4,["374"]=8,["375"]=4,["376"]=4,
    ["377"]=4,["379"]=4,["380"]=4,["445"]=0,["446"]=4,["447"]=8,
    ["451"]=0,["452"]=8,["453"]=0,["454"]=4,["455"]=8,["456"]=0,
    ["457"]=8,["458"]=0,["459"]=4,["460"]=8,["461"]=12,["462"]=16}
  local baseLevel = select(4,GetItemInfo(link))
  local upgrade = link:match(":(%d+)\124h%[")
  if baseLevel and upgrade then
    return baseLevel + levelAdjust[upgrade]
  else
    return baseLevel
  end
end

Probably less reliable than just pulling the item level straight out of the tooltip.

Jarod24 · 12-07-12, 02:14 PM

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

Jarod24 · 12-07-12, 02:23 PM

Originally Posted by semlar

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:

function GetActualItemLevel(link)
  local levelAdjust={ -- 11th item:id field and level adjustment
    ["0"]=0,["1"]=8,["373"]=4,["374"]=8,["375"]=4,["376"]=4,
    ["377"]=4,["379"]=4,["380"]=4,["445"]=0,["446"]=4,["447"]=8,
    ["451"]=0,["452"]=8,["453"]=0,["454"]=4,["455"]=8,["456"]=0,
    ["457"]=8,["458"]=0,["459"]=4,["460"]=8,["461"]=12,["462"]=16}
  local baseLevel = select(4,GetItemInfo(link))
  local upgrade = link:match(":(%d+)\124h%[")
  if baseLevel and upgrade then
    return baseLevel + levelAdjust[upgrade]
  else
    return baseLevel
  end
end

Probably less reliable than just pulling the item level straight out of the tooltip.

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).

Phanx · 12-07-12, 10:38 PM

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.

d07.RiV · 12-13-12, 01:51 PM

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:

local spTable = {
  [458] = 4914,
  [463] = 5152,
  [466] = 5293,
  [470] = 5496,
  [471] = 5550,
  [474] = 5704,
  [476] = 5812,
  [478] = 5920,
  [480] = 6032,
  [483] = 6206,
  [484] = 6261,
  [487] = 6441,
  [489] = 6564,
  [490] = 6628,
  [491] = 6685,
  [493] = 6812,
  [494] = 6879,
  [496] = 7007,
  [497] = 7071,
  [498] = 7140,
  [500] = 7272,
  [501] = 7337,
  [502] = 7408,
  [503] = 7478,
  [504] = 7548,
  [505] = 7619,
  [506] = 7688,
  [507] = 7761,
  [508] = 7836,
  [509] = 7907,
  [510] = 7980,
  [511] = 8054,
  [512] = 8132,
  [513] = 8206,
  [514] = 8286,
  [515] = 8364,
  [516] = 8441,
  [517] = 8518,
  [518] = 8603,
  [519] = 8680,
  [520] = 8761,
  [521] = 8841,
  [524] = 9093,
  [525] = 9179,
  [528] = 9439,
  [532] = 9797,
}
local upTable = {
  [1]   =  8, -- 1/1
  [373] =  4, -- 1/2
  [374] =  8, -- 2/2
  [375] =  4, -- 1/3
  [376] =  4, -- 2/3
  [377] =  4, -- 3/3
  [379] =  4, -- 1/2
  [380] =  4, -- 2/2
  [445] =  0, -- 0/2
  [446] =  4, -- 1/2
  [447] =  8, -- 2/2
  [451] =  0, -- 0/1
  [452] =  8, -- 1/1
  [453] =  0, -- 0/2
  [454] =  4, -- 1/2
  [455] =  8, -- 2/2
  [456] =  0, -- 0/1
  [457] =  8, -- 1/1
  [458] =  0, -- 0/4
  [459] =  4, -- 1/4
  [460] =  8, -- 2/4
  [461] = 12, -- 3/4
  [462] = 16, -- 4/4
}
function GetItemStatsUp(link, table)
  local result = GetItemStats(link, table)
  if not result then
    return result
  end
  local id = tonumber (link:match ("item:%d+:%d+:%d+:%d+:%d+:%d+:%-?%d+:%-?%d+:%d+:%d+:(%d+)"))
  local _, _, _, iLvl = GetItemInfo(link)
  iLvl = iLvl or 0
  if iLvl >= 458 and upTable[id] then
    local iLvl2 = iLvl + upTable[id]
    if iLvl2 > iLvl and spTable[iLvl] and spTable[iLvl2] then
      for k, v in pairs(result) do
        if tonumber(v) then
          result[k] = math.floor(tonumber(v) * spTable[iLvl2] / spTable[iLvl] + 0.5)
        end
      end
    end
  end
  return result
end

Mirroar · 01-06-13, 05:53 AM

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:

local exp, mult = 1.00936754973658, 68.6945347210951
local spellpower = mult * (exp ^ iLvl)

The error should be pretty small (a max of 4 points of spellpower with the given values, so < 0.1%) and you have the added benefits of it working for item levels not in your table.

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...

d07.RiV · 05-29-13, 01:29 PM

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

I'm getting upgradeFactor from weapon damage data (ItemDamageTwoHand.dbc), and it seems to work fine except for rounding issues (maybe if I find out how to use stat allocation values I'd get it right).

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:

local upTable = {
  [1]   =  8, -- 1/1
  [373] =  4, -- 1/2
  [374] =  8, -- 2/2
  [375] =  4, -- 1/3
  [376] =  4, -- 2/3
  [377] =  4, -- 3/3
  [378] =  7, -- 1/1
  [379] =  4, -- 1/2
  [380] =  4, -- 2/2
  [445] =  0, -- 0/2
  [446] =  4, -- 1/2
  [447] =  8, -- 2/2
  [451] =  0, -- 0/1
  [452] =  8, -- 1/1
  [453] =  0, -- 0/2
  [454] =  4, -- 1/2
  [455] =  8, -- 2/2
  [456] =  0, -- 0/1
  [457] =  8, -- 1/1
  [458] =  0, -- 0/4
  [459] =  4, -- 1/4
  [460] =  8, -- 2/4
  [461] = 12, -- 3/4
  [462] = 16, -- 4/4
  [465] =  0, -- 0/2
  [466] =  4, -- 1/2
  [467] =  8, -- 2/2
  [468] =  0, -- 0/4
  [469] =  4, -- 1/4
  [470] =  8, -- 2/4
  [471] = 12, -- 3/4
  [472] = 16, -- 4/4
  [476] =  0, -- ?
  [479] =  0, -- ?
}

ravagernl · 05-29-13, 01:53 PM

Originally Posted by Mirroar

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:

local exp, mult = 1.00936754973658, 68.6945347210951
local spellpower = mult * (exp ^ iLvl)

The error should be pretty small (a max of 4 points of spellpower with the given values, so < 0.1%) and you have the added benefits of it working for item levels not in your table.

Maybe something was added/substracted to the base of the exponentiation or afterwards? Does blue ever respond to these type of questions?

[offtopic]Mirroar, when can we expect a TopFit update for 5.3 please

[/offtopic]

d07.RiV · 05-29-13, 02:01 PM

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.

scotepi · 09-16-13, 08:21 PM

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:

-- 5.4
    local levelAdjust={ -- 11th item:id field and level adjustment
        ["0"]=0,["1"]=8,["373"]=4,["374"]=8,["375"]=4,["376"]=4,
        ["377"]=4,["379"]=4,["380"]=4,["445"]=0,["446"]=4,["447"]=8,
        ["451"]=0,["452"]=8,["453"]=0,["454"]=4,["455"]=8,["456"]=0,
        ["457"]=8,["458"]=0,["459"]=4,["460"]=8,["461"]=12,["462"]=16,
        ["465"]=0,["466"]=4,["467"]=8,["469"]=4,["470"]=8,["471"]=12,
        ["472"]=16,["491"]=0,["492"]=4,["493"]=8,["494"]=4,["495"]=8,
        ["496"]=8,["497"]=12,["498"]=16,
    }

suicidalkatt · 09-17-13, 08:31 PM

I've been using LibItemUpgradeInfo-1.0 for my !SyLevel addon.

The libarary has also been updated for the changes in 5.4

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode