Feature - Implemented Friendlier maximizer pricechecking

Quite often I use the maximizer, then say rude words when I realise I'd forgotten to set price back to "don't check" after a previous use. The list of potions is very large for quite a few modifiers, and it can take a good while to run through price checking every one of them.

There are two things I'd like to see to make maximizer behaviour friendlier with regard to price checking:

1) When aborting the maximization (e.g. by hammering the escape button and saying "NO NO NO NO") the price checks should also be aborted. Currently even if you abort the maximization and set price check to "don't check", every potion in the aborted maximize request is still price checked before the maximizer will do anything else.

2) Many user scripts that check item prices will only do so if the historical price is greater than N days old. This would be nice functionality for the maximizer.
 

Bale

Minion
1) When aborting the maximization (e.g. by hammering the escape button and saying "NO NO NO NO") the price checks should also be aborted. Currently even if you abort the maximization and set price check to "don't check", every potion in the aborted maximize request is still price checked before the maximizer will do anything else.

This.

Often I forget to uncheck that box and find myself having to sit through the price checks on my next maximization.
 

Darzil

Developer
2) Many user scripts that check item prices will only do so if the historical price is greater than N days old. This would be nice functionality for the maximizer.
It would. It currently looks up every price in the Mall if the item is less than twice your maximizer indicated max price.

I'm considering adding an "Exact" checkbox, defaulting to false.

When unticked, it'd use the same logic as Inventory Manager does when trying to work out if it's better to make or buy. If the price file has updated in the last 7 days, it'll use the price file price, otherwise it'll check the mall and use that price.

When ticked, it'd use the same logic it does now.

That way users can choose between speed and accuracy (defaulting to speed to save server hits).

Thoughts ?
 

fronobulax

Developer
Staff member
My experience has been that for planning purposes historical prices are fine. For execution, I generally don't care what the price is so long as I obtain what I asked for at the expected or lower price.
 

roippi

Developer
I think that interface is cluttered enough. My vote is to just make it use historical_price.
 

Theraze

Active member
Rather than add a check box, maybe give it a preference? Since the maximizer works using exact references, it usefully avoids the autoBuyPriceLimit. However, if you tell it to, it tells you how much that will cost. That makes it a great tool for knowing how much meat you're spending for that extra bump.

If we go to using the fuzzy decision logic, two things will likely happen:
1) The exactness will go away. It will probably be better, but it means you won't be able to trust it precisely, especially if one of the items planned for use by the maximizer was used to create one of the other items.
2) It will likely go to either using autoBuyPriceLimit or misusing irreplacable tokens to acquire items which you wanted to buy from the mall because that's how it said it was going to do it, but since the token is non-tradable it was picked first.
 

Darzil

Developer
I wouldn't be changing the logic of what it uses anyway, just how it determines the price. A preference may be the route I take to avoid further interface complexity. Personally I'd prefer a fast interface with (slightly) less accurate price.
 

Darzil

Developer
r15632 adds this. If maximizerCurrentMallPrices is set to true (default false) it'll always use mall searches, otherwise it'll use historical data from mall price database, unless that data is over 7 days old, in which case it uses a mall search.

Should be a bit less accurate, but much faster.
 
Top