You can do it while paused in singleplayer and can do it in multiplayer,but you cannot do it while paused in multiplayer, so I dont think it is particulary useful. You might want to fix it though, I can see lower elo players getting a significant advantage by writing scripts to do the trading for them, faster than me who put both options on the same hotkey in the video.
At higher Elos, wasting APM on the market for 1 gold is probably not viable, especially since the opponent can just buy/sell the resource to throw you off.
These 2 more cases (I did not test them. Just in theory), sell for 29/26 and buy back at 28/25. To adjust exchange_rate for these 2 cases, we need to buy the resource to the max_price(9999) and sell the resource back which is impossible in real match.
Based on my understanding(correct me if I’m wrong), there are a few magic numbers (or called constants) in this resource exchange system:
MIN_EXCHANGE_RATE = 20
MIN_BUY_PRICE = 25
DECLINE_PER_TRANSACTION = 3 (It was 2 in The Conquerors)
FEE_SARACEN = 5
The selling/buying prices are the following:
sell_price = exchange_rate * (100-fee)%
buy_price = max(MIN_BUY_PRICE, exchange_rate * (100 + fee)%)
By solving “sell_price(exchange_rate) > buy_price(exchange_rate - 3)” with Saracen fee, we get exchange_rate < 31.5 and that’s why there are so many exploit cases for Saracen.
I believe the original developers considered this exploit and set the above magic numbers(MIN_BUY_PRICE=25 and MIN_EXCHANGE_RATE=20) according to the original DECLINE_PER_TRANSACTION=2, unfortunately, this decline was blindly increased from 2 to 3 without reconsidering the other 2 constants and it causes the issue.
- increase MIN_BUY_PRICE from 25 to 30 ← seems to be the easiest way
- increase MIN_EXCHANGE_RATE ← This would impact on gameplay a lot
- increase Saracen fee ← This would be a nurf to a civ which already has really low win rate
- reduce DECLINE_PER_TXN from 3 back to 2 ← Bad solution and it impact on gameplay.
Mind the question, what’s, so bad about this?
I don’t know if you guys ever played the star wars version of age of empires, galatik battlegrounds.
There the trade faction with the drioidd can get a unique tech for 0 trade fee so even better than saraxen and can exploit this to gain 2 gold per click no matter what price.
Sell for 100 buy back for 98.or buy for 100 sell for 102. But is mega click intensive, since that game doesn’t have keyboard shortcuts for makeets.
I think a mini code hack would be better
IF ( civ == saraxen && effective sell price 26)
Then change effective sell price to 25
There must be a reason that increased this var for the past change. What I guess is that they want the price drop faster so there is less gold in game.
I tested in the scenario editor (by giving myself a lot of gold to reach the cap, I dont know how to set market prices through triggers), with a “true price” of 27 , the market says 26/29 so while you can make 1 gold by selling for 26 and buying for 25; for some reason the selling price, which I thought would be 27*1,05 = 28,35 = 28 in game, is 1 higher than expected. Why is this particular price not calculated like every other? Well at least it fixes this exploit in 1/4 cases, so whoever coded this spaghetti, good job, you missed a spot.
Apologies to the spaghetti maker, I just noticed the “true price” of 87 should result in 83/91 according to my formula, but it is 83/92 in game… either the game rounds .35 up, or the “true price” isn’t necessarily an integer.
Ok, I just realized there are more prices weird:
True price|Buy/Sell|Calculated|In Game
75|S|71,25|71 (expected, keep in mind for later)
I first thought that the market always rounds up from .25 , but starting from the standart 100, this is clearly not the case, buy price at 94 and sell at 85 are exactly as expected. Also, it is only the buy price that rounds up at .25, but both do round up at .3 . (but only if you have reached the upper limit with the market, the normal prices behave as expected)
This is most perplexing.
Thanks for the testing and just fyi, the price shows in market panel might round incorrectly. For example, initial stone sell price for Saracen should be 130*0.95 = 123.5 and it shows 123. However, I would actually get 124 gold when I sell 100 stone. When I ask another player to buy the stone back(true price back to 130) and then sell 100 stone again, I would get another 124 gold. It means the sell price is indeed 124 instead of 123.5(as calculated) or 123(as UI). You may need to actually buy/sell the resource instead of getting the price from UI panel to test whether the rounding logic is expected or not.
I do not intent to check every single value i listed… but I can confirm, while the market says “Buy for 29” at 27, it actually just costs 28 gold. So…yeah. This still doesnt explain why the rounding for the 3n+1 market values are different from the 3n ones, or why the shown value is rounded differently from the used value, or, for that matter, why at the easily achieveable price of 28, the buy price is shown as 29, yet if you have 29 gold (from trades alone, villagers carry fractions), it makes the “succesfully bought” sound yet nothing happens, but if you have 30, it does remove gold, and only 29 at that.
Meaning on top of the 2 seperate rounded values, there is an unrounded value also involved in market transactions.
who in the world in sane mind would do this, takes all the apms 11
- Bugs should be fixed regardless of abuseabilty
- Script kiddies would mind
- You know how many APM some people have? You also know that a free-spinning scroll wheel surely isnt cheating? Do you realize that “gamer mice™” have re-programable buttons, do you want to be responsible for button altering, free spinning, reprogramable scroll wheel having computer mice spiking in value?
Yes you are right, thats ridiculous. Still, why do you take such offence to a literal bug report that you leave this rather rude comment here?
i wasnt rude-sorry if it seemed so. I was laughing because abusing it manually would kill him hilariously. tried the lith relic bug once-kissed the dirt. that’s why i was laughing
Hi everyone! Thanks a lot for this report. We are now tracking the issue. Thanks!