Class BootClockGuard
- Namespace
- GrindFest
- Assembly
- GrindFest.dll
Remembers what the game clock was when the session started, says so loudly when it was stopped, and puts it back so the rest of the session is usable.
public static class BootClockGuard
- Inheritance
-
objectBootClockGuard
Remarks
Why this exists: measured 2026-09-16, a player build booted with Time.timeScale 0 because
ProjectSettings/TimeManager.asset had been committed with m_TimeScale: 0. A player serialises that
value; the editor ignores it (play mode runs at 1 whatever the asset says), so the editor was green, the
whole DevTest suite passed, and the only symptom was a build that sat on the logo screen forever - the
world load lived in a DOTween callback, and DOTween runs on scaled time. Nothing in managed code ever
wrote that zero, which is what made it expensive to find: it was never 1 to begin with.
What this does NOT do is hide the cause. The error is the deliverable: it names the setting and the fix, in
the log of any build, editor or player. ProjectClockBuildGuard stops such a build from being made at
all, and UILoadingScene no longer gates the boot on scaled time, so a stopped clock can no longer
wedge anything - it just gets reported and repaired.
Properties
- BootTimeScale
Time.timeScaleas this session found it, before anything here touched it. For anyone who needs to know what the build was actually configured to start with (a test, a report, a support log).