Debug and Maintain Projects
Troubleshooting Slow Play Mode Entry
Separate domain reload, third-party initialization, scene loading, and registration prewarm when Play Mode stalls.
- Audience
- All developers
- Time
- 10 minutes
- Requires
- Flow Core 6.0 or later and a reproducible Play Mode delay
- Modules
- Flow Core
On this page
Locate the work that blocks entering Play before changing prewarm settings. A long pause at the Play button can occur before Flow Core’s normal frame-sliced queue gets an opportunity to run. Use the same scene and Enter Play Mode settings for a meaningful comparison.
Recognize the phase
| Observation | Check first |
|---|---|
| A long pause only with domain reload enabled | Assembly/static initialization, reload callbacks, third-party packages, and Editor windows. |
| A long scene initialization before Awake | Scene integration and scene-loaded callbacks, including package initialization. |
| One expensive frame after gameplay begins | Cold first use, an indivisible binding, Graph construction, resources, and other scripts. |
| Player startup differs from the Editor | The actual Player path; Editor windows and domain-reload work are absent there. |
| Returning to Edit Mode feels faster | The exit path performs different work; it does not establish that entry initialization is frame-sliced. |
Domain reload recreates managed state and runs initialization callbacks. Unity controls this transition; Flow Core cannot distribute every package’s static initializer or Unity’s own reload across gameplay frames. Disabling domain reload can shorten iteration, but it changes lifecycle behavior and requires testing the project’s other systems.
Capture a useful comparison
- Note Unity version, scene, domain/scene reload settings, prewarm modes, and open Editor windows. Preserve unsaved work before changing any test state.
- Capture ordinary CPU profiling with Editor samples across entering Play. Start with Deep Profiling off to limit measurement overhead.
- Inspect
EnterPlayMode, reload, scene integration, callbacks before Awake, and the first gameplay frames separately. Parent timings include children; do not add them together. - Inspect the expensive child call rather than assuming every registration-related name belongs to Flow Core.
- Repeat without Profiler, using the same scene and settings. Compare Editor logs where available and separately run a Player build.
- Restore the original settings and windows. Record what changed and what was actually measured.
Opening and repainting diagnostic windows can add work to a profile. Close unneeded windows for a second comparison, and identify tool overhead before attributing it to gameplay.
A Unity Visual Scripting case
In one development project using Unity 6000.6.5f1, with domain reload and scene reload enabled, the dominant scene-loaded initialization was this callback:
Unity.VisualScripting.RuntimeCodebase.ResetStaticsOnLoadAfter confirming the project did not depend on Unity Visual Scripting, removing com.unity.visualscripting produced this same-scene comparison:
| Ordinary Profiler scope | Before removal | After removal |
|---|---|---|
Whole EnterPlayMode | 29.58 s | 14.02 s |
| Scene integration | 17.15 s | 0.55 s |
| Visual Scripting reset callback | 16.52 s | Absent |
An additional unprofiled run logged initial scene integration at approximately 0.43 s. The original multi-second scene-initialization stall was removed, while the complete Editor transition still included substantial reload and window-initialization cost.
These are one profiled before/after comparison and one unprofiled follow-up from a particular project, not a general performance guarantee. They do not show that every Unity Visual Scripting installation has the same bottleneck, or that Flow Core’s registry update alone caused the timing improvement. The tested package removal was a separate change.
Check dependencies before removing a package
Flow Core does not require Unity’s Visual Scripting package. Before removing it from your project, inspect source and assembly references, scenes, prefabs, Script Graph or State Graph assets, serialized components, and third-party integrations. Keep a version-control recovery point, then compile and test the actual Editor and Player workflows after removal.
The name Visual Scripting can also appear in other products. Game Creator’s visual-scripting implementation is separate from Unity’s com.unity.visualscripting package. Do not remove unrelated third-party code because its folder or namespace uses that phrase.
Check Flow Core preparation separately
Flow Core 6.0 uses compiled bindings in Player and maintains Editor registration state in memory. It does not repeatedly write a central registry C# asset. Its normal background preparation is frame-sliced on the main thread, but an individual binding and synchronous first use can exceed the soft budget.
Use Automatic Registration & Prewarm to prioritize upcoming Graphs, modules, or entries while the application remains in a menu. Measure the first actual prewarm update separately from domain reload, Graph construction, asset loading, and instruction execution.
A faster Player does not prove that its scan scope is merely smaller. It runs a different initialization path with compiled providers and without Editor reload or window repaint. Compare the measured call paths.