-
-
Notifications
You must be signed in to change notification settings - Fork 6
Dev Maths
LSML shows a lot of statistically derived values and for most weapons these are straight forward. However for the Ultra AC/5 and LB 10-X AC and Machine Gun there are a few caveats.
The UAC/5 can fire twice in a cool down period. But each such double-shot runs the chance of jamming the gun for a time. The maximum and sustained DPS values shown for the UAC/5 are statistically expected values when using double firing on every shot (i.e. button down firing).
However, the Burst DPS value will show how much damage you can expect the UAC/5 to put out in a specific time interval, and if the interval is low then the burst will be higher than the max expected DPS.
We calculate the statistical rate of fire like this:
Define:
P_jam := probability that weapon will jam when double fired.
CD := cool down, or more specifically, time between shots
(including fast fire if applicable).
JT := jammed time, if the weapon jams, it is unavailable for this time.
Assume the user tries to double fire 'k' times. The amount of time
it will take is:
T = k*P_jam*(CD + JT) + k*(1 - P_jam)*CD
And the number of rounds fired is:
F = k*P_jam + k*(1 - P_jam)*2
ROF = T / F = ... = (P_jam*JT + CD) / (2 - P_jam)
Functions the same as LB 10-X (below).
The LB 10-X AC fires bullets in a cone. Although each bullet has a very long range, the effective range of the weapon is much shorter due to the spread.
In LSML all damage statistics are conditioned on range and the damage values for LB 10-X AC will take the spread into account in the damage. Because of this, the alpha/DPS/burst values may differ from other tools that do not take the spread into account.
You can easily see the falloff on range by adding a LB 10-X AC to a loadout with an engine and opening the damage graph.
The data files contains a spread value which has no documented meaning. After much research we have come to the conclusion that the spread value is the standard deviation on the spread in degrees of a normal distribution with mean 0. By assuming a target area as a circular area with radius 6 meters we can statistically calculate how many bullets will hit this target area and derive the damage.
As a reference, an atlas is reported around 16 meters tall and judging from for example this image then the ratio of height to width is ~1.3 so that would make the atlas about 12 meters wide, or you could inscribe a circle of radius 6 meters in the torso area.
So the damage is calculated for that size, when shooting at a smaller target the actual damage will of course be lower.
maxAngle = arctan(targetRadius, range) * 180 / pi
angle ~ N(0, spread)
P_hit = P( -maxAngle <= angle; angle <= +maxAngle)
X = (angle - 0) / spread ~ N(0,1)
-> P_hit = CDF(maxAngle/spread) - CDF(-maxAngle/spread)
-> P_hit = 2*CDF(maxangle/spread) - 1
Where CDF is the Cummulative Distribution Function for
standard normal distribution: N(0,1).
The RAC has two wind up/down mechanics, one for the bullets them selves and one for the "jam bar". It also has a spread which is computed the same way as other ballistic bullet spreads.
When the trigger is first pulled, then the weapon ramp up and jam bar ramp up start simultaneously. Once the weapon ramp is complete projectiles start to be fired. Once the jam bar ramps up fully, each round has a chance to jam the weapon.
When the trigger is released, a grace period of RampDownDelay seconds starts, after which the weapon ramp down starts. If during the grace period the trigger is pulled again then the weapon fires again and the grace period is reset. If during the ramp down, the trigger is pulled again, a partial ramp up based on linear portion that was already "ramped down" occurs.
It is unclear if the jam bar ramp down begins on trigger release or after the grace period; However based on YouTube videos I've reviewed I think that the jam bar ramp down starts after the grace period. This is sensible as otherwise one could game the system by letting the jam bar recover briefly during the grace period and then shoot again without jam chance and ramp up, essentially trading a low percentage peak dps drop for immunity to jam chance but only doable with FCS software essentially giving those players a significant, unfair advantage.
If the weapon jams, then the weapon is unavailable for JammedTime during which time the grace period and jam and weapon ramp downs will proceed as if the trigger was forcefully released.
Attributes (RAC/2):
rampUpTime="0.75"
rampDownTime="2.0"
jamRampUpTime="8.0"
jamRampDownTime="10.0"
RampDownDelay="0.3"
JammingChance="0.037"
JammedTime="10"
Before we can analyse the expected rate of fire we need to decide on which strategy to use for dealing with jam probability.
The strategy is to never jam by waiting out the full jam ramp down until and then firing until the jam bar fills up.
This means that RoF * (jamRampUpTime - rampUpTime) shots will be fired during a period of jamRampUpTime + RampDownDelay + jamRampDownTime. This assumes jamRampDownTime >= rampDownTime and jamRampUpTime >= rampUpTime which is reasonable (otherwise the weapon would be mostly useless) and true for all RAC weapons at the point of writing.
Giving an effective rate of fire of: RoF * (jamRampUpTime - rampUpTime) / (jamRampUpTime + RampDownDelay + jamRampDownTime).
I don't think this strategy is possible (any more) as I think that the jam ramp down starts after the grace period. But if it the jam ramps down during the grace period one can pulse the trigger so that jam bar never red-lines but the weapon ramp down is never started. So the during the RampDownDelay seconds grace period the jam bar will recover RampDownDelay/jamRampDownTime% which allows us to shoot for RampDownDelay * jamRampUpTime / jamRampDownTime seconds.
This gives a total period of: RampDownDelay * (1 + jamRampUpTime / jamRampDownTime) seconds and RoF * RampDownDelay * jamRampUpTime / jamRampDownTime shots fired. Which results in an effective rate of fire of: RoF * jamRampUpTime / (jamRampDownTime + jamRampUpTime).
However, I think this strategy is not possible and even if it was it would require using a FCS software which we don't want to assume every one has. However it would be significantly higher than the normal Never Jam strategy.
Exactly what it says on the tin.
The firing period will be jamRampUpTime + expectedNonJammedTime + max(RampDownDelay + jamRampDownTime, JammedTime) and the number of shots fired will be RoF * (jamRampUpTime - rampUpTime + expectedNonJammedTime) giving a total effective rate of fire of:
RoF * (jamRampUpTime - rampUpTime + expectedNonJammedTime) / (jamRampUpTime + expectedNonJammedTime + max(RampDownDelay + jamRampDownTime, JammedTime))
The shots during red line jam bar individually have JammingChance chance of jamming, thus the probability of jamming after firing exactly k shots is (1 - JammingChance)^(k) * JammingChance.
So we have: expectedShots = sum(k=0, inf, k*(1 - JammingChance)^(k) * JammingChance) and thus expectedNonJamedTime = expectedShots / RoF.
Comparing to the effective RoF of Never Jam:
RoF * (jamRampUpTime - rampUpTime) / (jamRampUpTime + RampDownDelay + jamRampDownTime).
=> RoF * (jamRampUpTime - rampUpTime + expectedNonJammedTime) / (jamRampUpTime + expectedNonJammedTime + max(RampDownDelay + jamRampDownTime, JammedTime)) >= RoF * (jamRampUpTime - rampUpTime) / (jamRampUpTime + RampDownDelay + jamRampDownTime)
expectedNonJammedTime >= ((jamRampUpTime - rampUpTime) * (max(RampDownDelay + jamRampDownTime, JammedTime) - RampDownDelay - jamRampDownTime)) / (RampDownDelay + jamRampDownTime + rampUpTime)