Bug retrieve_price bug

S

Shiverwarp

Member
retrieve_price returns the mall_price of an item in your inventory, even if the meatpasting components required to create it would be cheaper than the mall price.

For example:
The mall price of whirled peas is: 1,331
The mall price of handful of split pea soup is: 10,000
valueOfInventory preference is 2

If I have a handful of split pea soup in inventory, running retrieve_price($item[handful of split pea soup] will return 10,000 instead of 2,672
If I have no handful of split pea soup in inventory, it will return 2,672 as expected.

Expected behaviour: retrieve_price returns the lowest price of meatpasting items, regardless of whether you currently have one in inventory.
 
Worth noting that if you do this:
Code: 
retrieve_price($item[handful of split pea soup], available_amount($item[handful of split pea soup]) + 1) - retrieve_price($item[handful of split pea soup], available_amount($item[handful of split pea soup]))
you get the expected value. But I think in most situations where I'd call retrieve_price on a craftable item, I care about the cost of an additional or replacement item, not the cost of not selling the one you have in your inventory.
 
Last edited:
This is not the "cost to create". If that is your "expectation", perhaps you should reconsider how you are using it.

retrieve_price (aka priceToAcquire) is used by priceToMake is used by cheaperToBuy is used by retrieve_item.
That last function (aka "acquire") only considers buying or making if you want more than you already have.
That's why available_amount + 1 works the way it does.

I wrote priceToAcquireTest.java - which also tests priceToMake. It's 750 lines of detailed tests.
The tests tell me that it works as "expected" - assuming you have the correct expectations. :)

Code: 
int retrieve_price(item)
int retrieve_price(item, int count)
int retrieve_price(item, int count, boolean exact)
exact is use "current" mall price vs. "historical" mall price.

Meaning of valueOfInventory (default is 1.8):

Code: 
    // 0.0 - Items already owned are considered free.
    // 1.0 - Items are valued at autosell price.
    // 2.0 - Items are valued at autosell price if min-priced in Mall.
    // 2.0 - Items are valued at current Mall price, if not min-priced.
    // 3.0 - Items are always valued at Mall price (not really realistic).
 
This is not the "cost to create". If that is your "expectation", perhaps you should reconsider how you are using it.

retrieve_price (aka priceToAcquire) is used by priceToMake is used by cheaperToBuy is used by retrieve_item.
That last function (aka "acquire") only considers buying or making if you want more than you already have.
That's why available_amount + 1 works the way it does.
Click to expand...

Perhaps I misunderstand the intention of the function - my expectation was that it was "what is the value of this item" aka "how much meat does it effectively cost if I were to consume it"

In the case of meatpasting, since everyone can do it and it does not cost a turn, shouldn't the value of the item when using this function, be the cheapest way that we can acquire it? Whether via meatpasting together components or otherwise?

(Me mentioning valueOfInventory was only meant to be relevant to the example I gave, so there was no changes compare to mall price.

Were it the default of 1.8, I would still expect retrieve_price to return the lowest effective value of the item.

If I had 1 whirled peas in inventory, and had a handful of split pea soup in inventory, I would then be expecting retrieve_price to use that valueOfInventory on the single whirled pea in inventory, combined with the mall price cost for purchasing a second one, and then +10 for the meat paste for the cost of crafting a split pea soup for cheaper than buying from the mall)
 
Last edited:
That is exactly what it is telling you. "The cheapest way you can acquire" an item is to use one you already have; that's how retrieve_item() works.
Now, if you want to acquire two, but only have one, retrieve_item() will decide whether to buy or create the second.

Since you told retrieve_item that items in inventory "cost" min mall price (valueOfInventory == 2.0), your "cost" to retrieve an item in inventory is the mall price - the Meat you could supposedly get by selling it. If you don't like that, set valueOfInventory to something less than 2.0.

FWIW, vcon does this: int price = retrieve_price( needed, consumable, true ) / needed; - where "needed" is the amount it would like to have.

Given existing functions, perhaps set valueOfInventory to something lower or closet your items so it HAS to buy or create them.
Or perhaps we could expose priceToMake as the create_price or something. I thought we already had that.
 
"The cheapest way you can acquire" an item is to use one you already have
Click to expand...
I suppose this is the part that confused me. I imagined the function to be a "cheapest price" of an item (in the case of bowl of split soup, it is to actually craft it, rather than to buy from mall, so a price of 10,000 confused me)

If you don't like that, set valueOfInventory to something less than 2.0.
Click to expand...
My understanding was this only changed things by lowering the value closer to autosell price, and would have no effect on this specific situation where it is cheaper to craft, no? (Other than lowering the value of both the bowl of split pea soup and the cost to craft it from whirled peas, to be lower than mall price)

If the answer is just "Bypass this issue by always using retrieve_price as available_amount + 1", then fair enough!


Perhaps for clarity I'll just specify the reason this came up:

Libram has a function for trying to find the cheapest "free run banish" (Louder than bomb, split pea soup, divine champagne popper, etc), and I wanted to use retrieve_price to determine the effective costs of these. I noticed that it was not using split pea soup because I already had one in inventory, and thus was valuing it higher than its actual cost.
 
Last edited:
Veracity said:
Or perhaps we could expose priceToMake as the create_price or something. I thought we already had that.
Click to expand...
How would a hypothetical create_price behave in this scenario? Would it always return the cost of making it by crafting? Would it return the lower of the cost of crafting it vs mallbuying it? Would it do a third thing?

I think this is a good solution; I'm fine doing a difference or division with retrieve_price, but also this feels like a desirable value to expose natively.
 
I assume it would use priceToMake, which returns the lowest of crafting vs. mallbuying.
Note that this, also depends on valueOfInventory, since it assumes you'll want to use items you already own.

Fun fact: that is mutually recursive with priceToAcquire
- priceToAcquire calls cheaperToBuy with calls priceToMake
- priceToMake calls priceToAcquire for each ingredient

And my priceToAcquire tests also include priceToMake tests.
 
Alright after working a bit on trying to make something for libram here is an overview:

We would like to be able to determine the effective cost of consuming an item.

using retrieve_price works great for this, except in the following situations
  • The best effective way to create the item is through something like meatpasting where the components are cheaper than the created items mall price, and we also have at least one of those items in our inventory. Having access to priceToMake would fix this issue
  • The best effective way to create the item is something that is "free", such as Mayam calendar or Takerspace. This means priceToMake would return 0 (I assume), but what we want is priceToMakeAndConsume in this situation, because things like Mayam and Takerspace are limited per day, so their products actually have value.
 
You must log in or register to reply here.
Back
Top