As for the Auction Hall changes. We almost did change automatic searching on categories but we did not want to sacrifice current functionality to make a performance change. If the other way is more desired we can try that if needed as you have indicated that may be preferable for at least some portion of our players. I was personally split, I generally make my search criteria then click on a category.
Search criteria: the available "search criteria" changes depending on which category you pick.
Normal user expectation: for both a person who has never seen the Auction House system through to veteran players (due to the above point), is to click on a category and even sub-category to broadly locate what they are searching. This can be checked with usability testing.
Gateway: works as point 2. It is a more intuitive and pleasant experience than the in-game AH, even with the loss of the critical Sort function (which btw puts off many players using the Gateway AH at all and partially redirects traffic back to the slower in-game system).
Performance comparison: from a logical and practical perspective, there are massive performance gains that can be made by not having any searches made until as much search criteria is entered BEFORE a search is made. I assume you have access to the performance data from the Gateway to see an idea of the minimum performance gains achievable compared to in-game.
Scaling: the "current functionality" you describe does not scale and neither is anyone asking for it to be wholly removed, merely shifted. If someone wants to search an entire category or sub category effectively with just the piece of a name, they could still do it. Therefore, it is not loss to change the functionality for a significant performance and usability improvement.
The current (automatic) search functionality would work well enough when there were a small number of either total items or items per category and the items have very few attributes other than name. However, it is a performance and usability nightmare as more items, especially heavily attributed items, are added. It also disproportionately impacts categories with many sub-categories like the most common one, i.e. in "Equipment".
The changes proposed to limit the rate of searches acts as a double whammy on a system as currently designed. Not only are users forced to already do unnecessary searches on a slow system but on top of that you limit those searches further? What happens as performance degrades still further, say, from more items or, ironically, having an even more successful game, i.e. higher population of users? It is a path that does not scale.
With a system that had no automatic searching, rate limitations would have almost no impact on most user activities and only impact extremely heavy users (or bots?), hence benefiting the overall system, reducing costs without affecting users.
Of course, if rate limitations are only being used as a stop-gap to a redesign towards a better performing, more stable and more usable AH search system, then, so be it. Would be nice to hear if this is happening, if so...
The problem with that (Panderus reply) is that you must click on Category (and initiate the auto-search before clicking the subcategory. Seems like most of the time you'd want a subcategory
you should never search everything a category has to offer when you dont explicit hit the search button, since the result is pointless, but when you already have entered some search terms, than its ok
maybe a short delay to select a subcategory when available
I was personally split, I generally make my search criteria then click on a category.
The advanced equipment criteria can't be selected until after you have already selected the equipment tab. When selling, I can drag and drop the item to the search bar and then hit the equipment tab, resulting in only one search. If I'm looking to buy a specific item and know/enter enough of the name to avoid false positives, again only one search is initiated. However, if I'm shopping trying to find items of a certain level range or stats, I have to click on the equipment tab (one search) and then enter the rest of my criteria, then search again.
"We have always been at war with Dread Vault" ~ Little Brother
0
nwnghostMember, Moderators, Neverwinter Beta Users, Neverwinter Knight of the Feywild UsersPosts: 0Arc User
edited February 2014
.a2 seems to be on Owlbear now, any details on differences to .a0?
And now .a4 and server down
0
dardoveMember, Neverwinter Beta Users, Neverwinter Guardian Users, Neverwinter Knight of the Feywild UsersPosts: 0Arc User
edited February 2014
At the very least, the latest version fixes brutal enchantments so they now show their icon.
Also, I noticed that Rusted Iron lockboxes are gone from this build. They aren't in the bazaar and they aren't dropping from enemies.
0
tripsofthrymrMember, Neverwinter Moderator, NW M9 PlaytestPosts: 1,624Community Moderator
Actually... just not searching until someone clicks "search" should be a trivial change (without knowing the code, just based on my 3 decades of software development experience).
As for the Auction Hall changes. We almost did change automatic searching on categories but we did not want to sacrifice current functionality to make a performance change.
The current approach of performing a search as soon as a person clicks on a category, without any other filtering criteria entered, cannot possibly be useful to anyone. There are way too many items in a category (or even a subcategory) for the result to be useful.
I would propose that part of the current functionality creates enormous strain on the system (mostly-unfiltered search) for near zero benefit.
I 100% agree with the proposed Auction House search tool edit! I want to put in all my search criteria before looking something up...So sick of hitting "Equipment" and waiting for a slow load of stuff I'm not looking for so I can narrow my search.
Autosearch when selecting a category should be turned off immediatelly (a feature like that should have never been implemented). It leads to up to 3 times more searches than needed, and usually the first two are thrown away without ever being useful.
I'd even suggest adding more filters for less network traffic (since rubberbanding and lag seem to be an issue these days). Price per unit would be the most useful. I don't really care if there are 400+ overpriced items, i might only be interested in those with buyout < X, since i'm not willing to pay more than X anyway. That would avoid fetching 400+ items each time.
I'd even suggest adding more filters for less network traffic (since rubberbanding and lag seem to be an issue these days). Price per unit would be the most useful. I don't really care if there are 400+ overpriced items, i might only be interested in those with buyout < X, since i'm not willing to pay more than X anyway. That would avoid fetching 400+ items each time.
YES!!!
And set a Maximum High Bid to my Total AD since I can't possibly buy/bid higher than that anyway!
...and of course filterable by High Bid, Buyout AND AD/Unit!
I realize this suggestion would require actual programming (O.o), but any time an ah search returns less than the max (400) item returns, I think you could save server quarries and server compute time by simply compressing the results into a flat file, then send said flat file on the intranet to a push server, and have that push server dedicated to streaming the file to a client, after which, all resorting and category searches could be done client side, which seems to be the majority AH quarries, as far as I can tell.
If bandwidth is a concern, a dedicated push server could even run a quick single pass text compression on the flat file, which, given the nature of searches having highly repeated content, would compress quite well.
Not having your data on search quarries, I can't run the math to see if this would be cost effective, given data points such as the number of in-search category resorts, whether the lag on the server is compute lag or bandwidth lag, and the type of researches that don't require a re-compute.
Other possibilities would include a more optimized database of items. From my current experience interacting with the AH it seems the database is split into categories, and given my experience with the necessities of deadline programming, I doubt the database file is filtered much beyond that.
Given that assumption, each search is likely comparing the search string to each database item and then returning all results to a sort function. However, given the nature of the AH only accepting items _your team_ has created, you have the advantage of knowing the name of every possible item to search for. Thus, if you compared the search string only once to each possible name match, and then maintained a separate hash table for the various sortable categories of sales of any item name, that said hash table could be updated in real time as sales and postings are made of any item.
The beauty of that solution is that category resorts are effectively done at post time, rather than search time. Via the binary expansion of hash tables you come to the same result, but pre-sorted. Even with the most basic hashing algorithms that would result in multiple sale results per hash, necessary at-search sorting would likely be kept to 4 or less passes. And off the top of my head I can think of some algorithms that would minimize that greatly.
End result being your category resort results become much closer to a binary search tree than a brute force, overly resource intensive, string compare.
Comments
The current (automatic) search functionality would work well enough when there were a small number of either total items or items per category and the items have very few attributes other than name. However, it is a performance and usability nightmare as more items, especially heavily attributed items, are added. It also disproportionately impacts categories with many sub-categories like the most common one, i.e. in "Equipment".
The changes proposed to limit the rate of searches acts as a double whammy on a system as currently designed. Not only are users forced to already do unnecessary searches on a slow system but on top of that you limit those searches further? What happens as performance degrades still further, say, from more items or, ironically, having an even more successful game, i.e. higher population of users? It is a path that does not scale.
With a system that had no automatic searching, rate limitations would have almost no impact on most user activities and only impact extremely heavy users (or bots?), hence benefiting the overall system, reducing costs without affecting users.
Of course, if rate limitations are only being used as a stop-gap to a redesign towards a better performing, more stable and more usable AH search system, then, so be it. Would be nice to hear if this is happening, if so...
Encounter Matrix | Advanced Foundry Topics
maybe a short delay to select a subcategory when available
And now .a4 and server down
Also, I noticed that Rusted Iron lockboxes are gone from this build. They aren't in the bazaar and they aren't dropping from enemies.
Actually... just not searching until someone clicks "search" should be a trivial change (without knowing the code, just based on my 3 decades of software development experience).
Sci-fi author: The Gods We Make, The Gods We Seek, and Ji-min
The current approach of performing a search as soon as a person clicks on a category, without any other filtering criteria entered, cannot possibly be useful to anyone. There are way too many items in a category (or even a subcategory) for the result to be useful.
I would propose that part of the current functionality creates enormous strain on the system (mostly-unfiltered search) for near zero benefit.
Sci-fi author: The Gods We Make, The Gods We Seek, and Ji-min
I'd even suggest adding more filters for less network traffic (since rubberbanding and lag seem to be an issue these days). Price per unit would be the most useful. I don't really care if there are 400+ overpriced items, i might only be interested in those with buyout < X, since i'm not willing to pay more than X anyway. That would avoid fetching 400+ items each time.
YES!!!
And set a Maximum High Bid to my Total AD since I can't possibly buy/bid higher than that anyway!
...and of course filterable by High Bid, Buyout AND AD/Unit!
Encounter Matrix | Advanced Foundry Topics
If bandwidth is a concern, a dedicated push server could even run a quick single pass text compression on the flat file, which, given the nature of searches having highly repeated content, would compress quite well.
Not having your data on search quarries, I can't run the math to see if this would be cost effective, given data points such as the number of in-search category resorts, whether the lag on the server is compute lag or bandwidth lag, and the type of researches that don't require a re-compute.
Other possibilities would include a more optimized database of items. From my current experience interacting with the AH it seems the database is split into categories, and given my experience with the necessities of deadline programming, I doubt the database file is filtered much beyond that.
Given that assumption, each search is likely comparing the search string to each database item and then returning all results to a sort function. However, given the nature of the AH only accepting items _your team_ has created, you have the advantage of knowing the name of every possible item to search for. Thus, if you compared the search string only once to each possible name match, and then maintained a separate hash table for the various sortable categories of sales of any item name, that said hash table could be updated in real time as sales and postings are made of any item.
The beauty of that solution is that category resorts are effectively done at post time, rather than search time. Via the binary expansion of hash tables you come to the same result, but pre-sorted. Even with the most basic hashing algorithms that would result in multiple sale results per hash, necessary at-search sorting would likely be kept to 4 or less passes. And off the top of my head I can think of some algorithms that would minimize that greatly.
End result being your category resort results become much closer to a binary search tree than a brute force, overly resource intensive, string compare.
-2 cents.