What every record must include
- Game name, identifier and slug.
- Game version and the supported mode. The initial model covers hip-fire only.
- A yaw parameter with explicit units: degrees per count at sensitivity 1.
- Supported sensitivity minimum and maximum values.
- Whether DPI, eDPI and cm/360 are supported by the loaded model.
- Source label, URL, source type and access date for every parameter.
- The date the record was checked.
- Known limitations, including mode or version caveats.
- Source and update metadata for the record.
Data standard
Every record uses the same shape: a game identifier, a supported mode, a yaw value, sensitivity bounds, step and source metadata. Records with missing or invalid yaw are excluded from the converter.
The runtime validation layer enforces record shape, positive yaw, valid bounds and approval metadata before a record can be loaded.
What is not included
- Values that conflict across sources without a documented resolution.
- Values inferred from a different game, engine or mode.
- ADS, scope or FOV multipliers that have not been separately implemented and tested.
About the current coverage
The loaded records come from public game-data sources and embedded calculator data. Some yaw values were missing or outside a basic sanity range; those records were excluded. Where bounds were unavailable, the runtime uses a broad fallback and labels the limitation.
The conversion methodology explains how a loaded record is used and what the model deliberately leaves out. The sensitivity conversion guide explains how yaw and input behavior affect a converted value.
Last reviewed: 2 November 2026