Buying food at the mall

JGefell

New member
I am looking to buy hi meins at the mall, and I am not particularly preferential as to the flavor. As such I wish to buy the 3 cheapest I can possibly buy. The problem, however, is that when I check my mall prices mafia does not look to see if after purchasing one of an item if it is still the cheapest.

as an example, I noticed to day that there is somebody selling hi meins for 288 a piece, but has limited you to 1/day. I would like to purchase 3 different types of said hi meins, but mafia checks prices and buys one of them for cheap and defaults to buying the other two and a far more expensive price while there are cheaper eats to be had.

I'm sure the reasoning mafia doesn't auto update mall prices is to prevent mallbots from buying up all the cheap stuff, but is there any way to force mafia to update mall prices on things?

what I'm using now
Code:
foreach i in $items[sleazy hi mein, hot hi mein, spooky hi mein, stinky hi mein, cold hi mein]{
					if (mall_price(i) < cheap_hi_mein){
						cheap_hi_mein = min(cheap_hi_mein, mall_price(i));
						cheap_hi_mein_name = i;
						}
					}
				buy(3-hi_meins, cheap_hi_mein_name);

I realize that this is not good code for what I want, but because I can't get those updated prices, this is how it runs for now.
 
At the moment I can't find the thread the explains why in more detail, but mafia only updates prices a) the first time the price is requested in a session and b) when a purchase is made from the Purchases tab. This is done deliberately to prevent using mafia to build mall bots.

The problem you see has been dealt with in scripts. The technique is to buy one at a time and limit the max price you are willing to pay. Use buy. Also keep in mind that mall_price is also the 5th lowest so there are opportunities to buy even when mall price is high.

I would look at Bale's StoreCredit which is around here somewhere. It wants to buy Alice cards without exceeding a price until a goal is reached. That seems to have a lot in common, conceptually, at least, with buying any hi mein until a particular fullness potential has been achieved.

Alternatively you could use EatDrink, which is also around here somewhere and trust it to pick your hi meins for you.
 
I thought that every time you purchased, it updated the mall prices, whether on the purchases tab or not... as such, as long as you do "cheapest hi mein" between each purchase, it should keep purchasing the cheapest...
 
I thought that every time you purchased, it updated the mall prices, whether on the purchases tab or not... as such, as long as you do "cheapest hi mein" between each purchase, it should keep purchasing the cheapest...

Well, I got it backwards. See this thread where it is stated that
The update of cached prices only occurs when you use the CLI or ASH 'buy' command.

So I was right in that there are ways to buy items that do not update the price but wrong when I said which ways those were. Thus the prices DO NOT update if the Purchases tab is used (and presumably the relay browser as well).
 
It would, if it knew about available limited ~250 meat/himein sales, if it could, which it can't.
First, mafia scripts won't know about them either. Second, the optimal approach is to buy them on sale and resell at full price later.
 
I use http://www.houeland.com/kol/diets?g...ightcap=yes&semirares=0&items=tuxedo&cost=all and there is no meat-per-adventure value where it picks hi meins.

Hmm, from what I remember, Eleron's little tool optimizes based on what you value an adventure to be worth, as opposed to overall profit. I should get around to releasing my consumption script which optimizes based on expected MPA, but at the moment, there's a bug with buying isotope food -- it doesn't seem to want to acquire transpondent. :P
 
"What you value an adventure to be worth" = valueOfAdventure = average profit per turn (revenue - buffs) or value of untradeable/etc gains. Optimizing for that is the same as maximizing profit, leaving the complicated MPA calculation for the player.
 
Eleron's tool also shows total profit = (value of adventure in meat) * (adventures generated) - cost
That seems to be what's optimized there.

Optimizing for average profit per turn is trivially different - don't eat anything! Anything else decreases your profit per turn!

The third thing that can be optimized, but nobody really does, is number of adventures generated given how much meat are you willing to spend per adventure generated.
You can use Eleron's tool to optimize that by going down the list and using the first diet that has value-of-adventure that fits within your limit.
 
The third thing that can be optimized, but nobody really does, is number of adventures generated given how much meat are you willing to spend per adventure generated.

During holidays and similar events I often find myself wanting to do this since I quite often want to experience as much of the content as possible rather than make as much profit out of it as possible.
 
During holidays and similar events I often find myself wanting to do this since I quite often want to experience as much of the content as possible rather than make as much profit out of it as possible.

Are you really maximizing subject to meat paid *per adventure*, as opposed to meat paid *per day*? That's not equivalent.
(If I say "I am willing to spend 5M today", then that's that. If I say "I will pay 10000 mpa" that gives me no idea how much I will pay in the end, and if I estimated the profitability correctly I will end at exactly zero profit for hours of pointless work. If I say "I guesstimate one adventure will generate 10000 meat" then I am probably maximizing total profit again.)
 
The way I tend to do it atm is "Look in the item manager for things that give lots of turns, use them no matter what their price is and possibly buy some other things that I know give good adventure ranges even though they may be a bit overpriced in mpa. Where does that fall? :)
 
I think we have had this discussion in the EatDrink thread. Quite simply, the meaning of MPA is overloaded and a lot of people assume that when they "optimize" something based upon MPA they have formulated and solved a different problem, such as maximizing the number of adventures gained subject to various constraints such as meat, pulls and so on.
 
Personally, I go through this with simulating (using EatDrink) various costs. During holidays, VoA is going to be a minimum of 1000, maybe even 2000. When it's normal time, it'll probably be down at the default of 500. But if the difference in adventures between 1000 and 2000 only gives me an extra 5 adventures and costs 30k more meat for those... meh. :)
 
The way I tend to do it atm is "Look in the item manager for things that give lots of turns, use them no matter what their price is and possibly buy some other things that I know give good adventure ranges even though they may be a bit overpriced in mpa. Where does that fall? :)

Probably "subject to meat per day", since you can't spend more than what you have (unlike some real-world examples).
 
Personally, I go through this with simulating (using EatDrink) various costs. During holidays, VoA is going to be a minimum of 1000, maybe even 2000. When it's normal time, it'll probably be down at the default of 500. But if the difference in adventures between 1000 and 2000 only gives me an extra 5 adventures and costs 30k more meat for those... meh. :)

Hmm.. this gives me an interesting idea. Write up a little script to run through VoAs in Eatdrink and plot that versus total adventure gain.. I'll bet there's some interesting data to be found in the first and second derivatives of that plot (though yeah it's not really going to be a continuous function).
 
Hmm.. this gives me an interesting idea. Write up a little script to run through VoAs in Eatdrink and plot that versus total adventure gain.. I'll bet there's some interesting data to be found in the first and second derivatives of that plot (though yeah it's not really going to be a continuous function).
I did something similar with an EatDrink alternative that Heehehee was working on that had a much more rigorous mathematical basis to the problem being solved and was disappointed because I learned nothing new. Still might be a fun exercise, though.
 
Back
Top