Dale said:
I think your code is giving an extra first strike for free.
That much is obvious. And I'm still rather certain you're wrong, no offense. Maybe if you weren't so convinced I don't know what I'm talking about it'd be easier to show you the truth.
Dale said:
or something from 0 to 0.999999 recur,
That is impossible, b/c it returns integers.
Dale said:
if a unit has a first strike, either natural or promotion, then setCombatFirstStrikes will always be non-zero. This is because firstStrikes() returns natural + promotions. So your example of "Assume zero full first strikes. If you have 5 fs chances" is invalid because firstStrikes() will return the addition of both parts, not one of the two parts.
So? You are completely missing the point. I am NOT saying setCombatFirstStrikes will or will not always be anything. I am taking issue with how it converts FS Chances into actual FS's. I meant assume the unit has 0 full fs's and 5 fs chances IN THE XML or with promotions, going INTO setCombatFirstStrikes.
Dale said:
If a unit has 1 first strike under vanilla code, then the "else" becomes 1 + random chance. Now, even if the chance is 0 there will always be 1 first strike.
Yep. No argument here.
Dale said:
If a unit has 1 first strike under your code, then the "else" becomes 1 + random chance + 1. This gives the unit a minimum of 2 first strikes in combat even though the abilities give it 1.
False. Because Soren(1) still always returns 0. My +1 is in the Soren argument, not added to its result.
Remember, 0 to x-1 with a minimum of 0 is the range on the result, I'm certain of it having gone over the code. (There's also several dozen instances of vanilla code calling Soren in other places that assumes this. Take any instance -- and there are many -- of odds = some integer i, like 60. The test that follows is Soren(100) < i. Not <=. That can only be right if the range is 0 to x-1. Meaning in this case 0 to 59. Which is exactly 60 actual numbers, counting them. The remaining set is 60 to 99, or 40 actual numbers. 60 / (60 + 40) = 60%.)
The fundamental problem is that, in my 15+ years of computer programming, I have never seen a random function that didn't return EITHER (0 to x-1) OR (1 to x). It's common sense that if you pass the argument 5 you want the return range to encompass 5 numbers. It's also tradition and precedent that it's done this way. With First Strike CHANCES, you want the ENTIRE range returned. 5 chances means you could get none of them. You could get all of them. Or anything in-between. That's 6 total values: 0 1 2 3 4 5. It means Soren(chances+1) has to be used regardless. If the function returns (1 to x) you have to subtract off 1 afterward but the bound still has to be expanded to encompass the extra value.
If anyone else wants to jump in and back me up on this, *please* feel free.
On a side note, just picking a random like this is the same as doing a coin flip FS-Chances times and adding up the resulting 0's and 1's, except that the distribution is different. The coin flip method gets you a Bell Curve; the single-random-from-the-whole-range gets you a horizontal line. I like the latter better in this case personally.
) I would be very thankfull.
