FAQ for smooth first play.

PSO Autopilot is an Unreal Engine plugin that prepares startup content before gameplay so first-play shader and texture costs happen under a controlled loading screen instead of during interactive play.

It focuses on three practical goals: memory-safe batch loading, smooth loading-screen updates, and smart repeat launches when a previous warmup already matches the current content set.

Many UE projects hitch the first time a player reaches heavy content because shaders, PSOs, textures, and package dependencies are being touched for the first time. PSO Autopilot shifts that work into a startup preparation phase.

The goal is not to hide every possible runtime hitch. The goal is to make common first-run startup costs predictable, visible, and less disruptive.

No. Large projects benefit from the memory-safe batching, but smaller projects can also benefit from fewer first-play stutters and a cleaner startup flow. The presets let you choose how conservative or aggressive the warmup should be.

It drives Unreal's native shader and PSO preparation path by loading selected content, gathering materials and primitive data, and requesting PSO precache work. The work is time-sliced so the loading screen can keep updating.

No plugin can guarantee that. Runtime stutters can come from streaming, spawning, physics, animation, IO, Niagara, plugin code, driver behavior, or content that was never included in the warmup set.

PSO Autopilot reduces a specific and common class of startup and first-play hitches by preparing the content you target.

Use the Fab listing for the product page and the Discord server for support, setup questions, and troubleshooting.

1. Copy the PSOAutopilot folder into your project's Plugins folder.
2. Regenerate project files if your project uses C++.
3. Compile the project.
4. Open the editor and enable the plugin if Unreal prompts you.

Open Unreal Engine and choose Window > PSO Autopilot Startup Setup. The wizard provides a One-Click Simple Setup flow to guide your configuration. It features a Project-Aware Preflight Validator that scans your active project, generates an Automatic Readiness Card with color-coded results, and provides instant inline Fix buttons for safe items.

• Game Level: the map players should reach after preparation finishes.
• Loading Screen: your widget class, or the wizard-created editable default at /Game/PSOAutopilot/WBP_PSOAutopilotLoadingScreen.
• Content to Prepare: folders that contain startup-critical assets.
• Quality Preset: Safe Startup, Balanced, or Fast Warmup.
• Skip When Already Prepared: enabled for normal production startup.
• Prepare Textures Early: enabled when first-frame texture pop-in matters.
• Editor Iteration Mode: use Unreal's editor compilation for daily PIE work, or run the full PSO Autopilot warmup when you want to validate the loading flow inside editor preview.

It creates or opens the default loading level, places or updates a PSO Autopilot Loader actor, sets the loading level as the project startup map, and applies the selected simple setup choices.

Current builds default Editor Iteration Mode to Use Unreal Editor Compilation. In PIE, Editor, Editor Preview, and Game Preview worlds, PSO Autopilot completes immediately before starting its warmup path so Unreal can use the normal editor shader compilation behavior.

This does not disable packaged builds. Switch Editor Iteration Mode to Run PSO Autopilot Warmup, use Standalone Game, launch with -game, or make a Development package when you want to validate the complete startup warmup.

The validator generates an Automatic Readiness Card by scanning your game level, loading level, loading widget, content folders, cook settings, package preload paths, boot map separation, batch size, ignored content types, and whether the startup loader is present. You can resolve issues instantly using the provided inline Fix buttons.

No. Simple Setup writes a beginner-friendly settings snapshot that feeds the same runtime subsystem. Advanced Mode exposes the lower-level controls for teams that need more precise targeting and tuning.

Balanced is the recommended default. Safe Startup lowers risk for large or memory-sensitive projects by using more conservative batch behavior. Fast Warmup spends more frame time during loading and is best for smaller projects with comfortable memory headroom.

No. The wizard can create an editable default Widget Blueprint at /Game/PSOAutopilot/WBP_PSOAutopilotLoadingScreen, parented to the native UPSOAutopilotLoadingScreenWidget. Customize that asset for branding, or provide your own UMG widget and drive it from the progress delegate or the one-node loading flow.

Loading everything at once can spike memory and freeze the loading screen. PSO Autopilot loads a controlled number of content items, prepares them, releases references, and optionally forces garbage collection before the next batch.

The subsystem spends only a configured amount of game-thread time per frame on preparation work. The default advanced budget is 5.0 ms, and presets adjust this for safer or faster behavior.

It uses standard Unreal Engine APIs such as FStreamableManager, the Asset Registry, material PSO precache APIs, texture streaming controls, package loading, and garbage collection.

Player-facing messages are intentionally plain: finding startup assets, checking previous warmup, loading assets in safe batches, preparing shaders, preloading gameplay map, and ready.

Technical status is available separately through Get Technical Status Message and the optional telemetry panel.

The built-in loader can release retained preload references and open the gameplay level. Custom flows can bind to On Startup Preparation Complete and decide what to do next.

Yes. The subsystem exposes Stop Preparing Startup Content through Blueprint and StopWarmup() in C++. It resets state, releases loaded content, and broadcasts completion.

Start with the destination gameplay map, startup characters, weapons, UI materials, VFX that appear immediately, common environment assets, and folders that hold first-play content.

For small projects, scanning /Game can be acceptable, but targeted folders are safer and faster. For larger projects, target the folders and explicit assets needed for startup. Broad scans increase startup work and can include content players will not see for a long time.

Do not add /Game to Additional Asset Directories to Cook or DirectoriesToAlwaysCook unless you intentionally want Unreal to cook the whole project. The setup wizard now avoids adding that root cook entry and can remove it when the validator finds it.

Explicit assets are specific maps, blueprints, materials, or other objects you want prepared even if they are not found by folder scanning. They are useful for soft-referenced systems and important startup assets.

It expands the warmup set by following package dependencies from selected roots. This helps catch materials and assets reachable through maps, actor blueprints, component templates, primary asset labels, and soft references.

Depth 1 is a practical default for many projects. Increase it when important startup assets are several references away. Reduce it if the warmup set becomes too broad.

Call RegisterRuntimeWarmupAsset(...) before starting the warmup. This is useful for selected characters, cosmetics, loadout assets, modular content, or boot flows that decide content at runtime.

Yes. Advanced Mode includes content types to ignore. Use this when a scan picks up unnecessary or unstable object types that should not be loaded during startup preparation.

Common causes are blank folder entries, invalid package paths, missing cook settings, scanning an empty folder, or relying on content that is only reachable through references while dependency expansion is disabled.

Run the setup validator first. Then check that folder paths use Unreal package paths such as /Game/Characters, not Windows paths.

Call Start PSO Autopilot Loading Flow. Set the gameplay level, optional loading widget, and options. The node registers the gameplay level, queues package preload, shows the widget, starts preparation, releases retained preload, and opens the gameplay level.

1. Open a lightweight loading level first.
2. Get the PSO Autopilot Subsystem from the Game Instance.
3. Bind On Progress Updated to your loading bar and status text.
4. Register any runtime-selected content.
5. Call Start Preparing Startup Content.
6. On completion, travel to the gameplay map.

Bind On Startup Preparation Progress for progress and status text. Bind On Startup Preparation Complete for travel, menu reveal, or other handoff behavior.

UPSOAutopilotSubsystem is the runtime core. It is a Game Instance subsystem and a tickable object, so it can run across the loading flow and report progress every frame.

APSOAutopilotBootLoader is a production-friendly actor for loading levels. It can apply simple setup settings, show the loading widget, register gameplay level content, queue package preload, start warmup, and open the destination level when ready.

Yes. Run PSO Autopilot after you know the startup content set. Register dynamic assets first, start warmup, and continue your own flow on completion.

The main controls are Items Per Step, content targeting, dependency depth, and Clean Memory Between Steps. Smaller batches and cleanup between batches reduce peak memory at the cost of more startup time.

Frame Time Budget (ms) controls how much preparation work happens per frame. Lower values protect UI smoothness. Higher values finish faster but can make animations or videos less smooth on slower machines.

Large projects can have thousands of assets and massive dependency graphs. Loading everything at once can produce RAM spikes, frozen UI, and out-of-memory crashes. PSO Autopilot's core value is doing this work in safer steps.

Use Safe Startup, keep content targeting focused, keep dependency depth low, and leave cleanup between batches enabled. Test on the lowest-memory hardware you intend to support.

Reduce the content set, lower dependency depth, disable unnecessary texture preheat, or move from Safe Startup to Balanced or Fast Warmup. Make sure Smart Skip is enabled for repeat launches.

Lower the frame time budget, reduce items per step, use Safe Startup, and check whether your own loading screen is doing heavy work. If video playback is involved, validate on target hardware.

Yes. The pipeline includes recovery behavior for stalled batch loading, fingerprint work, texture streaming, and package preload cases so a single bad item is less likely to stall startup forever.

Smart Cache Skip checks whether the current startup content fingerprint has already completed on the local machine. If it matches, PSO Autopilot skips the asset warmup and continues immediately.

Matched cache runs also bypass demo minimum-duration holds. This remains true after an Unreal restart even if the engine reports a temporary fresh-process pipeline-cache backlog.

The fingerprint is based on the engine context, selected content, scan configuration, and asset information. When the startup set changes, the fingerprint changes and a fresh warmup is expected.

The first launch prepares content and records completion. A later launch with the same fingerprint can skip preparation because the previous run already completed successfully. If a run finishes with asset-load or package-preload warnings, the fingerprint is intentionally not stored.

Disable Skip When Already Prepared or call Clear Smart Skip History. The demo overlay also supports cold-vs-cached validation flows.

Yes. The completion history stores multiple completed fingerprints so different startup paths do not have to overwrite one another immediately.

No. Drivers, engine changes, settings, and platform behavior can still affect cache state. Smart Skip means PSO Autopilot has a matching completed record for the selected startup configuration.

It asks Unreal to keep relevant UTexture2D mips resident for a period during startup preparation. This can reduce blurry textures when gameplay starts.

Yes. Advanced settings include standard texture readiness and virtual texture readiness. The plugin tracks virtual-textured UTexture2D resources and waits for pending init or streaming where applicable.

The content may not be included in the warmup set, the streaming pool may be too small, the material may be introduced after startup, or the platform may need more time to stream higher mips.

Yes. Keeping high-resolution mips resident uses memory. Disable it or narrow content targeting if startup memory becomes too high.

Yes. Package validation has covered Win64 editor, development game, and shipping game plugin builds. For your project, always validate the exact target platform and configuration you intend to ship.

Include the loading level and the destination gameplay level. If you use the demo, include /Game/Demo/Demo_BootFlow and /Game/Demo/Demo_PSOTorture.

Cook the loading level, gameplay level, and the targeted folders that contain startup content you expect to prepare. The setup validator can add recommended cook directories for common simple setup cases.

Avoid +DirectoriesToAlwaysCook=(Path="/Game") unless your intent is to cook the entire project. That root entry can make packaging look like it drops normal reference-based cooking and recooks everything. Current wizard fixes use specific folders and can remove the stale root entry.

Check whether /Game was added to Additional Asset Directories to Cook or to DirectoriesToAlwaysCook in config. A root cook directory tells Unreal to always include all project content.

Run the setup validator and use the Remove /Game fix if it appears. Then add only the loading map, gameplay map, and startup-critical folders such as /Game/Demo, /Game/DemoMaterials, or your real content folders.

Fab packages should use a clean plugin folder with descriptor metadata, source, resources, docs, and platform binaries generated by Unreal's BuildPlugin workflow. Engine-version-specific packages should be stamped for the target engine version.

Use the Fab listing for the buyer-facing product page.

The plugin uses standard Unreal APIs and the descriptor lists Win64, Mac, Linux, Android, and iOS. Package and playtest each platform because shader, texture, memory, and driver behavior can differ by target.

Use Development with logs while validating setup and demo telemetry. Use Shipping when validating the production loader path and final player experience.

Debug symbols are useful for development and support, but final distribution rules depend on your marketplace and build policy. Keep a symbol build available for diagnosing crashes even if the public package excludes symbols.

• Boot map: /Game/Demo/Demo_BootFlow
• Loading screen: /Game/Demo/UI/WBP_LoadingScreen
• Gameplay map: /Game/Demo/Demo_PSOTorture
• Gameplay overlay: /Game/Demo/UI/BP_PSOAutopilot_HUD
• Stress content: /Game/DemoMaterials

The demo warms startup assets, preloads the gameplay map during the loading screen, releases the retained preload before travel, opens the gameplay map, and then shows a cached run that can skip duplicate preparation.

1. Set GameDefaultMap to /Game/Demo/Demo_BootFlow.
2. Add the demo boot map and gameplay map to packaged maps.
3. Always cook /Game/Demo and /Game/DemoMaterials.
4. Run once for a cold pass.
5. Run again for a cached pass.

Yes. Run Unreal with Scripts/CreatePSOAutopilotDemo.py through -ExecutePythonScript.

Run the validator, check logs for batch load, package preload, texture streaming, and fingerprint timeout warnings, and confirm the destination map exists on disk and is cooked.

Check for blank folder entries, invalid package paths, folders with no cookable content, disabled dependency expansion, or content that only exists through runtime selection and was never registered.

Use Safe Startup, reduce items per step, narrow content folders, lower dependency depth, leave cleanup between steps enabled, and disable texture preheat if texture memory is the problem.

Lower the frame time budget, reduce batch size, simplify the loading widget, and validate in a packaged build. Editor behavior is useful for setup but not always representative of shipping startup.

Disable Skip When Already Prepared or call Clear Smart Skip History. For demo validation, use a cold pass followed by a cached pass.

The content set or settings may change every launch, the previous warmup may have completed with warnings, Skip When Already Prepared may be disabled, or the completion record may have been cleared.

Also check loader/demo debug flags. Re-running the setup wizard clears stale simple-setup demo overrides such as forced fingerprint resets on existing loader actors.

For packaging, remove any stale DirectoriesToAlwaysCook=(Path="/Game") entry so Unreal does not cook the entire project. For runtime warmup, make sure Skip When Already Prepared is enabled and no loader is resetting the smart-skip fingerprint on begin play.

Current builds skip matched cached warmups immediately after restart, even when a fresh editor process reports a pipeline-cache backlog.

Older setup data could point at the native C++ fallback widget instead of a project-owned UMG asset. The widget can still appear in Play because the C++ fallback generates UI at runtime, but there is nothing editable in your content folder.

Run the setup wizard and use the loading-widget fix or Create/Update Startup Flow. Current builds create and assign /Game/PSOAutopilot/WBP_PSOAutopilotLoadingScreen, an editable Widget Blueprint parented to UPSOAutopilotLoadingScreenWidget.

Current builds throttle active PSO precache requests during time-sliced batch processing so very large material sets do not flood the renderer with unchecked background work. If renderer instability persists, lower the item count per step, narrow content folders, and test in a Development packaged build with logs.

Verify the gameplay level package path, add the map to packaged maps, ensure the map is cooked, and confirm the loading level is different from the gameplay level.

Check that the package path is valid, cooked, and not blocked by missing dependencies. Large maps may need content targeting or platform IO checks before preload completes reliably.

No. The timeout logs a warning and proceeds so startup is not trapped forever by a texture that never reports completion. Investigate streaming pool size, missing mips, virtual texture settings, and target hardware.

Packaged builds depend on cook settings and staged content. Confirm maps and warmup folders are cooked, run a Development packaged build with logs, and compare the asset counts and package paths against editor output.

Use the package built for your engine version. Unreal Engine APIs and exported symbols can differ between releases, so Fab packages should be validated per target engine version.

Include the Unreal log from a Development packaged run, the setup validator messages, your plugin version, engine version, target platform, selected preset, startup maps, warmup folders, and the last visible status message.

Join the Discord support server for setup questions, bug reports, and project-specific troubleshooting.

• Unreal Engine version and target platform.
• Plugin version and whether the package came from Fab.
• Preset, batch size, frame time budget, and smart-skip setting.
• Loading map, gameplay map, warmup folders, and explicit assets.
• Development packaged logs when the issue appears outside the editor.

The Fab product page is here: PSO Autopilot on Fab.

Use the setup wizard, run validation, apply safe fixes, package a Development build with logs, launch once for a cold run, then launch again to confirm Smart Skip behavior.