Table of Contents

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
object
BootClockGuard

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.timeScale as 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).