extending AwesomeGuildStore

[merlight]

This is primarily aimed at @sirinsidiator, I just wouldn't want to lose out on ideas others might suggest. Here are the two things I'm trying to do with AGS:
1) decile filter: cuts off results more expensive than N tenths of results on the current page (per item name); with N=5 the cut point is the median, so only the cheaper half of results will be shown.
2) sort results by name, then unit price -- will describe in another post

The decile filter needs to have all results before it starts filtering, so I gather them in f:BeforeRebuildSearchResultsPage, build a table of what should be kept, and f:FilterPageResult simply consults that table. It works well, but I'm still not completely comfortable with the fact that GetTradingHouseSearchResultItemInfo is called twice for each result -- first in my "Before" hook and then during the actual filtering. So I started thinking...

What if AGS' RebuildSearchResultsPage did:
- gather all ZO_TradingHouse_CreateItemData(i, GetTradingHouseSearchResultItemInfo) in a table
- pass that table to filters' PreprocessSearchResultsPage method -- this should not remove anything from the table
- replace ZO_TradingHouse_CreateItemData with a function that runs filters' FilterPageResultData and returns either data or nil

I'd like to know what you think because it has 2 quite big drawbacks so I'm not comfortable with that either:
- creating item data for all results; currently no table is created for results that are filtered out
- some ugly compatibility code:

function FilterBase:FilterPageResultData(data)
    -- delegate to older method
    return self:FilterPageResult(data.slotIndex, data.icon, data.name, data.quality, data.stackCount, data.sellerName, data.timeRemaining, data.purchasePrice, data.currencyType)
end

[merlight]

2) sort results by name, then unit price

Sorting should probably happen before this point. AfterRebuildSearchResultsPage comes later, so would require another commit.

You can do that by temporarily replacing ZO_ScrollList_Commit. I have another suggestion, a bit hackier but one that avoids swapping global functions -- instead replacing the environment of the original method:

local clsRebuildSearchResultsPage = getmetatable(TRADING_HOUSE).RebuildSearchResultsPage
local orgENV = getfenv(clsRebuildSearchResultsPage) -- this will be _G until more add-ons abuse it
local newENV = setmetatable({}, {__index = orgENV})
 
setfenv(clsRebuildSearchResultsPage, newENV)
 
-- copy to avoid double lookups
newENV.ZO_ScrollList_CreateDataEntry = orgENV.ZO_ScrollList_CreateDataEntry
newENV.ZO_TradingHouse_CreateItemData = orgENV.ZO_TradingHouse_CreateItemData
 
function newENV.ZO_ScrollList_ResetToTop(list)
    orgENV.ZO_ScrollList_ResetToTop(list)
    -- BeforeRebuildSearchResultsPage
end
 
function newENV.GetTradingHouseSearchResultItemInfo(...)
    -- FakeGetTradingHouseSearchResultItemInfo
end
 
function newENV.ZO_ScrollList_Commit(list)
    -- AfterRebuildSearchResultsPage (+ sort)
    orgENV.ZO_ScrollList_Commit(list)
end

Now I realized I could do the decile filter after all other filters, before sorting -- in AfterRebuildSearchResultsPage, but preferably before list commit. That might actually make more sense.... but it's too late. I should read this tomorrow and see if it still sounds like a good idea

[QuadroTony]

/offtopic
btw for experienced traders only one sort order important - by time from new to old
this way also you can buy cheapest items because usually new items has lowest price than old items

[sirinsidiator]

1) Decile filter sounds really cool, but I don't really know what I would do with one. There is already a price filter, unit price filter and MM's deal filter which all reduce the amount of items to only show the best bargains. Don't let that stop you from making one, but there is usually not much left to filter once these 3 are applied with the correct settings.

I think the additional calls to GetTradingHouseSearchResultItemInfo are the lesser of two evils. If it is called 200 times instead of 100 times should not really make a difference overall. Changing the behavior of CreateItemData just makes the code more complicated and does not have any real benefit IMO.

2) Your hack looks really hackish. I guess it would need much more comments in order to make clear what it does.
Maybe just use function swapping instead.

One major problem with changing the local sort order is that the API uses the item index for purchasing, so we need to keep that information intact.
I would just do everything related to sorting in a swapped out ZO_ScrollList_Commit and leave the other methods alone.
The searchtab wrapper is already wrapping around that method twice and calls ZO_ScrollList_Commit a second time, so that should also be combine into one call with some added hook points.
And last but not least there was also the feature request from Tony to prevent the scroll list from resetting to top in some cases which would also go in there. (I haven't forgotten about that )

Quite a few things that will go in there.

Maybe ZOS can add a few hook points to make it a bit easier?

function ZO_TradingHouse_CreateItemData(index, fn, filter)
    local icon, name, quality, stackCount, sellerName, timeRemaining, purchasePrice, currencyType = fn(index)
    if(name ~= "" and stackCount > 0) then
      if(type(filter) == "function" and filter(icon, name, quality, stackCount, sellerName, timeRemaining, purchasePrice, currencyType)) then
        local result =
        {
            slotIndex = index,
            icon = icon,
            name = name,
            quality = quality,
            stackCount = stackCount,
            sellerName = sellerName,
            timeRemaining = timeRemaining,
            purchasePrice = purchasePrice,
            currencyType = currencyType or CURT_MONEY
        }
 
        return result
      else
        return true -- to indicate that it exists but was filtered
      end
    end
end

function ZO_TradingHouseManager:RebuildSearchResultsPage(preventResetToTop)
    local list = self.m_searchResultsList
    local scrollData = ZO_ScrollList_GetDataList(list)
    ZO_ScrollList_Clear(list)
    if(not preventResetToTop) then ZO_ScrollList_ResetToTop(list) end
 
    self:BeforeFilterSearchResultsPage()
    local hiddenNumItems = 0
    for i = 1, self.m_numItemsOnPage do
        local result = ZO_TradingHouse_CreateItemData(i, GetTradingHouseSearchResultItemInfo, self.SearchResultFilterFunction) -- The default SearchResultFilterFunction just returns true and can be prehooked or wrapped by addons
        if(result == true) then hiddenNumItems = hiddenNumItems + 1
        elseif(result) then
            scrollData[#scrollData + 1] = ZO_ScrollList_CreateDataEntry(SEARCH_RESULTS_DATA_TYPE, result)
        end
    end
 
    local numItems = #scrollData
    local totalNumItems = hiddenNumItems + numItems
    self:AfterFilterSearchResultsPage(totalNumItems, numItems)
    self:UpdateItemsLabels(totalNumItems, numItems)
 
    -- If no results were returned, disallow further searches (until one or more search criteria are modified),
    -- and display a "no items found" label.
    self.m_searchAllowed = (totalNumItems ~= 0)
    self.m_noItemsLabel:SetHidden(totalNumItems ~= 0)
 
    self:SortSearchResultsPage(scrollData)
    ZO_ScrollList_Commit(list)
end
 
function ZO_TradingHouseManager:OnPurchaseSuccess()
    self:RebuildSearchResultsPage(true)
end

[merlight]

Originally Posted by sirinsidiator 1) Decile filter sounds really cool, but I don't really know what I would do with one. There is already a price filter, unit price filter and MM's deal filter which all reduce the amount of items to only show the best bargains. Don't let that stop you from making one, but there is usually not much left to filter once these 3 are applied with the correct settings.

It spawned from my usage of guild stores. I don't use MM, it's pointless without a high frequency trading guild, and even if I had one, I'd be reluctant to use MM because then it'd be a hog.

For instance, I'm buying Shadowhide and Void Cloth for writs; for me cheap Shadowhide is ~4g, Void Cloth ~5g. Stack price filter helps, I set max 1000g. Unit price doesn't help much, since there are stores with dozens of Shadowhide stacks @4.5g. I'd need separate presets with name filter. Actually when I first messaged you about it, I was writing a different thing -- adding context menu entry for marking an item overpriced (by itemId) and then filtering those out. But that would basically require building a database of fair prices by hand, so I scratched that. Plus it wouldn't help at all with the case when I mark Shadowhide overpriced @4.5g and then visit a store with 40 stacks of Shadowhide for 4.4g.

I don't want to have separate presets for Shadowhide, Void Cloth, Elegant Lining, Dreugh Wax, raw mats etc...
Some stores have only a few stacks of nothing interesting, I don't want to go through 5 presets to find that out.

Now I come to a store searching for Clothing mats, set stack price filter max to 2000g, decile filter to 1st (1/10) ... and if there are 50 full stacks of shadowhide on the page, I only see 5 no matter what their price is; so I don't have to scroll as much to find some Void Cloth. And I also get to see cheap raw mats if there are any under 10g.

Originally Posted by sirinsidiator One major problem with changing the local sort order is that the API uses the item index for purchasing, so we need to keep that information intact. I would just do everything related to sorting in a swapped out ZO_ScrollList_Commit and leave the other methods alone. The searchtab wrapper is already wrapping around that method twice and calls ZO_ScrollList_Commit a second time, so that should also be combine into one call with some added hook points. And last but not least there was also the feature request from Tony to prevent the scroll list from resetting to top in some cases which would also go in there. (I haven't forgotten about that )

There's "slotIndex" in the data, the order in list is irrelevant (proof is the added "go to previous page" row).

I didn't notice the second wrapper. That one could be injected between sort and commit.