I see what you're saying, and valid points. I'm trying to figure out how to
work that in, because if it's a percentage based on total price of goods,
then a value above 10 is quite a significant change in native alarm. i.e.:
goods with a value of 1064 * .01 * 10 = 106, on a single load of cargo,
that's significant. More reasonable percentage values would need to be
between 2-5% for buy, sell, and gift. A value of 50% would result in 2
cargo loads worth only 1000£ each completely eliminating all alarm.
My feeling is that it should be based on a percentage of a 10th the cost of
the goods. I committed a change to be more consistent, and the description
to reflect that is based on a tenth the value of goods exchanged.
The existing value is only too low for gifts, but fine for sold goods.
Purchased goods seem too low, however now it's adjustable, so we just need
to agree on the defaults.
Feedback?
Thanks!
David
On Fri, Sep 8, 2017 at 5:37 PM Michael T. Pope <mp...@computer.org> wrote:
> 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
>
------------------------------------------------------------------------------
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
