49 replies to this topic

[Nightbird]

ShiverMeRivets, on 28 September 2018 - 12:15 AM, said:

It seems that guns somehow affect each other. The way to test this is to do 68 experments with a single gun and compare the jam chances to the theoretical values.

Give it a try and let us know! I suspect it'll be around 17%, and the bug is only present when groups of guns are fired and the jam chances rolled simultaneously.

[B L O O D W I T C H]

Nightbird, on 27 September 2018 - 02:09 PM, said:

Testing done on testing grounds... if anyone wants to do the test in live, please go ahead.

With the 8 C-UAC/2 build, each with a 17% chance of Jamming on a double tap, we expect to see on a double tap with all 8 guns:

0 Jams 22.5% of the time
1 Jams 36.9% of the time
2 Jams 26.5% of the time
3 Jams 10.8% of the time
4 Jams 2.8% of the time
5 Jams 0.5% of the time
6 Jams <0.01% of the time
7 Jams <0.01% of the time
8 Jams <0.01% of the time

In this experiment, I double tapped, record the number of Jams, waited for all weapons to unjam, and repeated.

I saw the following after 68 double taps:
0 Jams 42 times (61.7%)
1 Jams 7 times (10.3%)
2 Jams 1 times (1.5%)
3 Jams 7 times (10.3%)
4 Jams 11 times (16.2%)
Rest 0 times

Even if the sample size is small, the number of 0 Jams is far too high, as is the number of 4 Jams. The occurrence of 1, 2 Jams are also too low. The probability of encountering this extreme a finding when the Jam chance code is performing correctly is <0.0001, therefore the chance of a bug present is >99.99%

Please feel free to repeat this experiment to confirm the percent of Jams occurring is off.

The sample size is probably not big enough, it's still a good indicator, tho.

So, you had all cannons in one group, fired once and then fired twice within the doubletap window?
When did you doubletap? I recall hearing that, the later you doubletap, the less likely a cannon is pron to jam.

Also worth mentioning, training ground runs localy, livegames are on a server. I've had games on server where one tap counted as a doubletab resulting in insta jams (the infamous "ghost" double tap bug).

Are those numbers you posted maybe duo to uacs acting differently when used on liveservers with latency and hsr?

I recall octa uac2 boats firing in 4+4, or in chainfire macro, that might take some stress off of the uac doubletap, is this worth taking into account?
On a live game, each additional doubletap comes with another chance to jam, so overclicking with not 100% firing dicipline amplifies the jam chance.

Edited by Toha Heavy Industries, 28 September 2018 - 06:27 AM.

[LordNothing]

i kind of think the 8uac2 build is a little too hot to be practical. i currently do 8 cac2s, but ive seen 8lb2 or a mix of 4lb2 and 4uac2 work out well. i think more emphasis needs to be placed on more sane builds like tripple 5s, dual 10s, quad 2s. and single 20s.

[El Bandito]

Nightbird, on 28 September 2018 - 04:30 AM, said:

Do the experiment then, you have an UV

I did the experiment and the result was completely different. Just like you, I double tapped everything once and recorded each instance, one difference being I double tapped a total of 100 times. Out of 100 tries:

0 Jams 8 times (8%)
1 Jams 63 times (63%) gun 2nd from top jammed 14 times alone, and gun 6th from top jammed 21 times alone (combined those two guns are responsible for 55% of all single jams!)
2 Jams 29 times (29%)
3 Jams 0 times (0%)
4 Jams 0 times (0%)




If I learned anything, it's that everyone experiences different jam %, and I will sell gun #2 and gun #6.

Edited by El Bandito, 28 September 2018 - 08:43 AM.

[RJF Volkodav]

It also looks like jam chances depend on double tap speed. Suggestion of time dependent group jam chances are interesting taking into account well known fact for example that UAC MCII-B will have less jams if you fire doubletaps separately for each arm than full quad in a time.

[MischiefSC]

Nightbird, on 27 September 2018 - 02:09 PM, said:

Testing done on testing grounds... if anyone wants to do the test in live, please go ahead.

With the 8 C-UAC/2 build, each with a 17% chance of Jamming on a double tap, we expect to see on a double tap with all 8 guns:

0 Jams 22.5% of the time
1 Jams 36.9% of the time
2 Jams 26.5% of the time
3 Jams 10.8% of the time
4 Jams 2.8% of the time
5 Jams 0.5% of the time
6 Jams <0.01% of the time
7 Jams <0.01% of the time
8 Jams <0.01% of the time

In this experiment, I double tapped, record the number of Jams, waited for all weapons to unjam, and repeated.

I saw the following after 68 double taps:
0 Jams 42 times (61.7%)
1 Jams 7 times (10.3%)
2 Jams 1 times (1.5%)
3 Jams 7 times (10.3%)
4 Jams 11 times (16.2%)
Rest 0 times

Even if the sample size is small, the number of 0 Jams is far too high, as is the number of 4 Jams. The occurrence of 1, 2 Jams are also too low. The probability of encountering this extreme a finding when the Jam chance code is performing correctly is <0.0001, therefore the chance of a bug present is >99.99%

Please feel free to repeat this experiment to confirm the percent of Jams occurring is off.

68 is a big enough sample size to shake out outliers.

This looks distinctly like a bad RNG design. It would be a mistake to operate from the assumption that the jam chance is an actually accurate mathematical model. It may be (and likely is) skewed around repeated double-taps. It may not register all double-taps. It's possible that some people tap more quickly than others.

@Nightbird,

did you tap twice on your own or use a macro?

How about you, Bandito?

[Tier5 Kerensky]

I might do some testing, just need to change LBX2 into UAC2 and those 14 tons of ammo, too.

[El Bandito]

MischiefSC, on 28 September 2018 - 08:54 AM, said:

did you tap twice on your own or use a macro?

How about you, Bandito?

I tapped twice on my own.

[B L O O D W I T C H]

Teer Kerensky, on 28 September 2018 - 08:57 AM, said:

I might do some testing, just need to change LBX2 into UAC2 and those 14 tons of ammo, too.

Just in chance you did not know (which i doubt), you don't need to buy the uac2s if you don't want to. Just enter testing grounds out of the mechlab mech stats tab. You can also toss armor and shovel 25 tons of ammo in. without changing your existing build.

Just getting into testing and with a super accurate sample size of 10 shots i get this



Appearently AC nr 1 jams 50% of all times and contributes 38,5% of all jams, AC nr 2 never jams.
Obviously not to take serious.

Edited by Toha Heavy Industries, 28 September 2018 - 09:40 AM.

[LordNothing]

this thread looks too much like analyzing the randomness of a random number generator.

Edited by LordNothing, 28 September 2018 - 10:29 AM.

[RJF Volkodav]

There is a science field called mathematical statistics. It clearly states what is "chance" and how it behaves in big numbers. What we see in MWO is surely not adequate random generation of jam chance.

[K O Z A K]

For sure there is a PGI developer somewhere laughing their a** off at all the testing and theories on the jam chance knowing all too well it's totally RNG

[RickySpanish]

Tiny sample size is tiny. OP works in medicine R&D? Big whoop. In my line of work it isn't a sure thing until it has been tested 5 billion times, and that's the bare minimum. You can quite conceivably have patterns like this develop over a small run.

[Nightbird]

El Bandito, on 28 September 2018 - 08:39 AM, said:

I did the experiment and the result was completely different. Just like you, I double tapped everything once and recorded each instance, one difference being I double tapped a total of 100 times. Out of 100 tries:

0 Jams 8 times (8%)
1 Jams 63 times (63%) gun 2nd from top jammed 14 times alone, and gun 6th from top jammed 21 times alone (combined those two guns are responsible for 55% of all single jams!)
2 Jams 29 times (29%)
3 Jams 0 times (0%)
4 Jams 0 times (0%)




If I learned anything, it's that everyone experiences different jam %, and I will sell gun #2 and gun #6.

Interesting, guess I will test in live and let the team carry me. At least on testing grounds, it is the same clear evidence that the jam mechanics is borked. There is no way the distribution of jams is THAT off from the theoretical. For example, the odds of 0 3 or 4 Jams after 100 tries when it should occur 13.6% of the time is <.0000001%.

What it does show though is that the is consistently wrong for the user, depending on some things on the user's end. CPU? Windows version? Things that shouldn't affect the calculation but does.

I tried another test on my end on testing grounds, same results as my previous and nothing like yours.

RickySpanish, on 28 September 2018 - 10:55 AM, said:

Tiny sample size is tiny. OP works in medicine R&D? Big whoop. In my line of work it isn't a sure thing until it has been tested 5 billion times, and that's the bare minimum. You can quite conceivably have patterns like this develop over a small run.

Learn stats

Edited by Nightbird, 28 September 2018 - 01:55 PM.

[Nightbird]

Tested on live server, FP Sulfurous Rift defense

I saw the following after 70 double taps:
0 Jams 36 times (51.4%)
1 Jams 8 times (11.4%)
2 Jams 3 times (4.3%)
3 Jams 13 times (18.6%)
4 Jams 9 times (12.9%)
Rest 0 times

Distribution of jams still completely screwed up compared to if the code was working correctly. I also think the code for jamming is client side, not server side, since the response for jam or no jam is instaneous. There's not the delay that damage takes to register.

[Y E O N N E]

Nightbird, on 28 September 2018 - 07:03 PM, said:

I also think the code for jamming is client side, not server side, since the response for jam or no jam is instaneous. There's not the delay that damage takes to register.

Damage also has to resolve position and velocity deltas before it registers, a jam does not. If it was client-side, you'd think there would have been UAC jam chance hacks running rampant at some point in the game's history.

But, all speculation.

[Nightbird]

Yeonne Greene, on 28 September 2018 - 07:06 PM, said:

Damage also has to resolve position and velocity deltas before it registers, a jam does not. If it was client-side, you'd think there would have been UAC jam chance hacks running rampant at some point in the game's history.

But, all speculation.

If you have 100ms ping, it will take at least 200ms (assuming 0 computation time) for damage or jam chance to register. For jamming, there is clearly no delay from trigger pull to either bullets flying or jam message.

[Quicksilver Aberration]

Nightbird, on 28 September 2018 - 07:22 PM, said:

If you have 100ms ping, it will take at least 200ms (assuming 0 computation time) for damage or jam chance to register. For jamming, there is clearly no delay from trigger pull to either bullets flying or jam message.

They could be doing the RNG ahead of time (since you should have to fire once to even enter a state where you could jam) and each shot has RNG rolled for the UAC so that the client can know ahead of time whether it is going to jam and the server just recognizes that it was fired and matches state with it. Not that it is likely since that could be prone to exploits as well but just saying it is a possibility.

Edited by Quicksilver Kalasa, 28 September 2018 - 07:34 PM.

[Y E O N N E]

Nightbird, on 28 September 2018 - 07:22 PM, said:

If you have 100ms ping, it will take at least 200ms (assuming 0 computation time) for damage or jam chance to register. For jamming, there is clearly no delay from trigger pull to either bullets flying or jam message.

That assumes no predictive algorithms.

That some people get jams even with the trigger held depressed (there's a video of that floating around here somewhere) tells me that it's not client-side.

[MischiefSC]

Hazeclaw, on 28 September 2018 - 10:45 AM, said:

For sure there is a PGI developer somewhere laughing their a** off at all the testing and theories on the jam chance knowing all too well it's totally RNG

Except it's not. The jam chance isn't a random number between 1 and infinity - and, to be clear I'm going to put this in bold print and big font, not because I'm trying to yell or be a dbag at you but because it's important to keep in mind for WHY we want to test this stuff:

No computer we have today can generate a truly random number.

Beyond that jam chance isn't random - it's a set percentage. 17%, to be precise. Or, at least, we're told it's 17%. The distribution isn't actually a 17% distribution - that's the point. So it's not 17%, or it's 17% after a certain criteria is met. That's the point.

A) It's not a random number, no computer can generate a random number and

B ) it shouldn't be random at all. It should be 17%. It's not 17%, that's the issue.

So we need to test it because if it's broken it needs fixed.

Quicksilver Kalasa, on 28 September 2018 - 07:34 PM, said:

They could be doing the RNG ahead of time (since you should have to fire once to even enter a state where you could jam) and each shot has RNG rolled for the UAC so that the client can know ahead of time whether it is going to jam and the server just recognizes that it was fired and matches state with it. Not that it is likely since that could be prone to exploits as well but just saying it is a possibility.

That's what I was thinking. It could be some sort of cumulative algorithm that applies a failed jam test to the next trigger pull.

Nightbird/El Bandito -

Do either of you use 2x weapon groups? Was it all the guns on one weapon group with a manual double-pull on the trigger?

Edited by MischiefSC, 28 September 2018 - 07:46 PM.