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
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.
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?
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.
-- David
On Thu, Sep 7, 2017 at 3:19 PM Michael T. Pope <[email protected]> wrote:
> On Thu, 07 Sep 2017 14:50:32 +0000
> David Lewis <[email protected]> wrote:
> > Can you review the open pull requests and if they look good let me know
> so
> > I can merge them?
>
> I am a bit backlogged ATM, but did have a quick look the other day. There
> were several issues with the gifts one, but the real showstopper there is
> that we need to work out reasonable values for the magic numbers. I
> agree ATM the price/50 value is too low, but I suspect price * 40% goes
> the other way.
>
> It is not too hard to to sell a high value cargo for 1000 gold (I just
> tried with a starting game and 100 Trade Goods and got an initial offer of
> 1064 from the Arawak), so that is a change of around -400 alarm. The
> *entire* meaningful range of alarm is from HAPPY(100) to HATEFUL(1000)
> (see Tension.Level), so all it would require is 2 big trades to go from
> near war (ANGRY(800)) down to happy again. That seems too fast to me.
> My suggestion is values of 10%/10%/15%, but admit I (semi-)pulled these
> numbers out of the air (100 is the minimum alarm distance between named
> levels), and thus would really like some rationale, or even better,
> actual Col1 measurements to base this on.
>
> The deSoto one is fine and does the job. Thanks for following this up.
> However looking at it reminded me just what a mess LCR.chooseType is:-P.
> Feel free to commit, but I am seriously tempted to rewrite the whole
> routine for clarity.
>
> Should have some time over the weekend to catch up. Playtesting has
> thrown up a few weird things I need to follow through on, notably I am
> unhappy with the fix for BR#3083.
>
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/freecol-developers
