Yeah, the problem is that a new button is being created an passed to the function in Skillet's ThirdPartyHooks each time the window is opened. I fired off a message to Ackis about this and am currently pondering how to deal with it in the Skillet code.
It's tricky because a new button *is* being added each time the window is opened, and the old one is still there (just hidden).
Simple enough. Just add documentation to ThirdPartyHooks saying that it needs to be unhidden once it has been created.. Should be able to call button:Show() right?
I'm sure someone has already suggested this, but would be great to see how many of the mats required to make something are available on ALTS. ATSW does this.
i could swear that skillet used to tell me how many items i could craft based on available craftable items. like if i had raw cloth enough to make 10 bolts and i was going to make something that took 2 bolts each, it'd tell me that i could make 5 based on my inventory. anyway, if it did, it doesn't seem to be working for me. if it didn't, it should. :)
I'm sure someone has already suggested this, but would be great to see how many of the mats required to make something are available on ALTS. ATSW does this.
Yup, I'm planning on focussing on inventory features for the next release, and that is at the top of the list.
i could swear that skillet used to tell me how many items i could craft based on available craftable items. like if i had raw cloth enough to make 10 bolts and i was going to make something that took 2 bolts each, it'd tell me that i could make 5 based on my inventory. anyway, if it did, it doesn't seem to be working for me. if it didn't, it should. :)
Nope, this has never been a feature of Skillet. However, it should not be too hard to write. I'll file a feature request for it and see about getting it in.
While having the alchemy window open and learning a few recipes
Date: 2007-10-26 17:19:26
ID: 51
Error occured in: Global
Count: 1
Message: ..\AddOns\Skillet\UI\Sorting.lua line 154:
invalid order function for sorting
Debug:
Ace2\AceEvent-2.0\AceEvent-2.0.lua:304: TriggerEvent()
Ace2\AceEvent-2.0\AceEvent-2.0.lua:962:
Ace2\AceEvent-2.0\AceEvent-2.0.lua:955
AddOns:
<snip>
This looks to be one of these "this can never happen" errors, but I'm looking into it now.
Also, tooltip scaling based on the UI options doesn't seem to be working (or do I need to reset the config for skillet first?)
The tooltip scaling is based on the global UI scale right now. When I put this in I debated on whether or not to use the global setting or Skillet's setting. I choose the global setting because I think haveing all tooltips in the game use the same scaling works a bit better.
Let me know what you think of that. I'm always looking for feedback on this kind of thing.
woot for the reversible sort! double woot for the saved-per-sort method sort-order! for the sort plug in api, would it be possible to define a default order? my sort routine for sorting by cost puts the cheapest first by default whereas the others all sort by most expensive/highest first. if i could tell skillet that, it would be great.
or, you could make the tooltip for the sort order toggle be "value neutral" and say something like "reverse the direction of the sort".
is there a way to get rid of the down arrow on the pulldown list of sorting methods?
woot for the reversible sort! double woot for the saved-per-sort method sort-order! for the sort plug in api, would it be possible to define a default order? my sort routine for sorting by cost puts the cheapest first by default whereas the others all sort by most expensive/highest first. if i could tell skillet that, it would be great.
is there a way to get rid of the down arrow on the pulldown list of sorting methods?
You mean the one in the combo box or the one for the sort order? For the combo box definitely not, for the sort order maybe. Why do you want to get rid of it?
By chance there are future plans on being able to viewing an Alt's professions and recipes?
Or perhaps, in the Skillet tooltip that displays what items are needed to make the items, the name of the alt that can make the ingredient could be displayed.
Say the current character is a tailor and wants to make a silk pack.
One of the ingredients is heavy leather. Somewhere in the heavy leather area, it would say an alt (who is a leatherworker) can make it. Of course, if the alt doesn't know the recipe, it won't appear. (Alt B has the recipe.)
And if tracking the inventory of an alt is possible, then if the alt can make the heavy leather based on items in bags/bank, the tooltip will note it otherwise. (Alt B has the recipe and can make it.)
By chance there are future plans on being able to viewing an Alt's professions and recipes?
Filed as http://jira.wowace.com/browse/SKL-36. I'm not sure when I could get to this as I suspect that the current design of Skillet might make this a bit tricky.
Or perhaps, in the Skillet tooltip that displays what items are needed to make the items, the name of the alt that can make the ingredient could be displayed.
Say the current character is a tailor and wants to make a silk pack.
One of the ingredients is heavy leather. Somewhere in the heavy leather area, it would say an alt (who is a leatherworker) can make it. Of course, if the alt doesn't know the recipe, it won't appear. (Alt B has the recipe.)
And if tracking the inventory of an alt is possible, then if the alt can make the heavy leather based on items in bags/bank, the tooltip will note it otherwise. (Alt B has the recipe and can make it.)
Filed as http://jira.wowace.com/browse/SKL-37. This one should be less of a problem and will probably make it into the next version within the next couple of weeks.
One feature missing in skillet that ATSW has is a button to Buy Reagents from a vendor when their trade window is open right on the craft pane. Right now, if i forgot to queue my items before i clicked the vendor, i have to close the vendor and re-open them to auto-buy reagents... or am i just not seeing the functionality?
-
Also, not sure what this bug is, but, occasionally the skillet window section where it lists recipes looks like it has a pretty dark transparency over everything but the first line, and i'm unable to click anything other than the first thing listed
It's prolly not Skillet's fault, OneBag misbehaves in a similar fashion, where my inventory is unclickable. Maybe the problem exists in a library that both use for rendering their frame?
I only use Ace Addons with the exception of Auctioneer and MetaHud...
If you need the extensive list, i can provide it
Filed as http://jira.wowace.com/browse/SKL-36. I'm not sure when I could get to this as I suspect that the current design of Skillet might make this a bit tricky.
No rush on this one, nogudnik, as I have an addon ProfessionsBook that currently does it. :)
Quote from nogudnik »
Filed as http://jira.wowace.com/browse/SKL-37. This one should be less of a problem and will probably make it into the next version within the next couple of weeks.
Excellent! This will help me a lot as somebody who practically has every major non-gathering profession spread out in all 10 characters. :)
While I practically know what professions each of my characters have, it is a little cumbersome to swap characters and find out that I can't make the ingredient or I don't have an reagents to make it.
Just food for thought, I think it would less frequent for an account to have 10 leatherworkers in the same server, BUT... people are crazy sometimes. ;)
You mean the one in the combo box or the one for the sort order? For the combo box definitely not, for the sort order maybe. Why do you want to get rid of it?
yeah, i meant for the combo box. it seems odd to have 2 arrows next to each other, but the placement of the sort order reverse makes perfect sense -- right next to the dropdown. maybe then it's a request for the author of the library than handles the combo box to have a way to disable the arrow.
yeah, i meant for the combo box. it seems odd to have 2 arrows next to each other, but the placement of the sort order reverse makes perfect sense -- right next to the dropdown. maybe then it's a request for the author of the library than handles the combo box to have a way to disable the arrow.
It's a Blizzard standard combobox, so I don't think they're going to change it :-)
it's not documented on wow wiki, but that tells the init routine to modify the dropdown to remove the arrow and the frame around the selection, plus change the dropdown menu borders to be rounded vs squared.
or you could do this: (which is copied from the blizzard dropdown init code)
function Skillet:SortDropdown_OnShow()
UIDropDownMenu_Initialize(SkilletSortDropdown, Skillet.SortDropdown_Initialize)
getglobal("SkilletSortDropdownButton"):SetPoint("RIGHT", "SkilletSortDropdownText", "RIGHT", 6, 0);
SkilletSortDropdown.displayMode = "MENU"; -- changes the pop-up borders to be rounded instead of squar
...
basically it makes the arrow invisible and spanning the entire area of the pulldown textbox so clicking on the text brings up the dropdown.
even if you don't drop the arrow, the rounded look on the dropdown looks nicer with the rest of the skillet framing.
oh, and on the subject of drop-downs. you should check for the longest sort label being registered and either grow the dropdown menu selector to fit, or come up with some kind of clipping routine. "LSW: Reagent Cost" is too long and steps on other elements in the frame.
it's not documented on wow wiki, but that tells the init routine to modify the dropdown to remove the arrow and the frame around the selection, plus change the dropdown menu borders to be rounded vs squared.
I tried it out and I really did not like the look of it. I think I'll be sticking with the standard combo box for now.
or you could do this: (which is copied from the blizzard dropdown init code)
-- trimmed --
basically it makes the arrow invisible and spanning the entire area of the pulldown textbox so clicking on the text brings up the dropdown.
even if you don't drop the arrow, the rounded look on the dropdown looks nicer with the rest of the skillet framing.
SkilletSortDropdown.displayMode = "MENU"; -- changes the pop-up borders to be rounded instead of squar
I do like the way the displayMode = "MENU" looks and have already checked that in. However, I don't think I'll be ditching the arrow on the combobox. I may, however, move the arrow indicating sort direction so that it is not right next to the combo box. That does look a bit odd.
oh, and on the subject of drop-downs. you should check for the longest sort label being registered and either grow the dropdown menu selector to fit, or come up with some kind of clipping routine. "LSW: Reagent Cost" is too long and steps on other elements in the frame.
Don't know what has changed to show these errors when doing a tradeskill scan , for a mod called GuildTradeskills.
2007/10/29 22:00:15-187-x2]: Skillet-1.10-53338\ThirdPartyHooks.lua:160: AckisRecipeListFrameScanButton:SetPoint(): AC_UseButton is dependent on this
<in C code>: in function `CastSpellByName'
GuildTradeSkill-table: 298D1E58\core.lua:890: in function `OpenProfession'
GuildTradeSkill-table: 298D1E58\core.lua:848: in function `StartScan'
GuildTradeSkill-table: 298D1E58\core.lua:784: in function `Scan'
GuildTradeSkill-table: 298D1E58\core.lua:726: in function `ResumeScan'
GuildTradeSkill-table: 298D1E58\core.lua:717: in function `ScanNextTradeSkill'
GuildTradeSkill-table: 298D1E58\core.lua:719: in function `ScanNextTradeSkill'
GuildTradeSkill-table: 298D1E58\core.lua:719: in function `ScanNextTradeSkill'
GuildTradeSkill-table: 298D1E58\core.lua:693: in function <Interface\AddOns\GuildTradeSkill\core.lua:692>
GuildTradeSkill-table: 298D1E58\core.lua:673: in function <Interface\AddOns\GuildTradeSkill\core.lua:671>
---
[2007/10/29 22:00:32-187-x1]: Skillet-1.10-53338\ThirdPartyHooks.lua:160: AckisRecipeListFrameScanButton:SetPoint(): AC_UseButton is dependent on this
<in C code>: in function `CastSpellByName'
GuildTradeSkill-table: 298D1E58\core.lua:890: in function `OpenProfession'
GuildTradeSkill-table: 298D1E58\core.lua:848: in function `StartScan'
GuildTradeSkill-table: 298D1E58\core.lua:784: in function `Scan'
GuildTradeSkill-table: 298D1E58\core.lua:726: in function `ResumeScan'
GuildTradeSkill-table: 298D1E58\core.lua:717: in function `ScanNextTradeSkill'
GuildTradeSkill-table: 298D1E58\core.lua:693: in function <Interface\AddOns\GuildTradeSkill\core.lua:692>
GuildTradeSkill-table: 298D1E58\core.lua:673: in function <Interface\AddOns\GuildTradeSkill\core.lua:671>
---
When I did a manual scan for Ackis...
[2007/10/29 22:04:32-187-x1]: Skillet-1.10-53338\ThirdPartyHooks.lua:160: AckisRecipeListFrameScanButton:SetPoint(): AC_UseButton is dependent on this
<in C code>: in function `CastSpellByName'
Interface\FrameXML\SecureTemplates.lua:276: in function `SecureActionButton_OnClick':
<string>:"*:OnClick":1: in function <[string "*:OnClick"]:1>
(tail call): ?:
<in C code>: in function `securecall'
Interface\FrameXML\SecureStateHeader.lua:998: in function <Interface\FrameXML\SecureStateHeader.lua:979>:
Don't know what has changed to show these errors when doing a tradeskill scan , for a mod called GuildTradeskills.
2007/10/29 22:00:15-187-x2]: Skillet-1.10-53338\ThirdPartyHooks.lua:160: AckisRecipeListFrameScanButton:SetPoint(): AC_UseButton is dependent on this
<in C code>: in function `CastSpellByName'
Wow, I don't even know that that error message *means* :(
I will look into it though, and see if it is something Skillet is doing.
The buttons added to the skillet frame by the function in ThirdPartyHooks, even though it checks if the button is the same, can somehow still be added in and the old button not created.. EG AckisRecipeList's Scan Recipes button. If I open the skillet window, then close it, then open the same one again, the button is spaced farther to the left, as if the original button was added to the frame still.
I knew my ears were ringing ;)
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Simple enough. Just add documentation to ThirdPartyHooks saying that it needs to be unhidden once it has been created.. Should be able to call button:Show() right?
Yup, I'm planning on focussing on inventory features for the next release, and that is at the top of the list.
Nope, this has never been a feature of Skillet. However, it should not be too hard to write. I'll file a feature request for it and see about getting it in.
Also, tooltip scaling based on the UI options doesn't seem to be working (or do I need to reset the config for skillet first?)
This looks to be one of these "this can never happen" errors, but I'm looking into it now.
The tooltip scaling is based on the global UI scale right now. When I put this in I debated on whether or not to use the global setting or Skillet's setting. I choose the global setting because I think haveing all tooltips in the game use the same scaling works a bit better.
Let me know what you think of that. I'm always looking for feedback on this kind of thing.
or, you could make the tooltip for the sort order toggle be "value neutral" and say something like "reverse the direction of the sort".
is there a way to get rid of the down arrow on the pulldown list of sorting methods?
Should not be too hard, logged as http://jira.wowace.com/browse/SKL-35
You mean the one in the combo box or the one for the sort order? For the combo box definitely not, for the sort order maybe. Why do you want to get rid of it?
Or perhaps, in the Skillet tooltip that displays what items are needed to make the items, the name of the alt that can make the ingredient could be displayed.
Say the current character is a tailor and wants to make a silk pack.
One of the ingredients is heavy leather. Somewhere in the heavy leather area, it would say an alt (who is a leatherworker) can make it. Of course, if the alt doesn't know the recipe, it won't appear. (Alt B has the recipe.)
And if tracking the inventory of an alt is possible, then if the alt can make the heavy leather based on items in bags/bank, the tooltip will note it otherwise. (Alt B has the recipe and can make it.)
Filed as http://jira.wowace.com/browse/SKL-36. I'm not sure when I could get to this as I suspect that the current design of Skillet might make this a bit tricky.
Filed as http://jira.wowace.com/browse/SKL-37. This one should be less of a problem and will probably make it into the next version within the next couple of weeks.
-
Also, not sure what this bug is, but, occasionally the skillet window section where it lists recipes looks like it has a pretty dark transparency over everything but the first line, and i'm unable to click anything other than the first thing listed
It's prolly not Skillet's fault, OneBag misbehaves in a similar fashion, where my inventory is unclickable. Maybe the problem exists in a library that both use for rendering their frame?
I only use Ace Addons with the exception of Auctioneer and MetaHud...
If you need the extensive list, i can provide it
No rush on this one, nogudnik, as I have an addon ProfessionsBook that currently does it. :)
Excellent! This will help me a lot as somebody who practically has every major non-gathering profession spread out in all 10 characters. :)
While I practically know what professions each of my characters have, it is a little cumbersome to swap characters and find out that I can't make the ingredient or I don't have an reagents to make it.
Just food for thought, I think it would less frequent for an account to have 10 leatherworkers in the same server, BUT... people are crazy sometimes. ;)
yeah, i meant for the combo box. it seems odd to have 2 arrows next to each other, but the placement of the sort order reverse makes perfect sense -- right next to the dropdown. maybe then it's a request for the author of the library than handles the combo box to have a way to disable the arrow.
It's a Blizzard standard combobox, so I don't think they're going to change it :-)
oh. haha. i thought you were using a library to handle all that stuff.
okay, take a look at adding the word "MENU" to your dropdown init function. like:
UIDropDownMenu_Initialize(SkilletSortDropdown, Skillet.SortDropdown_Initialize, "MENU")
it's not documented on wow wiki, but that tells the init routine to modify the dropdown to remove the arrow and the frame around the selection, plus change the dropdown menu borders to be rounded vs squared.
or you could do this: (which is copied from the blizzard dropdown init code)
function Skillet:SortDropdown_OnShow()
UIDropDownMenu_Initialize(SkilletSortDropdown, Skillet.SortDropdown_Initialize)
getglobal("SkilletSortDropdownButtonNormalTexture"):SetTexture("");
getglobal("SkilletSortDropdownButtonDisabledTexture"):SetTexture("");
getglobal("SkilletSortDropdownButtonPushedTexture"):SetTexture("");
getglobal("SkilletSortDropdownButtonHighlightTexture"):SetTexture("");
getglobal("SkilletSortDropdownButton"):ClearAllPoints();
getglobal("SkilletSortDropdownButton"):SetPoint("LEFT", "SkilletSortDropdownText", "LEFT", -9, 0);
getglobal("SkilletSortDropdownButton"):SetPoint("RIGHT", "SkilletSortDropdownText", "RIGHT", 6, 0);
SkilletSortDropdown.displayMode = "MENU"; -- changes the pop-up borders to be rounded instead of squar
...
basically it makes the arrow invisible and spanning the entire area of the pulldown textbox so clicking on the text brings up the dropdown.
even if you don't drop the arrow, the rounded look on the dropdown looks nicer with the rest of the skillet framing.
oh, and on the subject of drop-downs. you should check for the longest sort label being registered and either grow the dropdown menu selector to fit, or come up with some kind of clipping routine. "LSW: Reagent Cost" is too long and steps on other elements in the frame.
I tried it out and I really did not like the look of it. I think I'll be sticking with the standard combo box for now.
I do like the way the displayMode = "MENU" looks and have already checked that in. However, I don't think I'll be ditching the arrow on the combobox. I may, however, move the arrow indicating sort direction so that it is not right next to the combo box. That does look a bit odd.
Sure, that's a good idea.
2007/10/29 22:00:15-187-x2]: Skillet-1.10-53338\ThirdPartyHooks.lua:160: AckisRecipeListFrameScanButton:SetPoint(): AC_UseButton is dependent on this
<in C code>: in function `CastSpellByName'
GuildTradeSkill-table: 298D1E58\core.lua:890: in function `OpenProfession'
GuildTradeSkill-table: 298D1E58\core.lua:848: in function `StartScan'
GuildTradeSkill-table: 298D1E58\core.lua:784: in function `Scan'
GuildTradeSkill-table: 298D1E58\core.lua:726: in function `ResumeScan'
GuildTradeSkill-table: 298D1E58\core.lua:717: in function `ScanNextTradeSkill'
GuildTradeSkill-table: 298D1E58\core.lua:719: in function `ScanNextTradeSkill'
GuildTradeSkill-table: 298D1E58\core.lua:719: in function `ScanNextTradeSkill'
GuildTradeSkill-table: 298D1E58\core.lua:693: in function <Interface\AddOns\GuildTradeSkill\core.lua:692>
GuildTradeSkill-table: 298D1E58\core.lua:673: in function <Interface\AddOns\GuildTradeSkill\core.lua:671>
---
[2007/10/29 22:00:32-187-x1]: Skillet-1.10-53338\ThirdPartyHooks.lua:160: AckisRecipeListFrameScanButton:SetPoint(): AC_UseButton is dependent on this
<in C code>: in function `CastSpellByName'
GuildTradeSkill-table: 298D1E58\core.lua:890: in function `OpenProfession'
GuildTradeSkill-table: 298D1E58\core.lua:848: in function `StartScan'
GuildTradeSkill-table: 298D1E58\core.lua:784: in function `Scan'
GuildTradeSkill-table: 298D1E58\core.lua:726: in function `ResumeScan'
GuildTradeSkill-table: 298D1E58\core.lua:717: in function `ScanNextTradeSkill'
GuildTradeSkill-table: 298D1E58\core.lua:693: in function <Interface\AddOns\GuildTradeSkill\core.lua:692>
GuildTradeSkill-table: 298D1E58\core.lua:673: in function <Interface\AddOns\GuildTradeSkill\core.lua:671>
---
When I did a manual scan for Ackis...
[2007/10/29 22:04:32-187-x1]: Skillet-1.10-53338\ThirdPartyHooks.lua:160: AckisRecipeListFrameScanButton:SetPoint(): AC_UseButton is dependent on this
<in C code>: in function `CastSpellByName'
Interface\FrameXML\SecureTemplates.lua:276: in function `SecureActionButton_OnClick':
<string>:"*:OnClick":1: in function <[string "*:OnClick"]:1>
(tail call): ?:
<in C code>: in function `securecall'
Interface\FrameXML\SecureStateHeader.lua:998: in function <Interface\FrameXML\SecureStateHeader.lua:979>:
---
Wow, I don't even know that that error message *means* :(
I will look into it though, and see if it is something Skillet is doing.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI knew my ears were ringing ;)