Ver 6.0

Flow Core 6.0 replaces manually maintained central extension-registration lists with assembly-local compiler bindings. Supported extensions become available after compilation, while first use and configurable background prewarm decide when registration support becomes ready.

Automatic registration and independent extensions

• Supported Instructions, Conditions, Drawers, Enums, and Blackboard types travel with their implementations and required helpers. Importing or removing a supported source extension updates its bindings on compilation.
• Editor registration state is maintained in memory. Normal operation does not write a central registry C# asset or require a manual registry-generation step.
• Player uses compiled bindings for its target without globally scanning loaded assemblies for extension types.
• Existing supported registration APIs and stable type/serialization identities remain available. Explicit manual registrations retain precedence over automatic defaults.

Follow Automatic Registration & Prewarm for source, assembly, dependency, and precompiled-DLL boundaries. Deleting an extension still requires resolving references from your own code and authored graphs.

Prepare upcoming content before gameplay

All Available is the default: configured Graphs, modules, and entries are prioritized before the remaining available bindings. Specified prepares that selected scope and dependencies. On Demand leaves preparation to actual use or explicit requests.

Editor preferences are personal, with a default soft budget of 1.5 ms per update. Player policy is shared project configuration, with a default of 0.25 ms per frame. Both queues work across frames on the main thread. First use can immediately prepare an unready binding and its dependencies.

The budget cannot interrupt an indivisible registration operation. Prewarm does not instantiate gameplay, construct every UI, load all resources, or execute Graphs. A broader prepared scope can retain more caches, and changing policy does not unload existing caches. Use the application’s menu time to prepare upcoming content and measure the actual memory and first-use tradeoff.

Generator remains an implementation and diagnostic tool

Use Generator to create or update implementation helpers such as wrappers, Drawers, resolvers, and serializers. Supported source types no longer require a separate central-list rebuild merely to become registered.

The Registry Generator includes Registration Directory, Validate Available Bindings, and Rebuild Directory Cache. Validation checks availability and conflicts across Editor updates without activating every entry; a cache rebuild does not repair missing implementations or project compiler errors.

Retired compatibility entry points

The twelve historical generated group classes below have been removed. External code or DLLs that directly referenced them must migrate to supported registration APIs and compatible compiler providers; do not recreate empty replacement shells.

Historical namespace	Removed class
TwoCatsCode.FlowCore.Bi.CT.G.Editor	GeneratedBlackboardValueDrawerRegistryGroup_fc98afae
TwoCatsCode.FlowCore.Bi.CT.G.Editor	GeneratedEditorBlackboardValueSerializerRegistryGroup_fc98afae
TwoCatsCode.FlowCore.Bi.CT.G.Runtime	GeneratedBlackboardValueSerializerRegistryGroup_fc98afae
TwoCatsCode.FlowCore.Bi.D.Editor	GeneratedConditionDataDrawerRegistryGroup_ff46b717
TwoCatsCode.FlowCore.Bi.D.Editor	GeneratedFlowFieldDrawerRegistryGroup_ff46b717
TwoCatsCode.FlowCore.Bi.D.Editor	GeneratedInstructionDataDrawerRegistryGroup_ff46b717
TwoCatsCode.FlowCore.Bi.E.G.Editor	GeneratedEditorBlackboardValueSerializerRegistryGroup_8c56c9b9
TwoCatsCode.FlowCore.Bi.E.G.Runtime	GeneratedBlackboardValueSerializerRegistryGroup_8c56c9b9
TwoCatsCode.FlowCore.Bi.R.C.G.Editor	GeneratedEditorConditionRegistryGroup_6a8ac687
TwoCatsCode.FlowCore.Bi.R.C.G.Runtime	GeneratedConditionRegistryGroup_6a8ac687
TwoCatsCode.FlowCore.Bi.R.I.G.Editor	GeneratedEditorInstructionRegistryGroup_d19092f5
TwoCatsCode.FlowCore.Bi.R.I.G.Runtime	GeneratedInstructionRegistryGroup_d19092f5

These retired generated types are distinct from the supported public registration facades. Do not delete every registry, generated implementation, or serializer file in a project.

Upgrade an existing project

1. Back up or commit the project and inventory custom extensions, generated outputs, and direct references to retired classes.
2. Import 6.0 with its compiler support and assembly structure intact. Unity asset-package imports can leave files that the newer package no longer contains; review and remove only the obsolete generated groups superseded by this update. Preserve custom implementations and their dependencies.
3. Resolve compiler errors and migrate external references to the twelve retired entry points. Precompiled integrations need compatible bindings or a supported adapter.
4. Review Personal > Diagnostics > Registration and Project Shared > Runtime > Registration in Flow Core Settings. Existing settings use All Available when no explicit strategy was stored.
5. Run directory validation, check the expected pickers and typed data paths, then exercise current graphs with domain reload enabled and disabled.
6. Rebuild and actually run the intended Player targets, including IL2CPP and stripping settings used for delivery. Editor availability alone does not prove Player compatibility.

This registration change preserves existing graph data and historical serialization readers. It does not automatically replace a graph’s references to an extension that you removed.

Domain reload and Unity Visual Scripting

Flow Core does not require Unity’s Visual Scripting package. In a Unity 6000.6.5f1 development-project comparison, removing an unused com.unity.visualscripting package removed a 16.52 s reset callback. Scene integration fell from 17.15 s to 0.55 s, and the whole profiled Play entry from 29.58 s to 14.02 s. An unprofiled follow-up logged approximately 0.43 s for initial scene integration.

This is a project-specific package-removal case, not a universal 6.0 speedup claim. Unity reload and Editor windows still contributed to the remaining delay. Audit your own package dependencies before removal, and distinguish Unity Visual Scripting from other products such as Game Creator. See Troubleshooting Slow Play Mode Entry for the sampling procedure and limitations.

Related

• Automatic Registration & Prewarm
• Personal & Project Settings
• Troubleshooting Slow Play Mode Entry
• Ver 5.3