Front Page › Forums › MCNSA › price equation changes
As was already noted on the PO8 store news feed, the equations for determining store prices have changed to vary more gradually, and transaction sizes have been capped.
For those who are curious, the new equation for price is this:
maxprice / ((current stock / 1728) + 1)
The gist of this equation is that, when the store has no stock, the price is set to a maximum price which was determined by Octavian, and the price gradually drops so that for every 1728 (27 stacks) of the item that the store buys, the price cuts in half. (Down to a minimum of 1/16 the maximum price, currently. Theoretically we could remove the minimum as the equation is set up so that the price never reaches 0.) Transactions of a single item are now limited to 27 stacks, so since the store is always willing to buy items at half the price it sells them at, it’s now impossible to game the system – you can only buy enough of an item to raise the sell price to what you bought for, or sell enough to lower the buy price to what you sold for.
(This is part of the reason for the new cap on transaction size (27 stacks of a single item per transaction, and 54 stacks total). The other reason is just to keep orders manageable for shopkeeps.)
So far I think the system’s working well. One consideration I’m realizing after the fact, though, is that while buying and selling large quantities of dirt, cobble, stone, etc. is very common, other items tend to get traded in smaller quantities, so perhaps their price should fluctuate more quickly. This leads to a question I’m throwing out there for discussion – would it be worth making that “1728” number in the equation different for different items, so that prices can drop/rise more quickly for certain items – *keeping in mind*, however, that that would require further limiting the transaction sizes for those items? (So for instance, we could alter wool so that its prices halved, say, every 12 stacks, instead of every 27 – but then we’d have to limit wool to 12 stacks of a given colour per transaction.)
I think it would be a good idea to change some of the equations to a little lower, especially for things like discs ðŸ™‚
So, does this mean that I can only sell a total of, say, 27 stacks of blaze rods over the course of this entire map?
I have been using po8 to sell things and raise money so that I can distribute it at random (which I can’t do in game until the plugin is restored). I need some clarification. I’m also not reading carefully since I’m in AP US History right now, but can I get some clarification?
the 27 stack limit is only for orders. and is per order.
You can buy and sell as much as you want.
Thanks, in that case, I have no objections.
Two things.
Your above equation doesn’t cut the price in half every 1728 stock. It cuts it by 1/3 after 2*1728, by 1/4 after 3*1728, by 1/5 after 4*1728, etc.
The equation you were looking for to cut the price in half every 1728 stock (so that 2*1728 will cut it by 1/4, 3*1728 will cut it by 1/8, etc) is (base price) * (1/2)^(current stock/1728).
Second, with a bit of calculus, you can smoothly calculate prices for stuff no matter which quantities you’re going from and to.
[s:2sas9qvo]For the equation you have, the antiderivative (thanks wolfram alpha!) integral b/(1+a/x) dx = b (x-a ln(a+x)). So if we want to get the price when somebody wants to buy 10 of something, say, do:
base price * ( 10 – 1728 * ( ln(1728 + 10 + current_stock) – ln(1728 + current_stock)))[/s:2sas9qvo]
Edit: I typo’d there taking the integral. Glad I checked it! It’s actually a little easier. It’s base_price * halfing_quantity*ln ( halfing_quantity + current_quantity)
So, for our example of 10:
base_price * 1728 * ( ln (10 + quantity + 1728) – ln(quantity + 1728) )
This isn’t subject to quantity limits or any other similar issues, and as long as quantity is updated at the end, will always give you the correct prices and keep the system working well.
Now, if you wanted to switch to the true halving equation, the antiderivative is: – base_price * halfing_quantity / ln(2) * (1/2)^(current_stock / halfing_quantity). So to calculate the prices:
base price * 1728 / ln(2) * ( (1/2)^(current stock / 1728) – (1/2)^( (current stock + 10) / 1728 ) ).
[s:2sas9qvo]I didn't completely check my math, but I *think* it's right. I'll check it later. If you want to implement it, don't do so until I verify it's working right.[/s:2sas9qvo]
Edit: Checked my work! Fixed what I did wrong! It’s good now. Talk to me if you want to use this and need help. ðŸ™‚
…whoa.
No idea what just happened, but it sounds smart. ðŸ˜›
@Pyrotek wrote:
…whoa.
No idea what just happened, but it sounds smart. ðŸ˜›
Math happened, Pyro. And I answered the question of “When in the hell does Calculus ever come in handy in real world applications?”
Doesn’t happen often, but when it does, you save TONS of work.
Thanks Alti – actually I caught my mistake a couple days after I put it in and figured out what I should have done, and I’m already working with Maboughey on getting the correct equation in the code. (Once I realized it, I was surprised somebody didn’t call me out on it sooner – I guess you’re the first one to take a close look.)
Doing the calculus would definitely remove the need to further limit transactions of specific items (although I’m still in favour of keeping the general one-inventory’s worth of an item and two-inventory’s worth total limits per transaction, just for the sanity of the shopkeepers!). I’m concerned, though, that it makes it difficult to know what you’re going to pay for something when you look at it in the store. If you see something listed at a price of 1 PO8, and you add 64 of it to the cart, and it shows the total price in the cart as being greater than 64 PO8 – that’s confusing and may make some people think the system simply isn’t working correctly (it also makes it hard to figure out how much of an item you can afford, except through trial and error or else doing the calculus yourself every time). Do you see what I mean?
The correct equation is now being used:
currentprice = maxprice * ( .5 ^ (stock / maxordersize) )
Where maxordersize is currently still 1728 for everything, so that’s the point at which the price halves.
Does anybody have any input on whether they’d accept limited to smaller transaction amounts on certain items to let the price fluctuate quicker? (So for instance, we’d leave things like dirt and stone alone, but we might limit ender pearls to 64 per transaction, so that the price can drop in half with every 64 pearls sold to the store, and we might limit music discs to 4 of each type per transaction so that the price can drop in half with every 4 discs sold, etc.) The idea would be to get the maxordersize for each item close to the amounts in which people typically want to buy and sell them.
Alti, something else is bugging me about your calculus approach. Would we have to set the sell price and buy price equal to each other? The idea right now is that if you buy and sell in maxordersize amounts, you end up paying exactly what the person who sold that stock to the store got for it, so the store breaks even and is basically a medium between the two players. (When you buy and sell in less than maxordersize amounts it makes a small profit on the deal.) If you use the calculus to smoothly vary the price, then that means the person who sold the stock gets paid less for it, and the person who buys it pays more for it, right? (Meaning that the store would always make a significant profit, and more quickly gets filled up with items that can’t ever get bought back out again because the populace lacks the necessary po8.) So are you assuming we’d just have one buy *and* sell price, or am I missing something significant about your approach?
Olarin – I can write more indepth about this later, but whether we do a zero-sum po8 system OR a margin-system po8, there isn’t going to be enough po8 in order to purchase everything back, as there will always be people with po8 who aren’t active, or who have a TON of po8 and are only looking to buy very specific things.
@Olarin wrote:
Alti, something else is bugging me about your calculus approach. Would we have to set the sell price and buy price equal to each other? The idea right now is that if you buy and sell in maxordersize amounts, you end up paying exactly what the person who sold that stock to the store got for it, so the store breaks even and is basically a medium between the two players. (When you buy and sell in less than maxordersize amounts it makes a small profit on the deal.) If you use the calculus to smoothly vary the price, then that means the person who sold the stock gets paid less for it, and the person who buys it pays more for it, right? (Meaning that the store would always make a significant profit, and more quickly gets filled up with items that can’t ever get bought back out again because the populace lacks the necessary po8.) So are you assuming we’d just have one buy *and* sell price, or am I missing something significant about your approach?
The calculus approach is identical to yours only smoother.
If somebody sells something, and gets 100 po8 from the sale, and then somebody turns around and buys exactly what the person just sold, it would cost 100 po8.
The store is making zero money with the calculus method.
To use my method for buying from the store instead of selling to the store, use a negative number for the quantity.