Updates to the current threads...
- The language now reflects that the alarm value is a percentage of a tenth
the total value of goods being exchanged in a trade.
- Builds for the Mac app are now (finally) working.
I'm one step closer to getting nightly/weekend builds published to Github.
Stay tuned!
David
On Sat, Sep 9, 2017 at 12:29 AM David Lewis <highwayofl...@gmail.com> wrote:
> 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
