Quote:
Quote:
Quote:
Quote:
Quote:
|
Thanks for the detailed replies.
Quote:
|
Quote:
I just got back from out of town though, if no one has tested it yet I could whip something up to test it with. |
I just downloaded new copies of FCOItemSaver & Advanced filters. Whatever you guys did while I was gone seems to have made a huge improvement.
|
Quote:
Quote:
libFilters.lua : https://gist.github.com/merlight/e45...libfilters-lua This is based upon r10, without debugging stuff. I removed ENCHANTING2 because it overlaps with ENCHANTING (on EXTRACTION tab both would have to be called), instead there are LAF_ENCHANTING_CREATION and LAF_ENCHANTING_EXTRACTION. FCO Item Saver will probably want to register both. I also exposed RequestInventoryUpdate, an enhanced scheduleListUpdate which, when called with e.g. LAF_STORE and LAF_MAIL, will only cause one update (my original scheduleListUpdate would use different callbackNames and thus cause two updates). libFilters_tags.lua : https://gist.github.com/merlight/e45...lters_tags-lua This is the above + the change from filterId to filterTag. |
Okay, I used libFilters_tags as the base for r11. I added a function to get the LAF that was applied last (libFilters:GetCurrentLAF()) so an addon can apply its generic filters to whichever LAF is active. This is what I'm using in Advanced Filters to choose which LAF to register my inventory filters for.
Other uses such as Item Saver should work fine as normal just registering for the one or two LAFs they want. |
I was wondering what bloody editor adds a space at every empty line ... until I found out it's github :eek: Next time I link a gist, I should note to use "Raw" source ;)
|
Ok I was reluctant to inject LAF type into inventories/layoutData, I thought there might be a better solution. Saving currentLAF in runFilters looked good, unfortunatelly there's a problem with it.
I'm at Bank Deposit tab. When I put something in the bank, it triggers filtering of both the backpack and bank inventories (due to SLOT_UPDATE events I guess). Afterwards currentLAF == LAF_BANK, although I'm still at Deposit tab and subfilters stop working until I switch the top filter twice without touching any subfilter in-between. |
Injected filterType into inventories, added inventoryType argument to GetCurrentLAF : libFilters.lua / gist
Required change in AF: Lua Code:
edit: updated with LAF_IMPROVEMENT from below ;) edit2: oops, now really |
Quote:
Thx for the rework on libFilters again. I'll tets around with FCOItemSaver and the libfilters with filterTags. @Randactyl: Would it be possible to add the following LAF to libfilters too, to make it more "complete" for all the different panels? Lua Code:
This one would be used at crafting stations at the improvement tab. The tab already got registered standrd filters to only shown items you are able to improve at the current crafting station type and which are able to be improved yet. I think we cannot use it the same way with LAF_DECONSTRUCTION like LAF_ENCHANTING_CREATION and LAF_ENCHANTING_EXTRACTION are used (ENCHANTING.enchantingMode selects the index entry from array enchantingModeToFilterType to get the appropriate LAF for the filterType), because the active panel at SMITHING can only be distinguished by the panel names (deconstructionPanel, improvementPanel, refinePanel, researchPanel):IsHidden() function and not by help of a variable like smithingMode. Am I right? Based on merlight's libfilters with filter tags this should be the needed additions: Lua Code:
Btw: What is this function doing: HandleDirtyEvent() ? Found at SMITHING.deconstructionPanel.inventory |
Can't get to my computer for about an hour, but just for my understanding:
This new method would result in both LAF_(GUILD)BANK and LAF_BAGS being registered? Couldn't I just as easily in Advanced Filters check to see if the current LAF is one for the banks and also register for BAGS? Of course, this leads to currentLAF really being a misnomer since those situations have more than one currrently applied. Should be something more like lastLAF :cool::D edit: Ohh I see how it will work for Bank/Bag. Current inventory and therefor current LAF will change every time change filter runs (clicking one of the big default filters). Does it also trigger when switching between deposit/withdraw? Also, I'm not sure what GetCurrentInventoryType() will return for store, mail, trade, etc? I'm pretty sure it will be INVENTORY_BACKPACK and we wouldn't end up with the LAF_STORE etc. Lua Code:
|
Apparently I wrote that, but had to look it up nonetheless :D g_currentInventoryType is assigned in OnEffectivelyShown hooks on "inventory display controls", it can only be INVENTORY_BACKPACK, INVENTORY_BANK or INVENTORY_GUILD_BANK.
When you're at the bank, tabs switch between ZO_PlayerInventory (INVENTORY_BACKPACK) and ZO_PlayerBank (INVENTORY_BANK). PLAYER_INVENTORY.inventories[INVENTORY_BACKPACK].appliedLayout == BACKPACK_BANK_LAYOUT_FRAGMENT.layoutData the whole time, btw. When you withdraw/deposit an item, filters get run on both BACKPACK and BANK inventories, so it's not always true that the last filterType from runFilters is the filterType of the currently displayed inventory control. g_currentInventoryType matches the displayed control, and you can ask libFilters what's the current LAF for this inventoryType - for BANK and GUILD_BANK it's trivial, for BACKPACK the answer is in appliedLayout. |
Test time!
All done right after a /reloadui. Zgoo used to view data. Open relevant fragment, then choose one of the main filters. Results follow. Inventory: 1. /zgoo GetCurrentInventoryType() -> INVENTORY_BACKPACK 2. /zgoo PLAYER_INVENTORY.appliedLayout.libFilters_filterType -> LAF_BAGS 3. /zgoo PLAYER_INVENTORY.inventories[GetCurrentInventoryType()].libFilters_filterType -> LAF_BAGS Bank (withdraw): 1. INVENTORY_BANK 2. nil 3. LAF_BANK Guild Bank (withdraw): 1. INVENTORY_GUILD_BANK 2. nil 3. LAF_GUILDBANK Store, Deconstruction, Guild Store, Mail, Trade, Enchanting Creation/Extraction, Improvement: 1. INVENTORY_BACKPACK 2. nil 3. nil So there is an issue with the hooking function that is supposed to run on init? |
Quote:
I don't know what you were expecting from that test, but some things I learned may apply to your test on the backpack. I had originally wrote my library to hook into the: ZO_InventoryManager:ShouldAddSlotToList so that as items were added to the inventory lists I would run custom filters against it. It worked fine for the backpack, bank, & guild bank. Everything worked fine until I started final testing and realized the different layout views for the backpack: Mail, trade, store, exc.. had some problems. When trying to track it down I noticed that, for example, when the mail is opened for the first time the list is populated, and when it is closed ZO_InventoryManager:ShouldAddSlotToList would run again and repopulate the list of items reverting back to the default backpack view. After the mail had been opened 1 time, ZO_InventoryManager:ShouldAddSlotToList would NOT run again when the mail was opened, only when closed. Why would it not run every time the mail was opened, but only run on close?? My best guess seemed to be that the layoutData was applied when it was opened (on the already populated/current backpack list), but the list is only repopulated the first time a layout view is opened and when the layout view is closed (in order to revert back to the default backpack view). I could not figure out a way to fix it & had to scrap it in favor of using the additional filters in the layoutData for the different backpack layouts like is done in libfilters. I could find no other way of doing it other than using those layout additional filters for: backpack, trade, mail, trading house, & vendor. My point is, that if you were doing this: Lua Code:
As for the others (I don't know how you guys handled this in your code, but) Enchanting does not use the backpack. It uses: ZO_CraftingInventory, as do all of the other craft stations. In mine I wrote separate filters for each crafting station, research, & improvement. For the crafting stations (refine/deconstruction) I rewrote: ZO_CraftingInventory:EnumerateInventorySlotsAndAddToScrollData to add additional checks & run the custom registered filters as it was enumerating the crafting inventories. For deconstruction I used: ZO_SmithingResearchSelect:SetupDialog to hide things from the research dialog box. and for the improvement filter I used: ZO_SharedSmithingImprovement_CanItemBeImproved to run my registered filters to see if we should allow an item to be improved or not. If an addons registered filters say the item should be hidden I just returned that the item can not be improved. The only tough one seems to be hiding things from the provisioning stations since it seems all code only refers to recipes with recipeListIndex, recipeIndex. I found a way around it & I've got it working, I just need to do some final testing to double check everything. |
PLAYER_INVENTORY:UpdateList
I do have one question though. I glanced at some changes you guys made & I'm unclear on why libfilters is doing:
Lua Code:
Since libFilters is using the layoutData.additionalFilter, which runs when the layout is applied...the list gets Committed/automatically updated after the layout is applied, so why call UpdateList ever? |
@Randactyl
I'm running out of ideas. Tried to reproduce what BigM wrote about Sell in comments, but for me it works (now). It'll be some stupid obvious bug, obvious bugs are hard to find, they look like features :D Quote:
|
Quote:
Inventory: 1. GetCurrentInventoryType() -> INVENTORY_BACKPACK 2. PLAYER_INVENTORY.appliedLayout.libFilters_filterType -> LAF_BAGS 3. PLAYER_INVENTORY.inventories[GetCurrentInventoryType()].libFilters_filterType -> LAF_BAGS Bank (withdraw): 1. INVENTORY_BANK 2. nil (this was unexpected, I thought it would apply layout immediately when opening bank; however, while on withdraw tab, appliedLayout is irrelevant, since it only applies to backpack) 3. LAF_BANK Bank (deposit): 1. INVENTORY_BACKPACK 2. LAF_BAGS (now it's ok) 3. LAF_BAGS Guild Bank (withdraw): 1. INVENTORY_GUILD_BANK 2. nil 3. LAF_GUILDBANK Guild Bank (deposit): 1. INVENTORY_BACKPACK 2. LAF_BAGS 3. LAF_BAGS Store (buy, sell): 1. INVENTORY_BACKPACK 2. LAF_STORE 3. LAF_BAGS (this is ok, because LAF from appliedLayout takes precedence) Mail (send): 1. INVENTORY_BACKPACK 2. LAF_MAIL 3. LAF_BAGS (same as above) Quote:
The only issue I'm aware of now is that when I switch the top filter from e.g. Weapons to All and back to Weapons, subfilter dropdown doesn't appear. |
Quote:
Lua Code:
|
Ah, thanks for the function explanation. Really dirty :-)
Edit: I've found the error... as I thought it was a simple one, but hard to find. As libFilters was updated and LAF_ENCHANTING and LAF_ENCHANTING2 were removed and changed to new LAF_ENCHANTING_EXTRACTION and LAF_ENCHANTING_CREATION constants the constant's integer value changed too. Inside my addon I forgot to update them properly and my maximum value of available panels did not increase as LAF_IMPROVEMENT was added later. libFilters:UnregisterFilter() did silently fail then as the tag of the filter contains the panelId in FCOItemSaver... Error description (SOLVED!) I'm currently rewriting FCOItemSaver to speed up and use the new libFilters correctly. Changed: -Only the enabled filter settings (bags, bank, guild bank, vendor, etc.) will register according filters -The filters and buttons at the inventories will only be registered if the panel is shown, otherwise only LAF_BAGS is registered (if enabled) So at the start of the addon only the LAF_BAGS filter will registered -The filter buttons will be created/changed (OnClicked function, colors, etc.) as the panel is shown The inventory filter buttons will be used for all the panels where ZO_Inventory is used (banks disposal, mail, trade, guild store sell, vendor, inventory). This is done in function "CheckFilterButtonsAtCurrentPanel". -I'm choosing the current panel by help of events and PreHooking function "OnMouseUp" at the top menu buttons at some stations, or using the scene callback for the mail_send part (thx to merlight). It is working together with AdvancedFilters and seems to be ok so far. The only part not working is the LAF_IMPROVEMENT one :-( It must be some silly "feature" like merlight has written above :cool: LAF_IMPROVEMENT should be enabled as I click the improvement button at a crafting station (preHook OnMouseUp function at line 5638) or open up the crafting station (SMITHING is shown) and the improvement tab is already shown from the last usage of the improvement parts. The current panel will be selected in function "checkActivePanel". Error: If I click the improvement button it will start to repeat the called function "FCOItemSaver_PreHookButtonHandler()" every second again? This will go on until I click the deconstruction button (line 5631). If I do not /reloadui or click the deconstruction button the game client might crash after a while. I'm not able to see why this prehooked button is behaving that bad :-( All other buttons react as aspected and will only run the code inside once. I've even implemented a variable to prevent this repeating (preventerVars.gButtonChanging) but it is not working either. Inside the chat type "/fcois deepdebug" (and use an addon to see the "pre addon loading text" maybe) to enable the debug output. Here is the version causing this bug: https://dl.dropboxusercontent.com/u/...ENT_button.zip I'd be glad if someone could help me where this "repeating" button click error comes from. btw: I've not changed all the right click menu hook, self made pre hook functions, and that other stuff (debugMessage function etc.) circonian and merlight have pointed me to before. I focused on removing the unnecessary filters and buttons and inventory updates first. So please don#t review this code again :) |
Quote:
I'd rather divert you from the idea of hooking buttons' OnMouseUp completely. This is SMITHING:SetMode: Lua Code:
|
All times are GMT -6. The time now is 02:53 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI