Feature - Implemented always update historical price when possible

[roippi]

When I do ash mall_price($Item), the $Item's historical price gets updated. However, when I search for $Item on the purchases tab, historical price does not get updated (whether it's an exact item search or not). The same happens when doing a "price investigation" in Store Manager, though I'm 99% sure those two things call the same function.

I have not done much/any investigating on this, so I don't know if an update occurs when we incidentally look up prices when doing retrieve_item, etc.

 

[Bale]

Update does not occur during retrieve_item unless a purchase is made. Also price update occurs when purchasing from command line, but update does not occur when purchasing from purchase tab.

I don't recall the whole thread, but all these conditions were enacted on purpose (after much discussion) to prevent any conceivable abuse. It is suppose to be awkward.

 

[roippi]

While I'm probably not devious enough to come up with half of the possible abuses, I don't doubt they could exist.

I wonder, though, if there's not a more robust way to implement it so that all methods across the board get a shared once-per-session ability to update historical price. Something like a check to see if a hashset contains the item; if yes, do nothing; if no, add it to the hashset and update historical price appropriately.

Just spitballing.

 

[fronobulax]

I remember participating in the discussion although I don't recall the details. I do recall that the case for abuse was strong enough that I did not want to be the one who made the change. I seem to recall some confusion between offer price and an actual sale price and which is being used when. If I use the purchases tab and deliberately buy something at a price that is more than the lowest price what should happen? What if I purchase from an NPC that is not universally accessible?

 

[roippi]

I'd appreciate a link to that previous thread if anyone has it, either here or in PM if we're being all cloak-and-dagger about it.

If I use the purchases tab and deliberately buy something at a price that is more than the lowest price what should happen?

I imagine historical_price gets updated when you do the search (probably exact searches only), and nothing happens when you do the purchase.

What if I purchase from an NPC that is not universally accessible?

I.. don't know how NPCs interact with historical_price().

Anyway I'm perfectly willing to reject this, I'm just lacking familiarity with the reasons behind the limitations.

 

[Bale]

We're not trying to be cloak-and-dagger, it's just that the bug tracker in question no longer exists.

 

[fronobulax]

Wasn't trying to be cloak and dagger. I just could not find it and now Bale reminds me of why.

What does historical_price mean? If it means sold for that price then it should not be updated by a search, but only an actual purchase. If it means something was offered for that price at some point in the past then it should be updated to the "fifth price" whenever a search is done which suggests that for some instant of time historical_price and mall_price (as reported by mafia) will be identical because both were reset in response to the same search. If it means, or is supposed to mean something else then there is an opportunity for discussion.

mall_price is often interpreted to mean that I can get at least one of the item at the returned price so long as I am not subject to a purchase limit on the item. Since historical_price is often used as a stand in for mall_price that uses no server hits I think we can argue in favor of the first case - the offer price.

Without researching what is actually being done now, I'm inclined to propose that any time mall_price is updated then so is historical_price and it is updated to the same value, "the fifth". I am having a hard time figuring out how that could be abused to make a mall bot.

The reference to NPC stores was that if an item is in an NPC store that is available to the player and priced at a cost of less than 100 meat, recording the sale price as historical_price would be very misleading for players who did not have access to the store. Degrassi Knoll is one such example, I believe.

 

[Bale]

historical price simply means the last price that was returned by mall_price(). These prices (and the date/time it was retrieved) are stored in mallprices.txt in your /data folder just so that you can retrieve them with historical_price(). I think that is all it means and all anyone should expect it to mean. It should never be updated except when mall_price() is updated. You're overthinking that.

Without researching what is actually being done now, I'm inclined to propose that any time mall_price is updated then so is historical_price and it is updated to the same value,

That's how it works.

 

[roippi]

Didn't mean anything by the C+D quip, just a bit of levity.

Clarifying my request a bit. So here's what historical_price does:

    public static Value historical_price( Interpreter interpreter, final Value item )
    {
        return new Value( MallPriceDatabase.getPrice( (int) item.intValue() ) );
    }

Likewise, the "mallprice" column in the item manager displays that same value, MallPriceDatabase.getPrice().

If I go to the purchases tab and search for an item, the "mallprice" column will not update for that item. If I do mall_price(item), on the other hand, the "mallprice" column will update. I believe this is because mall_price() will call StoreManager.updateMallPrice (once per item per session), which will update the value in MallPriceDatabase as well as in the store manager. The purchases tab does not call updateMallPrice.

-------

Getting back to your question: what does historical_price mean? That's something I hadn't really considered. I had always thought of it as your second option: a historical snapshot of the (fifth) lowest price for the item in question.

Without researching what is actually being done now, I'm inclined to propose that any time mall_price is updated then so is historical_price and it is updated to the same value, if "the fifth". I am having a hard time figuring out how that could be abused to make a mall bot.

I would agree.

Though I'm not sure if a search on the purchases tab updates mall_price - if it doesn't, I think it should? For reference, mall_price is backed by an array in StoreManager, and historical_price is backed by an array in MallPriceDatabase.

Edit: Bale ninja. This was @ frono.

 

[Bale]

Though I'm not sure if a search on the purchases tab updates mall_price - if it doesn't, I think it should?

Purchases tab does not update mall_price. I cannot think of any reason why it does not, but perhaps someone will chime in with the answer.

 

[Veracity]

I can't think of any reason it does not other than omitting to code it.

 

[xKiv]

Purchases tab does not update mall_price. I cannot think of any reason why it does not, but perhaps someone will chime in with the answer.

Because then you could watch prices change without any risk/cost to yourself, which means mallbot.
ETA2: actually, no - searchmall doesn't do it for that reason, but purchase tab could (when manually clicked), so scratch that




Alsoanyway, I think the big things about historical_price() are
1) it survives from session to session without having to hit the servers (because it's stored in data/) and
2) it also updates from shared prices on kolmafia server

 

[Theraze]

Purchases tab is accurate though and gives you every price, including the cheapest. If you're using that manually, that's not a bot... as long as when it updates historical_price, it uses the 5th lowest, same as mall_price would give, that doesn't help botting, just more accurate prices for people using historical_price and sharing it... and decreases server hits, if you then run mall_price on something you've searched for already.

 

[Catch-22]

Not sure if it's a potential reason why prices aren't being updated on the purchase tab, but if you search for something like "a" and set limit to 1 it will do literally hundreds of searches.

If something like this were implemented, this technique could potentially be used as a way to mass update your mallprices relatively quickly (by hitting the KoL servers a lot). I don't think that should really be an encouraged behaviour.

 

[Veracity]

I mass update mall prices just before I spin a new release by executing thousands of requests and submit the updated mallprices.txt into the repository.

Whether we "encourage" it or not, what benefit is there for a user to "mass update" mall prices, rather than just the ones she is interested in? But if there is a benefit to do so, considering you can "mass update" mall prices using a one-line ASH script, why should we "discourage" it?

 

[Catch-22]

Leaks over a bit to the discussion here but isn't that potentially a form of a mall bot?

I guess the term mall bot can be pretty loosely applied, is the discouraged form of mall bot in KoLmafia simply the ones that are constantly searching for underpriced/mispriced items and buying them as soon as possible?

 

[roippi]

Not sure if it's a potential reason why prices aren't being updated on the purchase tab, but if you search for something like "a" and set limit to 1 it will do literally hundreds of searches.

If something like this were implemented, this technique could potentially be used as a way to mass update your mallprices relatively quickly (by hitting the KoL servers a lot). I don't think that should really be an encouraged behaviour.

Mafia knows the difference between an exact and inexact search already, so we can just update for exact searches like I mentioned before.

why should we "discourage" it?

You make a fair point, but part of me still wants to discourage that behavior whenever possible. Heck, if there were a way to discourage that one-liner in ASH, I'd be in favor of that, too.

 

[Theraze]

What... having slightly more updated prices, once per mafia session? Since I believe historical_price only updates once per execution, just like mall_price. Note:

> ash mall_price($item[gimlet])

Searching for "gimlet"...
Search complete.
Returned: 5650

> ash mall_price($item[gimlet])

Returned: 5650

> ash mall_price($item[gimlet])

Returned: 5650

See the single search for prices? Why hit KoL's servers again if someone runs mall_price or historical_price, if they hit a price check on purchases? If anything, it DISCOURAGES mall bots, since then their script will have more out of date information...

Basically, if we're going to hit KoL's servers, let's save the server hit later. Among other reasons because it encourages people to do more exact searches if they care that much about their prices being accurate.

 

[Fluxxdog]

historical_price() never updates. It only uses current information. mall_price() will only execute once per session.

 

[roippi]

historical_price() never updates.

Wrong.

It only uses current information.

What?