|
11/23/15, 09:03 PM | #1 |
|
extending AwesomeGuildStore
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: Lua Code:
|
11/23/15, 09:56 PM | #2 |
|
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: Lua Code:
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 |
11/24/15, 02:44 AM | #3 |
/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 Last edited by QuadroTony : 11/24/15 at 07:44 AM. |
|
QuadroTony |
View Public Profile |
Find More Posts by QuadroTony |
11/24/15, 07:11 AM | #4 |
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? Lua Code:
Lua Code:
|
|
11/24/15, 10:32 AM | #5 | ||
|
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.
I didn't notice the second wrapper. That one could be injected between sort and commit. |
||
ESOUI » Developer Discussions » General Authoring Discussion » extending AwesomeGuildStore |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
Switch to Linear Mode |
Hybrid Mode |
Switch to Threaded Mode |
|
|