# FQualityLevels: Strict == operator given lossy float serialization?

**URL:** <https://forums.unrealengine.com/t/fqualitylevels-strict-operator-given-lossy-float-serialization/2745311>\
**Category:** Programming & Scripting\
**Tags:** unreal-engine, UE5, CPP, question\
**Created:** [August 20, 2026, 3:14pm UTC](https://forums.unrealengine.com/t/fqualitylevels-strict-operator-given-lossy-float-serialization/2745311 "2026-08-20T15:14:39Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![ubi\_herbertyanes](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@ubi\_herbertyanes](https://forums.unrealengine.com/u/ubi_herbertyanes)\
**Post date:** [August 20, 2026, 3:14pm UTC](https://forums.unrealengine.com/t/fqualitylevels-strict-operator-given-lossy-float-serialization/2745311/1 "2026-08-20T15:14:40Z")

</div>

`Scalability::FQualityLevels` relies on strict equality for its members during comparisons. However, `ResolutionQuality` is stored as a standard `float`. When the engine serializes this state to disk via `GConfig->SetFloat` (inside `SaveState`) and subsequently parses it back during `LoadState` using `FCString::Atof`, it introduces subtle precision drift.

We were relying on this comparison for one of our metrics to determine if the user’s current `ScalabilityQuality` was the same as the auto-detected quality.

I fixed it on our side, but I was unsure if this behavior is considered an issue or if our approach simply fell outside the intended use case for the operator.

---

<div class="post-metadata">

**Author:** ![ubi\_herbertyanes](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@ubi\_herbertyanes](https://forums.unrealengine.com/u/ubi_herbertyanes)\
**Post date:** [August 24, 2026, 11:41pm UTC](https://forums.unrealengine.com/t/fqualitylevels-strict-operator-given-lossy-float-serialization/2745311/2 "2026-08-24T23:41:13Z")

</div>

After closer inspection it does seem that the actual drift in the value was not introduced by the serialization itself but the way the values of CVar are set which essentially truncates the float to 6 significant figures which is then serialized introducing a drift between the serialized value and the benchmarked value we also store.