Feature Quantity to mall_price()

Catch-22

Active member
I noticed a few of the potential problems being faced in the EatDrink thread and thought it might be worth requesting a quantity option to the mall_price function.

This would work like mall_price(item, int) and return how much it would cost the player to buy int quantity of item. This is because you can't always be sure that any given number of items will be available in the mall at the same price (in case there's 1 left at a good price, for example). There should probably also be a maximum placed on the quantity you can get the total price for (5, 10?) to curtail potential abuse scenarios

I know this requires a bit of changing to the way mall prices are currently being fetched/returned and I don't know if there's enough interest behind it. Those who might find this useful may be happy enough to work around the way things are currently done, so feel free to discuss.
 

lostcalpolydude

Developer
Staff member
There should probably also be a maximum placed on the quantity you can get the total price for (5, 10?) to curtail potential abuse scenarios

There needs to be a minimum (probably 5) to prevent people from looking for a single underpriced item. What abuse does a maximum prevent?
 

Catch-22

Active member
There needs to be a minimum (probably 5) to prevent people from looking for a single underpriced item. What abuse does a maximum prevent?

Single would be the same as the current way mall_price works. I'm not suggesting we change that, because I think it's needed. So if it were mall_price(item, 5) it would skip the first 4 cheapest (as is the current behaviour) and return the sum of the 5th-9th cheapest available price (which could all be from the same store).

The reason I'd say you should cap it at some sort of maximum is so people don't use it as a tool to monitor market fluctuations (I assume that would come under the same umbrella as a mall bot?). It's not really something to use for that, it should be used for reliable prediction of the total cost of your grocery bill, effectively.
 
Last edited:

xKiv

Active member
1) making the maximum too low can make this useless (sometimes you need to buy hundreds or thousands of something, even if it is just to create one unit of another item)
2) mall_price(item, N) - mal_price(item, N-1) == exact price of Nth (or (N+5)-th) unit of the item, which I think we are not supposed to be able to get in ASH?
 

Theraze

Active member
1) I'd say that 1-5 should return the same as current mall_price. Don't obfuscate your answer more than it has to be.
2) I'd say that if we actually do this, it should be able to go up to at least 100, so that buffbots purchasing palm fronds, for example, don't bankrupt the player by buying palm fronds at 9 million apiece. Imagine that would be useful for Bale's UR. In terms of ED, going past 35 is useless. 40 if you consider game grid tokens and a steel spleen.
 

xKiv

Active member
In terms of ED, going past 35 is useless.

What if somebody has a very tempting sale on fudgecules (and everything else somehow becomes more expensive than fudge-bunnies-on-sale)?
Except there won't be enough fudgecules at the tempting price to make even one.
(that's 1000; lunar isotopes to moon pies is only 100, but is more likely to realistically be optimal for some nonastronomical VoA)
 

heeheehee

Developer
Staff member
What about spleen filled with epic wads? You can get that up to 53, which players who want to pull off stunts might want (e.g. solo overcoat run) -- 20 from spleen of steel, 15 from extra-greasy sliders, 15 from pickle juice, 3x mojo filters, melange so you can still adventure. You just need a vOA of ~118k!

To be fair, what Mafia _could_ provide that would be fairly useful is the cost of acquiring an item, which it already computes internally for use in retrieve_item and whatnot. Bonus points if it separates adventure cost from meat cost, but that's extra work (an alternative would be to vary valueOfAdventure and see the change in the output, so this isn't too necessary).
 

Rinn

Developer
What would you want to happen if the requested number of items doesn't exist in the mall?
 

Theraze

Active member
Good point... probably have a specific "error" response if you're trying to buy more than are actually available, maybe -1 or something since you wouldn't necessarily want scripts to abort though you'd want them to be able to be aware of it, but it would take a LOT of documentation to reduce the whining responses.

And even then, you'd still having whining... it would just be lessened.
 

slyz

Developer
Exactly. I'm less worried about capping the max than about what to do if there aren't any items in the search result (or in the mall). Return 0?

I agree with Catch-22 that mall_price( item, 1 ) should return mall_price( item ), effectively discarding the 5 cheapest items from the search. I'm not sure being able to know the price of the ith item in the mall is very useful... mall price fluctuations can already be tracked with mall_price(), if you manage to get around the price caching.

EDIT: or -1, yes.
 

Theraze

Active member
Yes... mall_price(item, X)/X where X<6 should just be mall_price. At 6 and above... it may start having some variance. The reasoning I had behind -1 is that then you don't need to do another check for mall_price(item) to make sure that it actually is being sold, since 0 is also the mallprice for unsale-able items.
 

Theraze

Active member
So if you do
Code:
mall_price(item, 7)
do you expect that to be the price to buy 2 items or 7 items? What I was suggesting would give you the price for 7 items, without needing to do
Code:
((mall_price(item)*5)+(mall_price(item, 2)))
to get the price for 7 items... the way I'm reading your suggestion, the second would be needed if I actually want to make sure people have enough meat to buy 7 items.

Note that I expect it to be done so that the 4 lowest prices are hidden and mall_price(item, 5) is mall_price(item)*5... but if you're just straight up eliminating the lowest 5 prices (rather than mafia currently eliminating the lowest 4), then...
 
Last edited:

slyz

Developer
Oh right, we're elmininating the lowest 4, not the lowest 5.

Let's say we want to see how much it would cost to buy 10 of item A:
Code:
3 @ 1000 meat
10 @ 1500 meat
10 @ 2000 meat
Mafia's will remove the cheapest 4 items from the results:
Code:
9 @ 1500 meat
10 @ 2000 meat
And mall_price( A, 10 ) will return 9 * 1500 + 2000 = 15500, instead of the 13500 it will actually cost.
 

Theraze

Active member
I'm just saying that since we know that the price for the first is actually the price for the 5th, instead of doing 9*1500+2000 we should do 10*1500. It's high, but it's more accurate and means that people won't just make the wrapper I listed above, since otherwise, you're looking at an inflated inflated price (it's not just the 5th lowest price, it's the 5th-7th lowest prices for 3 items) or does that seem off? I mean... personally, if your form of mall_price gets released, I'll just have this function:
Code:
int multi_mall(item it, int count)
{
  int totalprice = mall_price(it) * (count < 5 ? count : 5);
  if (count > 5)
  {
    if (mall_price(it, count - 5) > 0)
      totalprice += mall_price(it, count - 5);
    else
      return -1;
  }
  return totalprice;
}
embedded heavily into ED and anything else I maintain, but... maybe that's just me. :)
 
Last edited:

Catch-22

Active member
And mall_price( A, 10 ) will return 9 * 1500 + 2000 = 15500, instead of the 13500 it will actually cost.

slyz pretty much breaks it down perfectly. Provided you have mall_price(item, 10) meat, you have enough meat to buy 10 of the items (estimated cost at 15500, actual cost at 13500).

Theraze, I see what you're saying with your function, because mall_price returns the price of the 5th, we know that at least the first 5 will be available at that price or cheaper. I think another reason KoLmafia returns the 5th price is that it will hopefully filter out any raffle stuff happening (which is likely to sell fairly quickly), between the time you check the price and buy the item, the actual cost might go up, potentially higher than your estimated cost. There's benefits in both, one gives you a safer "buffer" for assuming you have enough meat to buy everything.

Also, the data slyz provides is really nice for showing examples but in my experience the price difference when it comes to food/drink tends to be more like 20-100 meat.
 

Theraze

Active member
Really? In my experience, especially when dealing with shops offering limited amounts of items, 500 is a fairly common jump on items. When you're using something like the scout rations or stench wads or other items where you buy 15+ of them, prices can fluctuate a fair amount...

Anyways, just saying that if it does get implemented and item 2 is actually the 6th cheapest, I'll be using my wrapper function to provide slightly more accurate info. Since that does get important when deciding if you're buying 6 or 11 of an item before moving on... :D
 

slyz

Developer
The goal isn't to prevent your wrapper function from working. I want to find a logic that is easy to explain. "Ignore the cheapest 5 items" fits the bill better than "consider that the 5 cheapest items are priced at the 5th cheapest price".
 

Theraze

Active member
Trying to explain that pricing 11 items is actually pricing the 6-16th items, or the 5-15th items, instead of the 1-11th items or 5-11th items with some repeats at the front to not violate mafia's mallbot rules... It's just that in any of the cases with UR or ED buying up the market in specific items... say UR plans on buying 100 green pixel potions (since some were purchased before the log posted began) or whatever it was for DA again. :) Should it stop buying when the price actually jumps crazy-high, or should it stop 5 items short and move on to a new item then? If it stops 5 short, mall_price(it) will still say it's a good choice... but mall_price(it, 1) will say it's bad.

Also, it seems like it will cause confusion to have mall_price(it) and mall_price(it, 1) be different things...
 
Top