Suppression formula at n=1: where does the 5‰ discrepancy come from?

[FreddoSoprano]

Hi all,
I'm working on a deployment-optimization tool for myself and trying to reproduce exactly what the combat log shows (with setany randomness 0). I've nailed down the kill formula but I'm stuck on a tiny discrepancy in suppression that I can't explain, even on the simplest possible case.

Setup: a single Pz IIIB shoots once at a full T-26. The log says:
Base Number of Shots: 1
Effective Accuracy: 50%
Deflect/Suppress/Kill chances: 30% / 20% / 50%
Prediction: 0.250000 killed, 0.104808 suppressed

The kill prediction matches what I expect: 0.50 (accuracy) × 0.50 (kill chance) = 0.25. Clean.

For suppression, my reasoning is the same: 0.50 × 0.20 = 0.10. So I'd expect exactly 0.100000. But the log gives 0.104808 — a small but very real and reproducible 5‰ excess.

Where does that 0.0048 come from? It's too large to be a rounding artifact (the log displays 6 decimals deliberately) and too small to come from any "panic bonus per kill" mechanism I can think of (a single shot produces at most 1 kill, with 25% probability — and any naive multiplication doesn't land on 0.0048 either).

Anyone here who has investigated the suppression formula and could shed some light on this? Even a hint about the general shape of the calculation would unblock me massively.

Thanks!

[FreddoSoprano]

Update: I've narrowed down the suppression formula and found something curious that goes beyond the original question.
Same setup (Wehrmacht infantry attacking a Soviet Regular squad in open terrain, setany randomness 0, setany weather clear). I held the defender at HP=5 and varied the attacker's HP from 13 to 16. Combat log predictions for suppression:

13 attacker HP : 0.815 suppressed
14 attacker HP : 0.541 suppressed
15 attacker HP : 0.568 suppressed
16 attacker HP : 0.594 suppressed

Going from 13 to 14 shots, suppression drops by 33%, then slowly recovers as more shots are added. This non-monotonic behavior is hard to explain with a continuous probabilistic formula — adding shots should never reduce suppression, at worst the extra shots have zero effect.

Possible explanations I can think of :

There's a threshold-based branch in the suppression code that activates above some E[K]/HP ratio, producing a discontinuity in this regime
There's an unintended side-effect in the formula at near-saturation
This is intended behavior modeling some tactical concept I'm not seeing

Anyone has insight into how the suppression formula handles near-saturation cases? Happy to provide more datapoints. Saves available on request.

[scorehouse]

curious how your utilize the Hero that gives 3% Suppression to all Adjacent Units? and what other Heroes complement/enhance its effectiveness? thanks

[armedevil]

@FreddoSoprano If I'm right, the combat algorithm repeats over all available attack-points one after the other. For every hit (suppress or kill), it selects one of the targets' available pre-combat strength points (active or suppressed) where 'double' hits on the same defending strength point can occur. So the weaker the target gets, the more of these duplicated hits will inevitably occur. It becomes mathematically impossible that all hits score separately.

At 100% randomness, it ends with the random attack outcome, but with randomness zero, the expectation of the outcome (this expectation might be inaccurate, as the calculation is complex!), rounded, becomes the final result. Everything from 0.5 to 1.49999 translates to 1 and so on.

With randomness > 0% and < 100%, the outcome is some kind of proportional mix of 100% and 0% randomness. A flaw is that the algorithm stops prematurely when all the defending points are killed. But then, the mix is still applied. So sometimes it becomes literally impossible to kill the target outright, even with total luck!

As the attacker attack points increase, the expected number of kills should also go up (to 5). Expected Kills + expected Suppresses cannot exceed the number of defenders, so expected Suppresses have to go to zero.

But I still cannot reconstruct the exact algorithm.