i think i've fixed the flashing progress bar issue.
i've added some recipe name filtering. currently it will strip off "enchant" from all the "enchant XXX" names cuz they're redundant and long and it replaced "Glyph of" with "Minor:" or "Major:" for all glyphs. the Major/Minor tags are also color coded (i might change the colors still)
i've also gotten added the ability to change the cost basis for recipes. normally, the cost is considered to be how much the materials in question would go for on the open market. this is the "resale" cost basis. it considers the vendor and auction house and selects the higher of the two.
you can now change the basis function to consider the purchase price for materials. this method will additional consider craftability of materials and select the lesser of the crafting cost, the vendor cost, or auction cost. there's also a toggle to only consider craftability of items LSW has identified you personally can make (so that it doesn't tell you to make bars if you're not a smith, for example -- not that you could scan bars since you can't link smithing, but you get the picture).
recipe cooldowns are not factored currently, which of course, needs to change.
finally, my disenchanting support allows me to spoof disenchanting as a recipe. this means that shards, dusts, essences and crystals are "craftable" by disenchanting any item you can craft. because these items generate extra "unwanted" items, those items are refunded as residual materials (they are valued based on the value pricing module as opposed to the cost module if you're curious).
the disenchanting has a built-in threshhold to not consider any result with less than a 10% chance. this prevents a recommendation based on a slim chance to land an item which would result in tens if not hundreds of runs of an item trying to collect enough shards or crystals.
i intend to add milling and prospect support soon.
oh, the cost basis menu is only semi-functional -- the checks aren't working for me and i haven't sorted it out completely. and the Skill Up option isn't implemented yet.
the alpha is in the projects pages here at wowace. i'm not going to tag it beta till it's further along. once it tag it, it'll syndicate over to curse and i'll probably upload it to wowi if it seems stable.
milling support has been added. uses very basic #'s for herbs -- 2.7 / 0.4 per mill for primary and secondary results. if that's not sufficient, let me know.
the options menus should also work better now. the skill up factor isn't currently implemented.
i'm noticing my milling and prospecting numbers aren't the same as other sources (namely informant). the prospecting numbers come from wowhead and my milling number come from... er... some site referenced in the milling page at wowwiki. is that the latest info? anybody know?
also, i need to come up with a good scheme to factor in residual pigment prices for milling. it seems that the pigments sell for a lot more than the herbs it takes to make them -- so much in fact that the left over pigments are often more lucrative than the ink used for the inscription... i'm not an inscriptionist, so i'm clueless on how realistic the prices are...
What prospecting numbers are you using? According to Wowhead, you should expect 0.243 blue gems per prospect, and 1.098 green gems per prospect of Saronite Ore. This can be found by summing up the number of total gems reported to be found, and dividing it by the number of reported prospects. (See: http://www.wowhead.com/?item=36912#prospecting)
for prospecting, i use the wowhead data for each item.
these numbers look accurate enough. i suppose i could combine them based on item type to increase the accuracy, but generally speaking they seem pretty consistent.
if you're interested you can find the tables in the prospecting_support.lua file. here is saronite's results:
enchantrix's numbers (which feed informant) seem to round a bit.
i get these numbers from the individual gem's pages and the "prospected-from" numbers. i think see the problem now. wowhead "prospected-from" numbers don't seem to include the number dropped. i'll have to rewrite the dataminer to grab the prospecting data from the ores instead.
i was thinking wowhead's numbers took into consideration that a single prospect could return multiple gems, oh well. i'm actually really curious about how their miner works, now. it's almost like they're considering every gem drop as a separate prospect, which would skew the numbers i think... hmm...
either way, clearly my numbers are wrong. well, that's why it's alpha!
I created a new tradeskill addon called Jobber and some are requesting compatibility with you addon. So, using your frame support system, I have created the needed code. It still needs some work and of course you would need adjust your toc if you choose to add support -
-- LSW Jobber Interface
do
local buttonNamePattern, buttonTextNamePattern = "JobberSkill(%d+)", "JobberSkill%d"
local function getWidth()
return JobberHF:GetWidth()
end
local function initButton(i)
local button = _G["JobberSkill"..i]
if (button and not button.LSW) then
button:SetScript("OnShow", function() LSW:SkillButtonShow(button) end)
button:SetScript("OnHide", function() LSW:SkillButtonHide(button) end)
LSW:CreateDynamicButtons(i, "JobberSkill"..i, JobberFrame)
button.LSWValue = _G["LSWTradeSkillValue"..i]
button.LSWCost =_G["LSWTradeSkillCost"..i]
button.LSWLevel = _G["LSWTradeSkillItemLevel"..i]
button.LSW = true
end
return button
end
local function updateWindow()
local num, button = 1
repeat
button = initButton(num)
if (button and button:IsShown()) then
if (button.isHeader) then
button.LSWValue:Hide()
button.LSWCost:Hide()
button.LSWLevel:Hide()
else
button.LSWValue:Show()
button.LSWCost:Show()
button.LSWLevel:Show()
end
end
num = num + 1
until (not button)
LSW:CreateTimer("updateJobber", 0.1, LSW.UpdateData)
end
local function Init()
hooksecurefunc(Jobber, "frameShow", updateWindow)
hooksecurefunc(Jobber, "frameUpdate", updateWindow)
LSW.RefreshWindow = updateWindow
LSW.GetSkillListWidth = getWidth
LSW.parentFrame = JobberListScrollFrame
LSW.buttonNamePattern = buttonNamePattern
LSW.buttonTextNamePattern = buttonTextNamePattern
end
function Test()
if Jobber then
return true
end
return false
end
LSW:RegisterFrameSupport("Jobber", Test, Init)
end
sure, i can do that no sweat. my goal is to actually have the system work where that code could be in lsw or in jobber. the only trick is getting the timing right -- you can't call the lsw functions before lsw is parsed but you also have to do it before lsw initializes. not sure if "loadswith" or optional dependencies might work favorably here. i guess till it's sorted out a bit more, the best plan of action is to just incorporate it into lsw.
if you have (or anybody else has) any thoughts on the issue, i'd love to hear em.
Well, my thought would be to go along the lines of ButtonFacade. Create a core library for the data and perhaps a GUI to provide changing how that data is displayed. Then any addon that wants to add support merely throws it's tradeskill button to LSW to be modified. All the support code would be in the tradeskill addon and you would not have to worry about any tradeskill addons themselves. What is nice about this system is if a tradeskill addon author does not want to provide support, a thrird party could make a plugin addon to throw the tradeskill addons buttons at LSW for modification.
Not sure if I explained that clearly :) However, I think if you look at ButtonFacade as a model, it should then become clear (I hope)
Well, my thought would be to go along the lines of ButtonFacade. Create a core library for the data and perhaps a GUI to provide changing how that data is displayed. Then any addon that wants to add support merely throws it's tradeskill button to LSW to be modified. All the support code would be in the tradeskill addon and you would not have to worry about any tradeskill addons themselves. What is nice about this system is if a tradeskill addon author does not want to provide support, a thrird party could make a plugin addon to throw the tradeskill addons buttons at LSW for modification.
Not sure if I explained that clearly :) However, I think if you look at ButtonFacade as a model, it should then become clear (I hope)
so when you say "throw the tradeskill buton to LSW to be modified" you mean in the init code, right? i noticed you stuffed the LSW buttons into your button frame. i like that approach cuz that might alleviate some GetName() calls in the show routine.
this originally spawned as an ATSW only mod and i was simply piggybacking onto the button:Show() event. as it's grown, its gotten really hairy which is why i'm rewriting it. i'm still untangling stuff that can be done in a more streamlined fashion. i'm not overly happy with some of the pattern matching stuff, so maybe a means of pre-manipulating the tradeskill button would be good. might be able to ditch the pattern string stuff.
i'd like to keep the system lenient enough to handle the various tradeskill mods out there without forcing authors to rework their code. generally speaking, i think i get more requests for supporting other mods that other mods get for supporting lsw. lsw is trying to be a glue app to stick ah data into tradeskill uis, so it needs to be really flexible. that's kind of the genesis of my "let the other mods load up, then get in there an tinker with their buttons" method of support.
case in point, ATSW sets the text of the button AFTER it calls the Show() which means my recipe name filtering scheme fails (the filter is called during the Show() function). this means i have to run an extra series of button shows in the update loop to get the filtering to work.
skillet has a built-in callback that fires after it's done setting the text so i don't need a secondary loop in the update call.
altho, i suppose now that i'm thinking of things a little clearer, i could ditch the Show() hook and simply do all the processing in a post-update hook...
Yes, that is what I mean, like the init code...and now that I think of it, just like you said, I could have done exactly what I was talking about and made a plugin instead of requesting on having my code included ;D
I am going to write support for LDW into Jobber via a plugin and see how it goes. I merely wrote the frame support as you had for ATSW and Skillet as I figured that is the way you wanted it to go :p
yeah, the big question is going to be timing. lsw uses addonloader to delay loading till after the player has entered the world. that might complicate things. lemme know how it works and if i need to alter how lsw loads.
also, i read something about sorting in jobber -- are there hooks available cuz sorting by cost is something people use a lot with lsw and skillet combined.
I got a plugin working no problem :) So, I suppose you can not add or remove the frame support code I gave you. I will have the plugin available in my next update. The only issue I am having is that the pricing does not update once the frame shows until I click on a tradeskill or scroll the frame. Trying to figure out if that is on my end or because this version is still in alpha :)
Now, as for the sorting, I can easily add in new sorting methods. And that would be my job anyhow :D I will just add the sort option along with the sorting code in the plugin. The question will be if the data is reachable from Jobber.
the skillet support module has some sorting stuff in there. basically i think the way skillet was set up is you could register a sorting comparison function by passing a name and function. the function would accept two skill indices to compare (and the tradeskill which may or may not be important). i tried to expose all the pricing info that is necessary but if there's more that's needed, i can add more hooks to the LSW table. check out the skillet support module -- it might look a little odd because there are actually two versions of skillet supported -- the trunk version and my clone version which do things slightly differently.
when you say the pricing does not update, you mean it doesn't draw or it draws but is 0's until you force an update?
i think i might refactor somethings along the lines of how you attached the dynamic buttons, so keep an eye on how things are changing.
also, you should probably add a check in there somewhere to make sure the right version is available. this is a complete rewrite, practically. the old lsw was a mess. something like:
if LSW and LSW.RegisterFrameSupport then
would be sufficient to avoid errors with people having the old version of lsw and trying to connect to jobber.
As long as I have access to the data, I should be able to get sorts for LSW working. I just have to make my sorting more modular as it is fairly hard-coded right now. I planned on adding new sort methods, but did not figure adding ones based on another addon's data.
when you say the pricing does not update, you mean it doesn't draw or it draws but is 0's until you force an update?
That would be correct. The progress bars moves along fine, but the data, even though it is there, does not update with pricing until I do something that causes an update in my frame.
also, you should probably add a check in there somewhere to make sure the right version is available. this is a complete rewrite, practically. the old lsw was a mess. something like:
Heh, I did that, though I pulled the Version number from the addon meta data.
That would be correct. The progress bars moves along fine, but the data, even though it is there, does not update with pricing until I do something that causes an update in my frame.
sounds like what's happening is that jobber induced redraws update more effectively than LSW induced redraws. the LSW.RefreshWindow function should be set to something that causes your window to redraw.
i suspect it might be an issue of Show() not firing for buttons that are already shown. that updateWindow function seems kind of peculiar to me. the hide()/show() stuff should be taken care of by the LSW show hook. you could probably replace that stuff with a loop that goes thru and calls the LSW:ShowSkillButton function for each of your buttons. that'd probably get things working.
...aCache\ItemDataCache_ByID_selltovendor_Functions.lua:28: attempt to index global 'ItemDataCacheLocal_ByID_selltovendor' (a nil value):
ItemDataCache-1.303\ItemDataCache_API_GetSellValue.lua:40: in function `GetSellValue'
...rkysWorkshop\pricingSupport\getSellValue_support.lua:13: in function `vendorCost':
LilSparkysWorkshop-1.00\lilsparkysworkshop.lua:738: in function <...ace\AddOns\LilSparkysWorkshop\lilsparkysworkshop.lua:732>
LilSparkysWorkshop-1.00\lilsparkysworkshop.lua:792: in function `AddRecipe'
...ilSparkysWorkshop\pricingSupport\milling_support.lua:214: in function <...ilSparkysWorkshop\pricingSupport\milling_support.lua:207>:
...ilSparkysWorkshop\pricingSupport\milling_support.lua:250: in function `Init':
LilSparkysWorkshop-1.00\lilsparkysworkshop.lua:1837: in function <...ace\AddOns\LilSparkysWorkshop\lilsparkysworkshop.lua:1833>
LilSparkysWorkshop-1.00\lilsparkysworkshop.lua:1851: in function <...ace\AddOns\LilSparkysWorkshop\lilsparkysworkshop.lua:1843>
LilSparkysWorkshop-1.00\lilsparkysworkshop.lua:1888: in function <...ace\AddOns\LilSparkysWorkshop\lilsparkysworkshop.lua:1885>
that strikes me as a problem with the ItemDataCache addon. LSW might be doing something wrong, but an un-inited global doesn't strike me as the kind of thing LSW could cause. since it's implementing the GetSellValue API, i think it should be pretty bullet-proof even if lsw did feed it something fishy.
i'll look into it on my end, but maybe you should notify the author of IDC as well.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
i think i've fixed the flashing progress bar issue.
i've added some recipe name filtering. currently it will strip off "enchant" from all the "enchant XXX" names cuz they're redundant and long and it replaced "Glyph of" with "Minor:" or "Major:" for all glyphs. the Major/Minor tags are also color coded (i might change the colors still)
i've also gotten added the ability to change the cost basis for recipes. normally, the cost is considered to be how much the materials in question would go for on the open market. this is the "resale" cost basis. it considers the vendor and auction house and selects the higher of the two.
you can now change the basis function to consider the purchase price for materials. this method will additional consider craftability of materials and select the lesser of the crafting cost, the vendor cost, or auction cost. there's also a toggle to only consider craftability of items LSW has identified you personally can make (so that it doesn't tell you to make bars if you're not a smith, for example -- not that you could scan bars since you can't link smithing, but you get the picture).
recipe cooldowns are not factored currently, which of course, needs to change.
finally, my disenchanting support allows me to spoof disenchanting as a recipe. this means that shards, dusts, essences and crystals are "craftable" by disenchanting any item you can craft. because these items generate extra "unwanted" items, those items are refunded as residual materials (they are valued based on the value pricing module as opposed to the cost module if you're curious).
the disenchanting has a built-in threshhold to not consider any result with less than a 10% chance. this prevents a recommendation based on a slim chance to land an item which would result in tens if not hundreds of runs of an item trying to collect enough shards or crystals.
i intend to add milling and prospect support soon.
oh, the cost basis menu is only semi-functional -- the checks aren't working for me and i haven't sorted it out completely. and the Skill Up option isn't implemented yet.
the options menus should also work better now. the skill up factor isn't currently implemented.
prospecting is next!
i'm noticing my milling and prospecting numbers aren't the same as other sources (namely informant). the prospecting numbers come from wowhead and my milling number come from... er... some site referenced in the milling page at wowwiki. is that the latest info? anybody know?
also, i need to come up with a good scheme to factor in residual pigment prices for milling. it seems that the pigments sell for a lot more than the herbs it takes to make them -- so much in fact that the left over pigments are often more lucrative than the ink used for the inscription... i'm not an inscriptionist, so i'm clueless on how realistic the prices are...
with the version you have up right now, I'm getting a null pointer with itemdatacache. I'll try to do an err capture later on.
these numbers look accurate enough. i suppose i could combine them based on item type to increase the accuracy, but generally speaking they seem pretty consistent.
if you're interested you can find the tables in the prospecting_support.lua file. here is saronite's results:
[36912] = { --Saronite Ore [36929] = 0.183, --Huge Citrine [36930] = 0.041, --Monarch Topaz [36923] = 0.182, --Chalcedony [36924] = 0.04, --Sky Sapphire [36917] = 0.181, --Bloodstone [36918] = 0.041, --Scarlet Ruby [36926] = 0.184, --Shadow Crystal [36927] = 0.039, --Twilight Opal [36920] = 0.182, --Sun Crystal [36932] = 0.184, --Dark Jade [36921] = 0.04, --Autumn\'s Glow [36933] = 0.04, --Forest Emerald },enchantrix's numbers (which feed informant) seem to round a bit.i get these numbers from the individual gem's pages and the "prospected-from" numbers. i think see the problem now. wowhead "prospected-from" numbers don't seem to include the number dropped. i'll have to rewrite the dataminer to grab the prospecting data from the ores instead.
i was thinking wowhead's numbers took into consideration that a single prospect could return multiple gems, oh well. i'm actually really curious about how their miner works, now. it's almost like they're considering every gem drop as a separate prospect, which would skew the numbers i think... hmm...
either way, clearly my numbers are wrong. well, that's why it's alpha!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI created a new tradeskill addon called Jobber and some are requesting compatibility with you addon. So, using your frame support system, I have created the needed code. It still needs some work and of course you would need adjust your toc if you choose to add support -
-- LSW Jobber Interface do local buttonNamePattern, buttonTextNamePattern = "JobberSkill(%d+)", "JobberSkill%d" local function getWidth() return JobberHF:GetWidth() end local function initButton(i) local button = _G["JobberSkill"..i] if (button and not button.LSW) then button:SetScript("OnShow", function() LSW:SkillButtonShow(button) end) button:SetScript("OnHide", function() LSW:SkillButtonHide(button) end) LSW:CreateDynamicButtons(i, "JobberSkill"..i, JobberFrame) button.LSWValue = _G["LSWTradeSkillValue"..i] button.LSWCost =_G["LSWTradeSkillCost"..i] button.LSWLevel = _G["LSWTradeSkillItemLevel"..i] button.LSW = true end return button end local function updateWindow() local num, button = 1 repeat button = initButton(num) if (button and button:IsShown()) then if (button.isHeader) then button.LSWValue:Hide() button.LSWCost:Hide() button.LSWLevel:Hide() else button.LSWValue:Show() button.LSWCost:Show() button.LSWLevel:Show() end end num = num + 1 until (not button) LSW:CreateTimer("updateJobber", 0.1, LSW.UpdateData) end local function Init() hooksecurefunc(Jobber, "frameShow", updateWindow) hooksecurefunc(Jobber, "frameUpdate", updateWindow) LSW.RefreshWindow = updateWindow LSW.GetSkillListWidth = getWidth LSW.parentFrame = JobberListScrollFrame LSW.buttonNamePattern = buttonNamePattern LSW.buttonTextNamePattern = buttonTextNamePattern end function Test() if Jobber then return true end return false end LSW:RegisterFrameSupport("Jobber", Test, Init) endif you have (or anybody else has) any thoughts on the issue, i'd love to hear em.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNot sure if I explained that clearly :) However, I think if you look at ButtonFacade as a model, it should then become clear (I hope)
so when you say "throw the tradeskill buton to LSW to be modified" you mean in the init code, right? i noticed you stuffed the LSW buttons into your button frame. i like that approach cuz that might alleviate some GetName() calls in the show routine.
this originally spawned as an ATSW only mod and i was simply piggybacking onto the button:Show() event. as it's grown, its gotten really hairy which is why i'm rewriting it. i'm still untangling stuff that can be done in a more streamlined fashion. i'm not overly happy with some of the pattern matching stuff, so maybe a means of pre-manipulating the tradeskill button would be good. might be able to ditch the pattern string stuff.
i'd like to keep the system lenient enough to handle the various tradeskill mods out there without forcing authors to rework their code. generally speaking, i think i get more requests for supporting other mods that other mods get for supporting lsw. lsw is trying to be a glue app to stick ah data into tradeskill uis, so it needs to be really flexible. that's kind of the genesis of my "let the other mods load up, then get in there an tinker with their buttons" method of support.
case in point, ATSW sets the text of the button AFTER it calls the Show() which means my recipe name filtering scheme fails (the filter is called during the Show() function). this means i have to run an extra series of button shows in the update loop to get the filtering to work.
skillet has a built-in callback that fires after it's done setting the text so i don't need a secondary loop in the update call.
altho, i suppose now that i'm thinking of things a little clearer, i could ditch the Show() hook and simply do all the processing in a post-update hook...
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI am going to write support for LDW into Jobber via a plugin and see how it goes. I merely wrote the frame support as you had for ATSW and Skillet as I figured that is the way you wanted it to go :p
also, i read something about sorting in jobber -- are there hooks available cuz sorting by cost is something people use a lot with lsw and skillet combined.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNow, as for the sorting, I can easily add in new sorting methods. And that would be my job anyhow :D I will just add the sort option along with the sorting code in the plugin. The question will be if the data is reachable from Jobber.
when you say the pricing does not update, you mean it doesn't draw or it draws but is 0's until you force an update?
i think i might refactor somethings along the lines of how you attached the dynamic buttons, so keep an eye on how things are changing.
also, you should probably add a check in there somewhere to make sure the right version is available. this is a complete rewrite, practically. the old lsw was a mess. something like:
if LSW and LSW.RegisterFrameSupport then
would be sufficient to avoid errors with people having the old version of lsw and trying to connect to jobber.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat would be correct. The progress bars moves along fine, but the data, even though it is there, does not update with pricing until I do something that causes an update in my frame.
Heh, I did that, though I pulled the Version number from the addon meta data.
sounds like what's happening is that jobber induced redraws update more effectively than LSW induced redraws. the LSW.RefreshWindow function should be set to something that causes your window to redraw.
i suspect it might be an issue of Show() not firing for buttons that are already shown. that updateWindow function seems kind of peculiar to me. the hide()/show() stuff should be taken care of by the LSW show hook. you could probably replace that stuff with a loop that goes thru and calls the LSW:ShowSkillButton function for each of your buttons. that'd probably get things working.
...aCache\ItemDataCache_ByID_selltovendor_Functions.lua:28: attempt to index global 'ItemDataCacheLocal_ByID_selltovendor' (a nil value):
ItemDataCache-1.303\ItemDataCache_API_GetSellValue.lua:40: in function `GetSellValue'
...rkysWorkshop\pricingSupport\getSellValue_support.lua:13: in function `vendorCost':
LilSparkysWorkshop-1.00\lilsparkysworkshop.lua:738: in function <...ace\AddOns\LilSparkysWorkshop\lilsparkysworkshop.lua:732>
LilSparkysWorkshop-1.00\lilsparkysworkshop.lua:792: in function `AddRecipe'
...ilSparkysWorkshop\pricingSupport\milling_support.lua:214: in function <...ilSparkysWorkshop\pricingSupport\milling_support.lua:207>:
...ilSparkysWorkshop\pricingSupport\milling_support.lua:250: in function `Init':
LilSparkysWorkshop-1.00\lilsparkysworkshop.lua:1837: in function <...ace\AddOns\LilSparkysWorkshop\lilsparkysworkshop.lua:1833>
LilSparkysWorkshop-1.00\lilsparkysworkshop.lua:1851: in function <...ace\AddOns\LilSparkysWorkshop\lilsparkysworkshop.lua:1843>
LilSparkysWorkshop-1.00\lilsparkysworkshop.lua:1888: in function <...ace\AddOns\LilSparkysWorkshop\lilsparkysworkshop.lua:1885>
---
i'll look into it on my end, but maybe you should notify the author of IDC as well.