Stored damage references differ from evaluated ranges
For a distance-dependent damage shell, ShellParams.avgMutableDamage returns the descriptor's armorDamage pair unchanged. Despite the getter's name, it does not average the entries, evaluate a distance or construct a randomized hit range. The shell tooltip has a separate row and distance-footnote path for this representation.
VehicleParams.maxMutableDamage and minMutableDamage instead use the active shot's shell to evaluate damage at a selected distance, then apply the provider's damage-distribution bounds and integer rounding. The first uses its first reference distance; the second uses the smaller of the shot's maximum distance and its last reference distance. The vehicle average-parameter tooltip selects these two evaluated ranges for mutable damage. These getter names identify configured samples, not measured global extrema or server hit outcomes. Nonmutable shells leave these fields unavailable.
With supplied reference damage (200, 100), reference distances 50/500, a maximum distance of 275 and randomization 0.2 with neutral distribution adjustments, selected original functions returned the stored pair (200, 100) and evaluated ranges (160, 240) and (120, 180). These are synthetic calculation checks with inert descriptors and modifier constants; actual configurations, provider construction, native operations, tooltip rendering and the client Python 2 runtime were not exercised.
Critical-hit chance is a category in this provider
ShellParams.criticalHitChance classifies the resolved shot shell's chanceToHitByProjectileModifier relative to one. It returns STANDARD at one, INCREASED above one and DECREASED below one for ordinary finite inputs. The queried shell must pass the provider's armor-piercing-type gate and a shot must resolve; otherwise this field is unavailable.
The enum's codes are STANDARD=1, DECREASED=2 and INCREASED=3. They are category identifiers, not percentages or a numeric ranking of chance. The dedicated formatter selects the corresponding localized label. A number-typed value is therefore insufficient reason to apply percentage formatting or ordinary numeric sorting.
Different modifiers can collapse to one category. Synthetic modifiers 0.7 and 0.9 both selected DECREASED; 1.1 and 1.8 both selected INCREASED. The additional shell-row path compares the resulting parameter values, so it cannot recover the original modifier difference from equal categories. These checks used selected original getter/formatter code with inert lookup, resource and translation adapters. Actual catalogs, shell configurations, critical-hit probability, native damage processing and client rendering were not exercised.
A shield coefficient row does not enable shield traversal
ShellParams.screensArmorMultiplier returns the integer shared shield-cost coefficient for a HIGH_EXPLOSIVE shell with MODERN mechanics, and otherwise returns None. It uses the first resolved shot's shell type when available, falling back to the queried shell's type. The getter does not inspect shieldPenetration.
The shell tooltip separately controls row visibility and wraps the value with localized text and a footnote. The Armor Inspector layer model also attaches its reduction-factor label when the selected packet is modern HE and the material is spaced armor. Neither displayed coefficient establishes that the penetration traversal's flag is enabled.
The Armor Inspector penetration calculation checks shieldPenetration > 0 inside its HE branch before subtracting the shield cost; its other branch sets remaining penetration to zero. The battle marker has its own shield-penetration gate and traversal rules. Preserve these consumer checks rather than using the presence of a garage row or layer label as permission.
Source inspection and selected original getter checks with inert shell types established the differing gates. They did not establish a stock configuration with contradictory UI, a rendered tooltip, collision outcomes, native physics or server penetration rules.
Preserve uncertainty and UI limits
Configured DPM is a provider-dependent rate times selected average damage, not a simulation of a player's firing sequence. Effective-speed formulas are descriptor estimates, not slope/steering/server physics. Simplified garage ratings combine several values and should not be presented as direct physical quantities.
Keep detailed breakdown work off navigation constructors, defer/coalesce refreshes and cache by full context. Reacquire rebuilt descriptor/mechanic objects rather than retaining an old parameter reference. Decompiled control-flow omissions can make active mechanics appear removed; verify a suspicious branch against stronger evidence before declaring a client defect.
See vehicle representations, staged model delivery and decompiled-source verification.