Matrix Games Forums

I have been playing the game for a while now and did not really notice this phenomenon until this point.

I am currently at the "Showpieces" scenario of the Chains of War campaign, and REALLY starting to get annoyed how may missiles does it take to down a single enemy aircraft.

Take a look at the below expenditures table:

SIDE: China
===========================================================

LOSSES:
-------------------------------
2x J-10A Firebird
3x J-15 Flying Shark [Su-33 Copy]


EXPENDITURES:
------------------
6x AA-12 Adder A [R-77, RVV-AE]
31x Generic Active Directional Sonobuoy
31x Generic Chaff Salvo [4x Cartridges]
93x Generic Passive Directional Sonobuoy
6x PL-12



SIDE: JTF Wahoo
===========================================================

LOSSES:
-------------------------------


EXPENDITURES:
------------------
32x AIM-120D AMRAAM P3I.4
1x AN/ALE-70 FOTD
2x Generic Chaff Salvo [5x Cartridges]


According to this, it took more than 6 (!!!) AMRAAM D-s to shoot down a SINGLE enemy aircraft. And this is from a missile with a base hit probability of 95%! Also I always made sure that Iam not taking any "range penalty" when firing, so the final PH was about 75%.

Another thing I noticed, that the game always rolled in the lows when checking against chaffs and DECM, and went overboard with high numbers when determining whether the missile hit or not. I think at least half of my missiles got "spoofed" due to this. Something which shouldnt happen.

Might be confirmation bias (and also, the reference pool is not very big either) but holy hell is it frustrating when you depart with three F-35B-s armed with 12 AMRAAMs and you return to base with one solitary kill..

If it comes to odds, I can only count to potato, so cant really say what are to exact chances of hitting after 20% chaff, 10% DECM and 75% final hit PH, but I am pretty sure its not 16% (i.e. 6+ missiles/plane).

Am I the only one experiencing this, is this WAD, or just confirmation bias on my part?

Thanks,

Save?

It would be interesting to see the message log entries for this.

I worked on a game a long time ago and we were getting unlikely results far too often. While I can't say it's true in this case I can tell you that random number generators in software can have problems. Good random number generation for applications where it is truly important rely on a hardware component specifically designed for the purpose like an atomic decay counter, etc...

I really don't think it's caused by RNG but by other parameters in the code (that can be complex).
RNGs functions coming with C++ or any other off the shelf programming language are over tested. They give results always simulating true randomness. They can be statistically tested, and they will always pass the test.

Years ago there was a bug in core lua code that effected how random random number generators were. I think it was before CMO was even around.

https://www.matrixgames.com/forums/view ... 3#p3629723

thewood1 wrote: Mon May 09, 2022 12:50 am Years ago there was a bug in core lua code that effected how random random number generators were. I think it was before CMO was even around.

https://www.matrixgames.com/forums/view ... 3#p3629723

The problem in that example was the use of non-integers as parameters when calling the math.random() function. From the Lua 5.3 reference:

math.random ([m [, n]])
When called without arguments, returns a pseudo-random float with uniform distribution in the range [0,1). When called with two integers m and n, math.random returns a pseudo-random integer with uniform distribution in the range [m, n]. (The value n-m cannot be negative and must fit in a Lua integer.) The call math.random(n) is equivalent to math.random(1,n).

This function is an interface to the underling pseudo-random generator function provided by C.

FWIW, if you need a function that returns a random number between two non-integer numbers, try something like this (b-a must be positive):
R

My point wasn't that you couldn't do it. My point is that there that have been bugs in RNGs before. C++ had one years ago in one of its RAND functions.

thewood1 wrote: Mon May 09, 2022 9:02 am My point wasn't that you couldn't do it. My point is that there that have been bugs in RNGs before. C++ had one years ago in one of its RAND functions.

Understood and agreed. There have indeed been bugs in RNGs before. The link that you provided, however, was an example of not using the math.random() function correctly versus illustrating an inherent bug in the random number generator.

I was just showing one method of accomplishing what the programmer had intended. nukkxx5058's point is well-taken: the issue seen is probably not due to the RNG "but by other parameters in the code (that can be complex)".

Running the scenario multiple times and analyzing the distribution of the results may help determine whether there was an issue with the RNG.

R