Feature - Rejected acquisition_cost() / creation_cost() -- topping the ASH function wish list!

It seems that the time is ripe for an ASH acquisition_cost(int n, item it) function, and/or a creation_cost() function. The latter is arguably better due to having more specific results.

It would return the cost of acquiring (or creating) n of it, or -1 if you are unable to acquire/create the specified number of items. The result would include the cost of adventures used in crafting (using the valueOfAdventure preference), and would consider user settings, such as whether or not to pull or purchase items (if so, the mall price of items that would be purchased would be included).

Basically, if I type acquire n it or create n it in the CLI, how much would it cost me?

This seems like it wouldn't be too hard in ASH, but it's actually quite involved. Mafia's internal item acquisition/creation algorithm is lovely and it's an awful lot of work to recreate in ASH. I made a decent bit of progress (to the point of parsing creation type and recursing ingredients) and then realized that there are more than a couple things mafia considers which are not transparent in ASH. For example, if you don't have a cocktailcrafting kit but you have the meat to purchase one, crafted drinks still appear in the item manager, but are not shown in either creatable_amount() or available_amount(). When buying items that are themselves creatable, mafia also considers the cost of buying ingredients vs. the whole item.

This logic would be lovely to have available in a predictive form.

The only information currently missing is the cost of a pull -- which it would need to consider if the user had allotted pulls for use. A valueOfPull setting would be the fairly obvious solution for this, consistent with valueOfAdventure.

Any other issues or roadblocks? A decision is required whether to include the price of cocktail kits / tenderizing hammers / ovens, but I'd say not -- those are more like a prerequisite skill acquisition than part of the cost for the specific item. Not including it is also more useful for cross-user comparisons.

Me would love this function long time. There are numerous wonderful uses for it in the item management arena -- and of course, in a script I'm currently working on.

I agree with this, it would really help in all sorts of scripts.

I have found Ascend, EatDrink and a couple of other scripts make decisions I do not, like on my behalf. More precisely, they make wrong decisions for my character based upon strategic or play style factors. These are due to the various constants that try and convert everything of value into meat. My experience with tweaking them reminds me too much with tweaking non-linear, possibly chaotic, systems with sensitive dependence on initial conditions. So while I agree such functions are useful I would much prefer that the functions return a record that has number of pulls, number of adventures and meat (potentially) spent. Since making such a record a native ash data type is an effort I'm in the position of not endorsing the original proposal or my suggested alternative.

Maybe I'm a bit paranoid, but unless this new function uses the fifth lowest mall price (as do all other KoLmafia functions), it'll probably be used by someone for mallbotting.

That being said, a record would probably be the best way to handle the return value, as meat isn't the same as adventures or pulls (at least for hardcore/ronin -- I guess in aftercore you could buy stuff and donate meat to the hall of legends? Still doesn't account for untradeables or quest/dungeon advancement.). However, calling such a function would look really weird (like:
), especially since there's currently no way to store an anonymous record to a variable (JH mentioned this when he implemented item_drops_array()). Also, he didn't want to reserve more words just for functions that appear maybe once, so that's probably out of the question, as well.

I'm actually for the implementation of this function, since attempting to recreate Mafia's processes in ASH seems a bit like reinventing the wheel. Handling it just seems really weird.

There's no way to make any prediction whatsoever about the results of an item acquisition, in the presence of a buyScript. Are you suggesting the removal of that feature?

In any case, this would require the complete duplication of all the item acquisition logic. We'd just have to hope that every time someone makes a change to that logic in the future, they'd remember to make the corresponding change to the predictive version. And even after all that work, there would still be no guarantee that the results match reality, due to mall price changes (which may completely change the remaining build vs. buy decisions once discovered), clan stash items that someone else has pulled, etc.

Don't hold your breath waiting.

heeheehee said:

Maybe I'm a bit paranoid, but unless this new function uses the fifth lowest mall price (as do all other KoLmafia functions), it'll probably be used by someone for mallbotting.

Click to expand...

Wait, what? So that's why it tried to make me buy a 900,000 Meat item when there were like 3 stores at minprice of 300 meat in the mall? That's... kind of absurd.

It'll still use the cheapest price when it buys anything but any scripted searches done will generate the 5th lowest price.