Re-Organize Auction House listings

[srmalloy]

The auction house lists enhancements running down from lowest level to highest level -- minimum level at the top and maximum level at the bottom -- but the recipes reverse this, with the highest-level recipes at the top and the lowest-level recipes at the bottom. Can this be made consistent, so that both enhancements and recipes are listed in the same order, so that those of us who, due to advancing age, sometimes have problems picking out the tiny number at the top of the enhancement symbol without leaning forward to peer at the screen don't have to scroll in different directions depending on where we're searching?

 

[MsSmart]

I would add to that that to always place attuned enhancements at the bottom of both enhancements and recipes. Sometimes they are in between the enhancement and recipes and others at the bottom, for one who purchases specifically attuned ones, would be easier if they were at the end 

[Rudra]

11 minutes ago, MsSmart said:

I would add to that that to always place attuned enhancements at the bottom of both enhancements and recipes. Sometimes they are in between the enhancement and recipes and others at the bottom, for one who purchases specifically attuned ones, would be easier if they were at the end 

Or just go to the attuned enhancements on the menu?

[mechahamham]

I really feel like the auction listing needs a major reorganization and optimization. The way it's currently done smells like the Paragon devs used an unordered 'select * from items where category = 'something'' when what they needed was to add on a series of parameterized clauses onto the query. 'order by parameter1, parameter2, etc...'

 

I'm not privy to the code, though.

 

If it were me, I'd also 'flatten' the tree-view listing a bit. Rather than have a tree for 'Enhancements', just bump the different enhancement types to the top level of the tree.

 

The most major change I'd make would be to acknowledge the fact that the consignment store buckets enhancements regardless of levels or attunement. Rather than a separate listing for each level of enhancement, have one listing per enhancer, and then have it select the player's level as the default to purchase, with an option to change the level or to purchase pre-attuned.

 

This is is some pretty serious SQL plumbing and UI work, though, and as we know, UI work is a LOT harder than it seems like. Additionally, unoptimized, uncached SQL can be a huge drain on computer resources and we know for a fact that this is something that HC can struggle with since they're using a hosting facility rather than the far more expensive option of maintaining their own servers.

[srmalloy]

21 hours ago, Rudra said:

Or just go to the attuned enhancements on the menu?

I think that they're referring to your putting, say, "Positron's Blast" into the search box and getting a disorganized return back. I think mechahamham has the right of it that the return from searches often feel like the only terms in the search are what you put in the search box and the level min/max choices -- which points up another quirk, in that attuned enhancements appear to have an internal level of 1, regardless of the level range of the set, so if you search for "Positron's Blast" with a level range of 35-40, you'll get the listings for level 35 through 40 crafted Positron's Blast enhancements and level 35 through 40 recipes for Positron's Blast enhancements, but not the attuned enhancements in the set, even though the level range you specified is within the set range, so the attuned IOs are valid for the query.

 

And I agree with you that the amount of query design necessary to make the more general queries present returns in a more 'rational' order will be significant. Speaking from experience -- I spent thirty years doing datamining from a medical information system, both in MUMPS and SQL Server -- what needs to be done first is to sit down and decide how the search returns should be presented, including ordering, and what changes need to be made to either the database or the queries to support this (i.e., making attuned enhancements show up within the level range of the set, rather than making you set the minimum level to 1 in order to show attuned enhancements in the return), and then go through and make the query changes, using a test database like one of the testing or internal testing servers so you can't accidentally corrupt the live database (even though you should only be making 'select' queries, so that shouldn't be possible, I've seen stupider things happen).

 

[mechahamham]

3 hours ago, srmalloy said:

MUMPS

 

The name alone gives me a cold chill. And sadly not the kind that gets you paid sick leave.

 

3 hours ago, srmalloy said:

using a test database like one of the testing or internal testing servers so you can't accidentally corrupt the live database (even though you should only be making 'select' queries, so that shouldn't be possible, I've seen stupider things happen).

 

There it is. There's the awful horror movie. Wow, I wish I could say I hadn't lived through that a few times.

[srmalloy]

1 hour ago, mechahamham said:

The name alone gives me a cold chill. And sadly not the kind that gets you paid sick leave.

It's a rather tortured acronym, coming from "Massachusetts General Hospital Utility Multi-Purpose System". The basic functionality had a medical information system written to use it as a database -- VA FileMan -- then the codebase was expanded further to become CHCS -- the 'Composite Health Care System' -- and used across the entire DoD healthcare system until it had a partially-separate GUI-based system -- AHLTA (Armed Forces Healthcare Longitudunal Technology Application) -- take over part of its functionality until both it and CHCS were replaced by a new medical-information system (MHS Genesis), with CHCS becoming a static archive until the legally-mandated live access period expired and the whole thing could be archived to Iron Mountain. 

 

MUMPS' claim to fame is that it handles sparse data better than any other language.  For example, in C, if you have an array with three indexes, each of which can range from 1 to 100, you need to allocate a million cells for the array to define it, even if you're only populating it with ten values. In MUMPS, you define the cells at those indexes, and you've allocated ten cells of storage. So you can store A(1,3), A(1032,42), A(13,999), and A(3,"ALPHA"), and have an array variable with four values populated, instead of the million-cell or more array C would require even if it could handle a string as an array index.