Suggestion - Option to limit amount of items per order

[Demolish50]

Shouldn't there be a limit on how much u can sell at once? For eg if something sells for 10c , the price will only drop if u sell some amount to the station. But that amount can be huge, like 100 million, so you will sell all that for 10c. But if u just sold 1 million at first, it would drop the price and u would get less and less money.

[Demolish50]

Also, to this point, someone can buy everything in the market for an item making the buy price inflate and then turn around and sell to the npc market at a maximum price.

[midspace]

Maybe... (I'm guessing at this), there should probably be a split between the buy and sell price? Keep the (market) Sell price as dynamic, and follow available stock levels. But fix the (market) Buy price as static.

So instead of this dynamic movement of both....

low (high stock)
market sell: $1.00
market buy:  $0.95

medium
market sell: $2.00
market buy:  $1.95

highsurge (low stock)
market sell: $4.00
market buy:  $3.95

Only the market sell price should be dynamic, and the market buy price is fixed at below the high stock sell price.

low (high stock)
market sell: $1.00
market buy:  $0.95

medium
market sell: $2.00
market buy:  $0.95

highsurge (low stock)
market sell: $4.00
market buy:  $0.95

[Demolish50]

Personally, I think the market buy price should change as well but it needs to to delay or possibly have a max purchasing limit per day, even better, on a per player basis. It will only purchase XX amount per day from each particular player?

Or just have a server admin customizable limit on individual order volume. Say 5000 or whatever, they have to execute multiple orders to say sell 20k. Each time they sell5k the market adjusts.

On Tue, Jan 31, 2017 at 10:23 PM, midspace notifications@github.com wrote:

Maybe... (I'm guessing at this), there should probably be a split between the buy and sell price? Keep the (market) Sell price as dynamic, and follow available stock levels. But fix the (market) Buy price as static.

So instead of this dynamic movement of both....

low (high stock) market sell: $1.00 market buy: $0.95

medium market sell: $2.00 market buy: $1.95

highsurge (low stock) market sell: $4.00 market buy: $3.95

Only the market sell price should be dynamic, and the market buy price is fixed at below the high stock sell price.

low (high stock) market sell: $1.00 market buy: $0.95

medium market sell: $2.00 market buy: $0.95

highsurge (low stock) market sell: $4.00 market buy: $0.95

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jpcsupplies/Economy_mod/issues/161#issuecomment-276569053, or mute the thread https://github.com/notifications/unsubscribe-auth/AIEqB6FN9oXMA9SJTSFtL1FE-Ly-y8aPks5rYAi-gaJpZM4LzQnF .

[jpcsupplies]

ye it did originally work with both buy and sell. changing but the price points made exploitation too easy. I settled on adding buy or sell bias so that in theory the buy back price can never be at a profit. you can only profit by buying from different physical stations and transporting it where there is a major price difference.

in NPC markets the default price becomes the baseline and this price reacts to available stock before it is displayed or a transaction is done.

to see how it works set a market item to have the same buy and sell price. eg 1000, then use the set command to increase or decrease the on hand stock you should see only the buy (from player) price dropping on high stock, then capping out at the 1000 on low stock, at which point the sell (to player) price starts going up as stock becomes low. When stock becomes high the sell to player price drops flooring at the 1000. so the prices never overlap so you cant technically exploit it much.

It was the safest compromise logic i could come up with - without adding a bunch of timer delays and market movement size logic which could potentially have a performance impact on the server

[jpcsupplies]

The main reason I didn't use movement size logic (and i wanted to actually) was simply that the NPC market prices are the "base" prices to which reactions to price are applied against. This allows prices to "snap back" without any major exploitable price changes.

Ideally movement size logic could also be used - but the only way this could be done I could think of was:

1. Have prices changes trigger a timer

2. Have the size of the price change vary depending on a combination of the current available stock, and the size of the transaction (so a little of the current logic and some extra modifiers)

3. Multiple price change timers can exist on heavily used markets, and would effect both buy and sell price. (stock market logic) or effect only a single price, but have either the buy or sell price as a fixed variation in price from the other.

4. When a price change triggers, write the change directly to the NPC markets price entry for the item it relates to. (or alternately maintain a second pricing database per market which resets at reboot or on command back to default database - it could only exist in memory for instance)

This has the main disadvantages that

a: prices are still exploitable, but you have to wait longer for the change to occur before you sell back - and another player may beat you too it.

b: it gives less control over the base default market pricing by admins since the price can move quite away from your set prices. This can be mitigated by my alternate logic listed in point 4 above tho - although that might not use our current reactive pricing table which is quite customisable by admins)

c: it potentially makes price modifiers less-central making it more complicated to implement contract prices, missions etc. At the moment however we now have a central reactive pricing routine - which we can plug in any logic we like quite easily. Including a timer driven test which delays updating to the new price - although we would need more parameters to discriminate (last 10 transactions get tracked by a timer or something like that)

d: Current system is pure simple math - which has virtually no impact on performance - so we can throw it at everything from buys/sells/valuations to prices displayed in pricelist and LCD catalogs without hurting sim beyond what these functions already consume. Switching over to additional overhead with a bunch of timers and arrays tracking price changes, transaction movements etc might not be as light.

[jpcsupplies]

Another way to make it work is sales dont effect price at all. But run a timer that periodically checks stock against price and applies reactive price logic in gradual steps. This would be easier to keep central, and keep performance good, but breaks our contract/mission bonus price logic we will need later. (we would need an extra modifier routine checked at each sale to do that - not really world ending) This sort of system would also have to maintain an in-memory price table that resets on server restart. This has one advantage over my prior suggestion in that prices will reset but automatically "snap" back to the price they were before restart on their own, instead of as a reaction to a particular transaction. But the delayed-gradual changes would give a similar effect. If anything it would work better ..

Ie - someone buys ALL the stock. The price doesn't immediately jump up. But if no more stock is sold to the market, the market would start acting "desperate" and gradually increasing prices until our capped price point. That way active markets could sell out and restock before any price changes occur at all.

We could also bolt-on mission/contract to trigger over a certain "desperation" level at that market to offer subsidized delivery prices/bonus missions much like #36 (transport tycoon style delivery subsidies)

This would also eliminate the blitzreig pricing effect @TheEngineer50 mentioned above. Although as stated the system is currently designed so that the buy back price never exceeds the sell price - although if they hit all at once they get the top price, its still less than any permutation of what it will buy it back for.

Or ignoring everything I said above we could simply focus on the exact exploitation scenario he mentioned, and implement some sort of pricing breaks routine so that they only get the price for each pricing point instead of the starting price in one transaction.

Either way, the current logic is just a starting point. Doesn't have to stay that way.

[Demolish50]

IMHO you guys are thinking about it way to hard :). A simple volume limiter solves it and is "good enough" in my opinion.

Call me lazy.

[jpcsupplies]

Hmmm well I suppose the lazy way to do it would be break the sale by the break points too. Trouble is that eliminates the benefit of catching a good price, but does limit people buying out the market to inflate the price then selling a ton back at the peak price. That adds a lot of iterating loops tho, that would be carnage on performance.

The current system makes the peak buy price the baseline price anyway, which the current logic prevents ever being higher than any possible sell price unless an admin deliberately sets a base buy (from) price higher than the sell (to) price or vice versa.

Ie.. To be more concise than my earlier posts - currently the sell (to player) price can only go up from baseline price, and the buy (from player) price can only go down from the baseline.

Even if they exploit the market price breaks ruthlessly - the NPC market still makes a profit since it never buys from a player for a price lower than any combination of price it would sell it to them for. The house always wins.

I do eventually want to add delayed reaction trades as well as auto-trades that free up cash burnt on dead stock like gravel and gives it back to the NPC. But the current exploit avoidance bias seems adequate for now.