Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion - Option to limit amount of items per order #161

Open
Demolish50 opened this issue Jan 31, 2017 · 8 comments
Open

Suggestion - Option to limit amount of items per order #161

Demolish50 opened this issue Jan 31, 2017 · 8 comments

Comments

@Demolish50
Copy link

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
Copy link
Author

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
Copy link
Collaborator

midspace commented Feb 1, 2017

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
Copy link
Author

Demolish50 commented Feb 1, 2017 via email

@jpcsupplies
Copy link
Owner

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
Copy link
Owner

jpcsupplies commented Feb 12, 2017

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants