Originally Posted by Randactyl
Edit: actually, it's really the "same inventory" in any of those contextual fragments just with special flavor like a label saying "Sell" instead of "Inventory" and the buttons to navigate through that fragment, right?
|
Exactly. It's always INVENTORY_FRAGMENT (top-level control ZO_PlayerInventory) with different layout fragment added to the scene. ingame/inventory/backpacklayouts.lua
Originally Posted by Randactyl
So then we would want to include all of the LAF_BAGS filters by default? (at least for Advanced Filters, anyway)
I'm trying to think of when I would want different filters in Sell vs. Mail vs. Inventory.
|
For example in an add-on named NeverSellRawMaterialsToNPC (but allow sending to friends). We don't have to come up with every possible usage, but if someone else comes with an idea and can use libFilters to implement it, that'd be great
Originally Posted by Randactyl
Option B could involve something like me choosing the correct LAF by hooking the display of a scene just like libFilters uses to determine which LAF to apply.
Option A sounds to be the easiest, but I have a gut feeling that is not the best thing to do.
|
Basically what I was thinking. B) looks like a bit more work for AF, but non-overlapping LAF filters might be worth it. libFilters could even tell you which LAF is active on INVENTORY_BACKPACK, it can save the value in layoutData when it hooks additionalFilter.
Originally Posted by Randactyl
I'm hesitant to dive into these changes because I'm trying to figure out which would be the best option performance wise since that is what all of this discussion was borne out of. I just don't know enough about performance impacts of the different options to make a call out of the gate.
|
Even without help from libFilters or trying to figure out which LAF is active, registering all LAF types every time would impose marginal overhead. Compared to the previous version, which caused several inventory refreshes per click and chained filters ad infinitum, we could perhaps do some Folding@Home during the time saved.
Originally Posted by Baertram
Avoid registering the filters twice by checking if the filter is already registered libfilters:IsFilterRegistered(filterId) in advance (btw: wouldn't this even make sense to be added inside the libfilters:registerFilter function by default?)
|
Agreed. I already wrote one modification inspired by event registration in the API, this would bring it further. RegisterForEvent fails silently if the event has already been registered, UnregisterForEvent fails silently if it hasn't been registered. Register/UnregisterFilter could work in the same way, only returning success/failure status.
Threaded Mode
