[Fyron]

The additive system allows for more bonuses and penalties to be applied at the same time without making the mathematics unnecessarily complex.

The percentage to hit is indeed a probability, but the method of acheiving the final probability currently used in SE4 allows for more flexibility and more options.

Hmm, we obviously don't agree on how to interpret something like "range modifiers to remain constant". To be clear, I am advocating a probability-based, multiplicative system across the board, including for range modifiers. So instead of having a 10% penalty per square and applying that in an additive manner, I would have a multiplicative factor by range. Translating the current scheme directly, that would be 1.0 at range 1, 0.9 at range 2 and so on: 0.8, 0.7, 0,6 and so on down to a factor of zero at (max range +1). My argument runs along the lines that in this scheme, the range modifiers are MORE constant, not less. So if the factor for range 6 were 0.5, and the factor for range 7 were 0.4, you would always be 20% less likely to hit at range 7 than range 6.

Your system makes all bonuses/penalties have less effect at long range than they do at short range though. A 20% penalty to hit from the enemy having ECM I currently gives you a to hit chance of 80%, modified by range. In your system, you get to hit chances like this with a range 10 weapon:

range 1: 1.0 * .80 = .80
range 2: 0.9 * .80 = .72
range 3: 0.8 * .80 = .64
range 4: 0.7 * .80 = .56
range 5: 0.6 * .80 = .48
range 6: 0.5 * .80 = .40
range 7: 0.4 * .80 = .32

So, at range 1, the ECM provides a 20% to hit penalty (from 100% to 80%). At range 5, it provides only 12% to hit penalty (from 60% to 48%). Your system makes the ECM less effective at longer ranges, which does not make any sense (being counter-intuitive and all). The same thing applies to all other modifers too. They are not supposed to provide variable bonuses, but constant bonuses.

There's a limit to how far that 'implies' argument can be taken of course, because we are postulating what others, or at least a majority of others, might understand by a 'percentage chance'. But for me, at least, "50% chance" is synonymous with a probability of 0.5. Similarly, I interpret "20% bonus" for a particular factor as meaning "20% more likely with that factor than without it", and hence I would think of that as being 1.2 times the probability. Conversely a 20% penalty would mean (20% less likely with that factor than without it", and hence 0.8 times the probability. As I said above, in probability terms that bonus or penalty always has exactly the same effect.

This requires that the to hit modifiers be very strictly limited to only a few input values, instead of all possible modifiers just being added to the to hit chance. It also unnecessarily complicates the calculations, while granting counter-intuitive effects.

Disagree. . As argued above, in probability terms the relative chance of hitting at range X versus range X+1 would always be the same. No edge effect at all. The argument about "when each modifier goes into effect in the calculations" I reject because it depends on using a mixture of addition and multiplication. Both operations are associative and commutative in themselves;

a + b + c = c + b + a = (a + b) + c = a + (b + c)
a * b * c = c * b * a = (a * b) * c = a * (b * c)
BUT
(a + b) * c != a + (b * c)

In fact the current system has mixed the operations; in that we have a series of additive operations, resulting in a number. That number is then divided by 100 to give a probability. I'm advocating no additives at all, but multiplication for all these calculations.

I know how algebra works...

Converting a percentage to a decimal probability value is completely irrelevant to this argument. That one operation of division in no way makes the se4 system have mixed operations. All chances to hit are added, there is no multiplication in them.

Part of the reason I suspected machine limitations/unacceptable overhead of floating-point calculations was that large battles can take so long to calculate as it is, on a lower-spec machine.

Only if you use unnecessarily large floating point variables. With the to hit chances, you really only need them to have 4 digits, the 1 place and 3 decimals. Any more does not have a significant effect with rounding errors on the calculations. These variables are not much larger than the integer variables, as they can also get 4 digits in them. Both require negative input values, so that balances out in the memory size of the variables.