The formula proposed by Jadis is an okay approximation of the In-Game Messaging Tax with the downside of being more and more false the lower your "coppers transmitted" are.
He does end up with the correct conclusion that the higher the coppers sent value is, the more the tax lowers down to 5%.
Indeed I have tested some coppers messaging up to about 250k at which point I cannot go higher.
Here is the data sheet that I will use to explain the exact formula.
First of all we notice that for a regular message (no coppers sent) the cost is 2 coppers. But we do know Nadeo always take at least 5% of any copper transaction (not the message cost itself) and that what they take are always integers. In the data sheet we can see that low values of coppers sent gives us a 3 coppers tax each times. This means we pay the 2 coppers for the message and a Rounded Up 5% of the coppers we want to send : 1 copper since the values are low (it is not possible otherwise, for example with 5 coppers sent : 5% of 5 is 0.25 so Nadeo either takes 0 cp or 1 cp from you but 0 would mean they take 0% therefore making one of the conditions above not verified ; it then adds the 2cp price of the message itself).
Let x be an integer (number of cp sent) :
Number of cp payed = roundup(x*1.05)+2
The tax is nothing more than the cp payed - cp sent :
Tax =
roundup(x*1.05)+2-x
=
⌈x*1.05⌉+2-x
=
⌊x*1.05 +1⌋+2-x
(This is the column D of the sheet which always match the experimental taxes in column C)
Now this is where it starts to get interesting : the conditions of Nadeo gives us a function with an Integer Part : ⌊⌋
This means that the tax = f(coppers sent) will have a stairs like shape. These "stairs" will also appear in the Tax function in % because it depends on the previous one.
By using an easy cross-multiplication :
tax(coppers)/tax(%) = sent(coppers)/sent(%) <- this is 100 because it is all the cp we want to send.
so
tax(%) = (100*tax_cp)/sent_cp
But we do have tax_cp we determined just before ; and sent_cp is nothing more than x.
tax(%) = (100*( ⌊x*1.05 +1⌋+2-x ))/x
We end up with an inverse and stairs type of function in green here :
http://i.imgur.com/NpLzAn3.jpg
The function in red is the one Jadis proposed which approximates our result better and better as the cp_sent gets higher the stairs get smaller and the scatter also.
However in the low transactions the average error keeps getting bigger as we approach 1.
I hope this showed that games uses some rounding quite a lot, also known as floor() and ceiling() programming functions in order to give us accessible integers numbers in their games
