More precise chance of ABMs, LBMs and item drops

Problem

The chance argument in ABMs, LBMs and the item drop chance (as rarity) is quite coarse. It allows you to specify chances of 1/chance, where chance must be an integer.

However, this is quite limiting, as many percentages are missed, especially for small chances. If you calculate the percentages for the first 10 possible chances, you get:

chance  percentage
 1      100.0%
 2       50.0%
 3      ~33.3%
 4       25.0%
 5       20.0%
 6      ~16.7%
 7      ~14.3%
 8       12.5%
 9      ~11.1%
10       10.0%

Notice that many important percentages are missing. Most notably, we don’t have access to any percentages between 50% and 100%, or ~33.3% and 50%, which is quite a lot. No 90%, no 80%, no 70%, no 60%, no 40%, etc.

Solutions

Add a chance_numerator argument to core.register_abm and core.register_lbm. This is an optional positive integer that defaults to 1.

The calculated probability will be chance_numerator/chance.

The benefit

This change will unlock basically any probability you’ll ever need, the huge gaps in the 1/chance formula are closed. You can specify any percentage between 1% and 100% exactly by setting chance_numerator to 100. You can increase the precision with chance. You can specify fractions like 3/4 or 2/3 exactly.

Also, the core logic of the calculation likely doesn’t need a huge rewrite; the only real change is replacing the hardcoded 1 in 1/chance with a variable.

Examples

So with chance_numerator=3 and chance=4, you get a probability of 3/4, or 75%.

If you only specify chance=4, the probability is 1/4, or 25%, because chance_numerator defaults to 1. This suggestion is thus backwards-compatible.

Implementation draft

The implementation could go something like this:

First, draw a random integer between 1 and chance. Second, check if that integer is equal to or smaller than chance_numerator. If yes, run the associated action.

For ABMs, I am unsure about how (and if) the behavior of catch_up should change (since it does something with chance).

Applying the suggestion to item drops

Item drops have a rarity argument which is also a 1-in-X chance. Thus, item drop tables could be extended with a rarity_numerator argument which is analog to chance_numerator which I described above.

Alternatives

I can’t think of any. I think this idea is simple enough.

Additional context

No response