On Fri, 08 Sep 2017 17:44:48 +0000 David Lewis <highwayofl...@gmail.com> wrote: > Yes, I agree, so what I did was change it to a 100th... > > + final int alarmBonus = -Math.round(price * 0.001f * getGame(). > getSpecification() > + .getInteger(GameOptions.ALARM_BONUS_SELL)); > Meaning that if the price of goods is 1064 * .001 * 40 (%) = (round) 43
Argh. The numbers/result/intent make sense, but the code had me
completely mislead. Please, if we are using a *percentage* option
can we have it work as a percentage option, not a
percentage-with-hidden-further-division-by-10-option? We are trying to
get rid of hidden magic numbers and you just snuck a magic 10 back in!
Also remember, this is what we are telling the users:
model.option.alarmBonusSell.shortDescription=Percent bonus on native alarm when
selling goods to a native settlement.
which is a bit unfair when it is really:
...=Percent bonus on native alarm when selling goods to a native settlement
which is then divided by 10.
As things stand in the code, anyone looking at csBuy/Sell/Gift will see
0.001f in two out of three places and be naturally lead to suspect that
there is a bug. Merging the hidden extra divisor into the expected 0.01f
conversion factor obscures what is going on. Really strict coding
standards (which we do *not* have here:-) would insist on not even having
a bare 0.01f, but for that too to be an explicit named constant (e.g.
"final float PERCENT_TO_FLOAT_CONVERSION = 0.01f;"). We do not need to go
that far, but the current code definitely needs improvement.
> Old value was: 1064/50 = 21.
> Probably means we should change the sell default value to 20%, rather than
> 40%.
> So: 1064 * .001 * 20 = 21, which would match the current alarm change for
> selling goods.
If you want to preserve the existing value, why not just dump the
extra divisor but use a value of 2%? However I thought we had agreed that
the existing value is too low, hence my suggestion of 10%. If that seems
too high we can just double the existing situation with 4%.
> Gifting I think should be double, so if it's default were 40%, and you gave
> those 100 trade goods to the natives, it's alarm change value would be -43,
> which I think seems reasonable?
I think gifts should be worth sales * n ; n in { 1.5 .. 2 }. If we get
sales right gifts follow.
> Only the buy value is: *.01 * (%), so a purchase of 100 would be:
> 91 * .01 * 80 (%) = -73 alarm change. But maybe it should be 20% as well by
> default.
> 91 * .01 * 20 (%) = -18 alarm change.
> Currently, a purchase is:
> 91 / 50 = -2 alarm change.
I am less worried by purchasing as the values are lower in general and are
less likely to be abusable to easily pacify a neighbouring tribe. IMHO
purchasing *should* be less effective as all you are doing for the tribe
is removing surplus goods, whereas sales/gifts you are providing them with
something they want that they do not have. There is a qualitative
difference. So I believe buy% == sell% is fine as a starting point.
Cheers,
Mike Pope
pgpMk7oD_WQhn.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
