pluginv2.0Blueprint only

ParallelFlow

The Blueprint performance toolkit. Stay in Blueprint. Stop the lag.

The missing performance layer for Blueprint developers. When your Blueprint starts to lag, you are usually told to rewrite it in C++. ParallelFlow is the alternative: replace a few slow Blueprint nodes with optimized native equivalents and your game runs smooth again. No threads, no async, no C++.

Download full guide Get it on Fab

Engine support: Unreal Engine 5.2
Version: 2.0
Backends: Not applicable

What you get

Drop-in native replacements for the Blueprint patterns that actually hitch
Parallel sort, filter, map, reduce, find and count across CPU cores
Frame-spreading loops for your own per-element Blueprint logic
Async files, JSON, CSV, compression, hashing and AES-256 encryption
Spatial math: heatmaps, noise, Voronoi, closest actor, batched line of sight
A Performance Advisor that tells you honestly when NOT to optimize
Live task debugger plus runtime stat nodes and console commands

Introduction

Welcome to ParallelFlow, the missing performance layer for Blueprint. When your Blueprint starts to lag, you are usually told to rewrite it in C++. ParallelFlow is the alternative. Replace a few slow Blueprint nodes with optimized native equivalents and your game runs smooth again, with no threads, no async and no C++.

The mission

If a Blueprint developer asks how do I optimize this, the answer should almost always be that ParallelFlow has a node for that. You never think about threads, workers or schedulers. You think: my Blueprint is lagging, so I replace a few nodes, and my game is smooth.

How to read this manual

New here? Read the Blueprint Optimization Guide first, since it teaches you how to think about Blueprint performance. Then use the Quick Start to make your first optimization in five minutes.
Have a specific game system to speed up? Jump to the Blueprint Performance Cookbook and find your recipe.
Want the details of a node? See the API reference.

Three things to remember

01The Advisor is your friend. Not sure whether to optimize? Drop in the Advise node with your element count. It gives an honest answer, including keep using normal Blueprint when your data is small.
02Measure, do not guess. The Benchmark nodes and Benchmark Map prove the gain on your own hardware.
03Small data stays simple. ParallelFlow is for when things get big.

The Blueprint optimization guide

This chapter teaches you how to think about Blueprint performance. Read it once and you will know when to reach for ParallelFlow, and when not to.

Why Blueprint slows down

Blueprint is not slow because it is interpreted. It is slow in specific, predictable situations:

01Big loops. A ForEach over 100,000 items runs every node in the loop body 100,000 times, one after another, on the Game Thread. Nothing else, including rendering, input and the rest of your game, happens until that loop finishes.
02Nested loops. A loop inside a loop is multiplication: 1,000 x 1,000 equals 1,000,000 iterations. This is where why did my game freeze for a second comes from.
03Per-frame heavy work. A moderately expensive loop is fine once. On Tick, every frame, it becomes a permanent frame-rate tax.
04Blocking operations. Saving a big file, parsing a large data table, hashing. These stop the world while they run.

None of these are Blueprint fault, exactly. They would be slow in single-threaded C++ too. The difference is that a C++ programmer knows to move them off the Game Thread or across CPU cores. ParallelFlow does that for you.

Understanding the Game Thread

Your game has one Game Thread that runs gameplay, Blueprint and ticks, and it has to finish all of that in roughly 16 ms to hit 60 FPS. Meanwhile your CPU has 8, 12, 16 or more cores mostly sitting idle.

A Blueprint loop uses one core, the Game Thread, and blocks everything else on it.
A ParallelFlow node uses the idle cores, and hands the result back to the Game Thread when done, so your frame never stalls.

That is the whole trick. You do not need to understand threads to benefit from them. You just need to stop doing heavy work on the one thread that cannot afford it.

What ParallelFlow actually does

Runs the heavy part, meaning the sort, the search, the distance math, as native C++ across multiple cores.
Keeps your Blueprint logic on the Game Thread, where it is safe. You get the results back in a normal Blueprint event.
Chooses worker count, chunk size, and small-versus-large strategy automatically. There is nothing to configure.

What ParallelFlow does NOT do

It does not run your Blueprint graph on other threads. That would crash any engine, because the Blueprint VM is not thread-safe. ParallelFlow runs native operations in parallel and returns to Blueprint for the logic.
It does not claim to beat well-written custom C++. It gives you production-quality native code so you do not have to write that C++ yourself.
It does not help small data. Sorting 50 items is already instant, and parallelizing it is pure overhead. The Advisor will tell you so.

The optimization workflow

01Measure, do not guess. Use the profiler (stat unit, stat game) or just notice the hitch. Find the loop that is actually slow.
02Ask the Advisor. Drop in Advise (Performance Advisor) with the operation and element count. It gives you an honest call.
03Swap the node. Replace the Blueprint pattern with the ParallelFlow node from the Blueprint Replacement Guide.
04Prove it. Run the matching Benchmark node, or open the Benchmark Map, to see the real gain on your hardware.
05Move on. Do not optimize what is not slow. ParallelFlow is a scalpel, not a coat of paint.

Rules of thumb

Under a few thousand elements: keep normal Blueprint.
Tens of thousands and up: ParallelFlow starts to clearly win.
Hundreds of thousands, or anything on Tick: you should almost certainly be using ParallelFlow.
Inherently heavy work such as heatmaps, noise, file I/O and many line traces: use ParallelFlow regardless of count, because Blueprint has no good answer for these.

The mindset shift

Before ParallelFlow, the answer to my Blueprint is too slow was rewrite it in C++. That is a wall a lot of Blueprint developers hit and never get past. ParallelFlow moves that wall much further out. You stay in Blueprint, designing, iterating and shipping, and reach for a ParallelFlow node the moment something gets heavy. You will write custom C++ later, and less of it, and only where it truly matters.

Installation guide

Requirements

Unreal Engine 5.2
Windows, Mac, Linux, Android or iOS target platforms (runtime module)
No third-party dependencies. ParallelFlow uses only engine Runtime modules: Core, CoreUObject, Engine, Json and ImageWrapper.

Installing from Fab

01Purchase or claim ParallelFlow on Fab.
02In the Epic Games Launcher, open Unreal Engine Library, find ParallelFlow under Fab Library and click Install to Engine for 5.2.
03Open your project, go to Edit > Plugins, search for ParallelFlow, tick Enabled and restart the editor.

Installing into a single project (source)

01Close the editor.
02Copy the ParallelFlow folder into your project Plugins directory, creating it if needed.
03Right-click your .uproject and choose Generate Visual Studio project files for C++ projects, or just open the project and the editor offers to compile the plugin.
04Confirm the plugin is enabled under Edit > Plugins > Performance > ParallelFlow.

YourProject/
  Plugins/
    ParallelFlow/
      ParallelFlow.uplugin
      Source/...

Verifying the installation

In any Blueprint, right-click and search for Parallel Sort. You should see the ParallelFlow nodes.
Open Window > Developer Tools > ParallelFlow Debugger. The task monitor should appear.
In the console, run ParallelFlow.DumpTasks. The scheduler logs its state.

Packaging

The ParallelFlow runtime module is packaged automatically with your game. The editor module, which is the debug window, is editor-only and never ships. No additional packaging settings are required.

Uninstalling

Disable the plugin in Edit > Plugins, or delete the Plugins/ParallelFlow folder. Blueprints using ParallelFlow nodes will report missing nodes afterwards, so remove those nodes first if you plan to keep the Blueprints.

Quick start guide

Five minutes from install to your first background task.

1. Your first background task

In any Blueprint, for example the Level Blueprint:

01Event BeginPlay into Run Background Task with Iterations set to 50,000,000.
02Drag off Started into Print String with the text Task started.
03Drag off Progress into Print String, appending the Progress float.
04Drag off Completed into Print String, appending Elapsed Ms.

Press Play. The workload takes real CPU time, the progress prints stream in, and your frame rate never dips, because the work runs on a background worker thread.

2. Sorting half a million floats

01Generate Random Floats (Async) with Count 500000, Min 0 and Max 1000.
02From its Completed (Results) into Parallel Sort (Float).
03From the sort Completed, print Elapsed Ms and the Results length.

Compare with a Blueprint for-loop sort of the same data. ParallelFlow finishes in milliseconds on worker threads while a Blueprint loop would freeze the game for minutes.

3. Progress bars

Every node Progress pin delivers 0.0 to 1.0 on the Game Thread, throttled to roughly 30 updates per second.

Create a UMG widget with a Progress Bar.
Bind the bar Percent to a float variable.
In the graph, set that variable from the node Progress event.

4. Cancellation

Two equivalent options:

Store the Task Handle from Started, then call Cancel Task (ParallelFlow Async Flow) whenever you want, for example from a UI button.
Or drag from the node Task output pin and call Cancel on it directly.

The task stops at its next safe point and the Cancelled pin fires. Threads are never force-terminated.

5. Task groups (Wait For All)

01Start three tasks, for example three Run Background Task nodes, and collect their Task Handles into an array.
02Feed the array into Wait For All Tasks.
03Its Completed fires once every task reached a terminal state, which is perfect for loading phases.

Wait For Any Task completes as soon as the first one finishes instead.

6. Spreading Blueprint work across frames

Blueprint bodies can only run on the Game Thread, so for per-element Blueprint logic use the frame-spreading loops:

Async Loop, with First Index, Last Index and Iterations Per Frame.
Async For Each (Indices), where you wire Loop Body Index into your array Get.
Async Sequence, one step per frame for staged init.
Async Repeat and Async While, which are interval-driven loops. End them with Break Loop, which fires Completed, or Cancel, which fires Cancelled.

Rule of thumb: built-in heavy math goes to Parallel Arrays nodes on worker threads. Custom Blueprint logic per element goes to Async Loop, which is frame-spread.

7. Async files

Async Save (Text) and Async Load (Text) for save-game text, logs and configs.
Async JSON Read and Write for validated JSON with pretty printing.
CSV Import to parse huge spreadsheets into rows without a hitch.
Compress File and Hash File to archive and fingerprint files in the background.

Relative paths resolve against your project directory.

8. Watch everything live

Open Window > Developer Tools > ParallelFlow Debugger:

Active Tasks: state, priority, live progress, execution time and worker thread.
Finished Tasks: newest first, with timings and error messages.
Stat tiles: running and queued counts, average and last execution time, worker count, CPU estimate and process memory.
Cancel All Tasks and Clear History buttons.

At runtime, including packaged builds, use the Blueprint nodes Get Scheduler Stats, Get Active Tasks and Get Task History, or the console commands ParallelFlow.DumpTasks and ParallelFlow.CancelAll.

Blueprint replacement guide

The mission: if a Blueprint developer asks how do I optimize this, the answer should almost always be that ParallelFlow has a node for that.

This is the lookup table. Find the slow Blueprint pattern you have on the left, then use the ParallelFlow node on the right. The Performance Advisor node will confirm whether it is worth it for your element count.

Your slow Blueprint pattern	Replace with	Typical gain
Sort node or manual sort on a big array	Parallel Sort (Float/Int/Vector/String)	~2-5x
ForEach + Branch + Add to build a filtered list	Parallel Filter	~3-6x
ForEach + Branch scanning until you find an item	Parallel Find / Parallel Search	~3-8x
ForEach accumulating a running total / min / max	Parallel Reduce	~4-8x
ForEach that rewrites or scales every element	Parallel Map	~3-6x
ForEach + Distance for every point	Distance Calculator	~3-6x
ForEach tracking the smallest distance (closest enemy)	Closest Actor / Nearest Point	~3-6x
ForEach + Line Trace for many targets	Visibility Processing	huge (async traces)
Nested loops splatting points into a grid	Heatmap Generator	impractical in Blueprint otherwise
Nested loops sampling noise per cell	Noise Generator	impractical in Blueprint otherwise
A ForEach that hitches the frame because it does too much at once	Async Loop (spreads it across frames)	no hitch
Save/Load Game that freezes on big saves	Async Save / Load	removes the freeze
Parsing a big data table or spreadsheet	CSV Import / Async JSON Read	off the Game Thread
Building a save checksum or verifying a download	Hash File / Checksum	streamed, off-thread
Shrinking screenshots or textures on disk	Image Resize	off the Game Thread

Gains are rough and scale with CPU cores and data size. ParallelFlow never claims to beat well-written custom C++. It gives you production-quality native code without writing any.

How to use this table

01Notice a Blueprint that lags, hitches, or shows up hot in the profiler.
02Find its pattern above.
03Drop in the Advise (Performance Advisor) node with your operation and element count. It tells you if the swap is worth it at your scale.
04If yes, replace the pattern with the ParallelFlow node. Wire Completed to what used to come after your loop.
05Optionally run the matching Benchmark node to see the exact gain on your hardware.

The honest part

ParallelFlow will tell you not to bother when your data is small. Sorting 20 items? The Advisor says keep using Blueprint, because the setup cost of going parallel would outweigh the microseconds you would save. The plugin optimizes you and teaches you where the real bottlenecks are.

The Blueprint performance cookbook

Real game systems, real bottlenecks, real fixes. Each recipe follows the same shape so you can scan for your problem: the problem, the slow Blueprint, the ParallelFlow fix, why it is faster, the expected gain, common mistakes, and when NOT to use it.

A rule that runs through every recipe: small data means keep normal Blueprint. When you are unsure, drop in the Advise node with your element count and it will tell you honestly. ParallelFlow is a scalpel, not a coat of paint.

1. Leaderboard / scoreboard

Step	Detail
Problem	End of match: sort 50,000 player scores for a ranked board. The Blueprint Sort, or a manual loop, runs on the Game Thread and the screen freezes for a beat right when players want their result.
The slow Blueprint	Get All Scores into Sort (descending) on the Game Thread, or worse a manual bubble or insertion sort with nested loops.
The ParallelFlow fix	Parallel Sort (Float) or (Int), Ascending = false, into Completed, then build the board UI. Wire Progress to a spinner.
Why it is faster	A parallel merge sort spreads the work across CPU cores instead of one, and it runs off the Game Thread so the frame never stalls.
Expected gain	~2-5x on the sort itself, and more importantly zero hitch on the frame that shows results.
Common mistakes	Sorting the full player struct array by copying it repeatedly. Instead sort a parallel array of scores, or score plus index, and reorder once at the end.
When NOT to use it	A 12-player lobby. 12 items sort in microseconds, so use normal Blueprint.

2. Inventory and loot

Step	Detail
Problem	A survival or ARPG inventory with thousands of items needs sorting by value, weight or rarity, and filtering such as show only weapons in range of my level.
The slow Blueprint	ForEach over the inventory with a Branch per item building a new filtered array, then a Sort. Two passes on the Game Thread.
The ParallelFlow fix	Sort with Parallel Sort. Filter with Parallel Filter (Int/Float) on the numeric key such as value, weight or item level. For items within a stat range, use Parallel Filter with Min and Max.
Why it is faster	Filtering and sorting are the two things Blueprint loops do slowest at scale, and both are natively parallelized here.
Expected gain	~3-6x on filter, ~2-5x on sort, and no frame hitch when opening the bag.
Common mistakes	Re-filtering every frame while the inventory UI is open. Filter once on open or on change, then cache the result.
When NOT to use it	A 30-slot inventory. Normal Blueprint is instant.

3. Crafting: can I craft this, across a big recipe book

Step	Detail
Problem	Thousands of recipes. On every inventory change you re-check which recipes are now craftable.
The slow Blueprint	Nested loops: for each recipe, for each ingredient, search the inventory. That is recipes x ingredients x inventory, a classic frame-killer.
The ParallelFlow fix	Precompute an ingredient-count map once. Then use Parallel Count (Int) or Parallel Filter to evaluate the recipe list in one native pass. For do I have N of item X, use Parallel Count over the inventory ids.
Why it is faster	You collapse nested Blueprint loops into native parallel passes and kill the multiplication.
Expected gain	From a noticeable hitch on pickup to imperceptible. Often 5x or more because you also removed the nesting.
Common mistakes	Recomputing the whole craftable set on every item pickup. Debounce: recompute at end of frame, not per item.
When NOT to use it	A dozen recipes. Keep it in Blueprint.

4. Quest system: objective checks at scale

Step	Detail
Problem	Open-world game with hundreds of active and inactive quests, each with conditions evaluated against world state.
The slow Blueprint	A ForEach over all quests on Tick evaluating conditions.
The ParallelFlow fix	Do not evaluate on Tick. Use Async Loop, spread across frames, to walk the quest list a few per frame, or Parallel Filter to find quests whose numeric trigger is met in one pass, then evaluate only those in Blueprint.
Why it is faster	You stop doing all the work in one frame. The heavy scan is native and the Blueprint logic only touches the handful that matter.
Expected gain	Eliminates the per-frame quest tax entirely.
Common mistakes	Evaluating string-heavy conditions in the parallel pass. Reduce to numeric triggers for the scan, then do the rich logic on the survivors.
When NOT to use it	A linear game with 5 quests.

5. Save game: big saves without the freeze

Step	Detail
Problem	Saving a large world, inventory or stats blob freezes the game for a fraction of a second, or more on console or HDD.
The slow Blueprint	Save Game to Slot, or building a huge string and writing it. All blocking the Game Thread.
The ParallelFlow fix	Serialize to a string or bytes, then Async Save (Text/Bytes). Want it small and safe? Compress (Bytes) into Async Save. Want it protected? Encrypt String into Async Save. Verify with Hash File.
Why it is faster	Disk writes and compression happen on a worker thread and the frame keeps rendering. It is not faster I/O, it is no freeze.
Expected gain	Removes the save-hitch entirely. Compression also shrinks files 40-70%.
Common mistakes	Kicking off a save every few seconds and overlapping writes. Use one Task Queue named SaveQueue so saves serialize safely.
When NOT to use it	Tiny option files of a few KB. The stock nodes are fine.

6. Minimap and fog of war

Step	Detail
Problem	Splatting hundreds or thousands of unit or POI positions into a minimap texture or influence grid every frame.
The slow Blueprint	Nested loops writing into a 2D array on the Game Thread. Unshippable past small sizes.
The ParallelFlow fix	Heatmap Generator for influence and threat maps. Grid Processing for sampling positions. Feed the result into a dynamic texture.
Why it is faster	Per-cell work is exactly what Blueprint is worst at and native parallel code is best at.
Expected gain	From impossible in Blueprint to runs every frame if you want.
Common mistakes	Regenerating a 512x512 map every frame when the data barely changed. Regenerate on a timer or on change.
When NOT to use it	A 16x16 static minimap computed once.

7. AI manager: closest enemy or target

Step	Detail
Problem	Each of many AI agents finds its nearest target among hundreds or thousands of actors. This is the single most common Blueprint performance killer.
The slow Blueprint	For each agent, Get All Actors plus a ForEach tracking the smallest Distance. If every agent does it every frame, it is agents x targets, every frame.
The ParallelFlow fix	Closest Actor, which snapshots positions on the Game Thread and searches on workers. For many-versus-many, build the position array once and run Nearest Point or Distance Calculator per query.
Why it is faster	The distance scan is native and parallel, and it is off the Game Thread.
Expected gain	~3-6x per query, and crucially it does not stack onto the frame.
Common mistakes	Calling Get All Actors Of Class every frame, since that itself is slow. Cache the target list and refresh it periodically, not per frame.
When NOT to use it	5 enemies. A simple loop is fine and has no setup cost.

8. Crowd AI, boids and simulation

Step	Detail
Problem	Thousands of agents each reading neighbours for flocking, avoidance or influence.
The slow Blueprint	O(n^2) neighbour loops in Blueprint. Dies at a few hundred agents.
The ParallelFlow fix	Use Parallel Filter (Vector), a radius ring around each query point, and Distance Calculator to get neighbour sets natively. Do the steering math in Blueprint on the reduced set. For density, use Heatmap Generator.
Why it is faster	The O(n^2) part becomes native parallel work, and Blueprint only handles the small per-agent decision.
Expected gain	Lets you scale from hundreds to thousands of agents.
Common mistakes	Trying to run the steering in parallel. That is Blueprint logic and stays on the Game Thread. Parallelize the queries, not the decisions.
When NOT to use it	A handful of agents.

9. RTS unit selection and commands

Step	Detail
Problem	Box-select across a large army, issue formation moves, and sort units by distance to target.
The slow Blueprint	ForEach over all units testing bounds, then another pass to sort by distance.
The ParallelFlow fix	Parallel Filter (Vector) for units inside the selection volume, Parallel Sort (Vector) by distance or axis for formation ordering, and Bounding Box for the group extents.
Why it is faster	Selection and ordering are native parallel passes instead of Game-Thread loops.
Expected gain	~3-6x, and smooth selection of large armies.
Common mistakes	Re-filtering during the drag every frame at full army size. Filter on mouse-up, or throttle during drag.
When NOT to use it	Selecting 10 units.

10. Tower defense: targeting many towers

Step	Detail
Problem	Dozens or hundreds of towers each pick a target, whether closest, strongest or furthest-along-path, among many creeps every frame.
The slow Blueprint	Per tower, per creep distance loops. Multiplies fast.
The ParallelFlow fix	Build the creep position array once per frame. Each tower query uses Nearest Point. Furthest along path uses Path Distance precomputed per creep, then a Parallel Reduce (Max).
Why it is faster	One shared native structure feeds all towers instead of each tower re-scanning in Blueprint.
Expected gain	Scales tower and creep counts far past the Blueprint ceiling.
Common mistakes	Rebuilding the creep array separately for every tower. Build it once, share it.
When NOT to use it	A few towers and a dozen creeps.

11. Projectile manager: many bullets

Step	Detail
Problem	Hundreds or thousands of projectiles doing distance, overlap or visibility checks.
The slow Blueprint	Per-projectile loops and line traces on the Game Thread.
The ParallelFlow fix	Distance Calculator for proximity culling. Visibility Processing for batched line-of-sight using async traces, with no frame block.
Why it is faster	Batched native queries and async traces replace serial Blueprint traces.
Expected gain	Large. Async visibility especially removes trace-stall.
Common mistakes	Running full collision through this. ParallelFlow does the queries, not physics resolution.
When NOT to use it	A few projectiles.

12. Damage and AoE system

Step	Detail
Problem	An explosion needs all actors within radius, sorted by distance, with falloff.
The slow Blueprint	Get All Actors plus a distance ForEach plus a sort.
The ParallelFlow fix	Parallel Filter (Vector) for the radius, into Distance Calculator for falloff, then apply damage in Blueprint on the filtered set.
Why it is faster	The find and distance pass is native and parallel. Blueprint only touches actors actually hit.
Expected gain	~3-6x on big AoE, and no hitch on the explosion frame.
Common mistakes	Using this for a 3-target cleave. Overkill.
When NOT to use it	Small radius, few actors.

13. Large data tables and CSV-driven content

Step	Detail
Problem	Importing or scanning a huge external data table for items, dialogue or balance data.
The slow Blueprint	Parsing strings in a ForEach, or a blocking file read that freezes on load.
The ParallelFlow fix	CSV Import (Async) for external spreadsheets, Async JSON Read for JSON, and Parallel Search (String) to find rows.
Why it is faster	Parsing and disk I/O move off the Game Thread, and search is native.
Expected gain	Removes load-screen freezes and searches large tables without hitch.
Common mistakes	Re-importing every time you need one row. Import once, keep the rows.
When NOT to use it	A 20-row DataTable already in the project. Use the built-in DataTable.

14. NPC manager and open world streaming logic

Step	Detail
Problem	Deciding which of thousands of NPCs to activate or sleep based on distance to the player each frame.
The slow Blueprint	Distance ForEach over every NPC on Tick.
The ParallelFlow fix	Distance Calculator for all NPC positions versus player, into Parallel Filter for within activation radius, then activate only those in Blueprint. Spread activation with Async Loop.
Why it is faster	The distance sweep is native and parallel, and activation is amortized across frames.
Expected gain	Turns a per-frame tax into a background sweep. A big open-world win.
Common mistakes	Toggling NPC state every frame causing thrash. Add hysteresis: activate at R, deactivate at R plus a margin.
When NOT to use it	A small level with a handful of NPCs.

15. Procedural generation and voxel terrain

Step	Detail
Problem	Generating heightfields, biome masks or voxel density fields. Inherently per-cell, with huge counts.
The slow Blueprint	Nested loops sampling noise per cell. Freezes for seconds, or is simply infeasible.
The ParallelFlow fix	Noise Generator for multi-octave seeded Perlin, Voronoi Processing for regions and biomes, and Grid Processing for sample points. Feed results to your mesh or voxel builder.
Why it is faster	Per-cell math is the textbook parallel workload. Native code across cores instead of one Blueprint loop.
Expected gain	From impossible in Blueprint to generate a chunk without a visible stall.
Common mistakes	Generating on the Game Thread at load and blocking. Generate ahead or in background and stream in.
When NOT to use it	A tiny fixed grid computed once at design time.

16. Pathfinding helpers

Step	Detail
Problem	Not full navmesh, but the helper math around it: path length, distance-along-path, nearest waypoint among many.
The slow Blueprint	Loops summing segment lengths, and nearest-waypoint distance loops.
The ParallelFlow fix	Path Distance for total and cumulative length per point, which is perfect for how far along am I. Nearest Point for the closest waypoint. Distance Calculator for waypoint costs.
Why it is faster	Native batch math replaces Blueprint segment loops.
Expected gain	~3-6x on large path and waypoint sets.
Common mistakes	Expecting actual A* navigation. This is the surrounding math, not the search.
When NOT to use it	Short paths, few waypoints.

17. Chat, log and text processing

Step	Detail
Problem	Filtering, searching or transforming large chat logs or text buffers, such as a profanity filter, search or formatting.
The slow Blueprint	Per-line ForEach with string ops.
The ParallelFlow fix	Parallel Filter (String) for contains, startswith and length. Parallel Search (String), Find and Replace, and String Processing (Stats).
Why it is faster	String scanning across many lines is native and parallel.
Expected gain	~3-8x on large logs.
Common mistakes	Running per keystroke on a huge buffer. Debounce input.
When NOT to use it	A short chat with a few lines.

18. Analytics and stats aggregation

Step	Detail
Problem	Summing or averaging large arrays of gameplay stats such as damage dealt, distances travelled and economy totals.
The slow Blueprint	ForEach accumulating a running total.
The ParallelFlow fix	Combine Array (Parallel Reduce) for Sum, Average, Min and Max, in double precision so big totals stay accurate.
Why it is faster	Chunked parallel reduction across cores. Double precision avoids float drift on large sums.
Expected gain	~4-8x, plus better numerical accuracy than a naive float loop.
Common mistakes	Summing thousands of floats into a float accumulator in Blueprint and getting drift. The native reduce uses double internally.
When NOT to use it	Summing 50 numbers.

Using this cookbook

01Find the system closest to yours.
02Confirm scale with the Advise node. It will say keep Blueprint if you are small.
03Swap the pattern for the ParallelFlow node, and wire Completed to what came after your loop.
04Prove it with the matching Benchmark node or the Benchmark Map.

Every recipe shares one honest truth: ParallelFlow removes the bottleneck, not the need to think. Measure first, optimize the thing that is actually slow, and let small data stay simple.

Blueprint examples

Copy-ready graph recipes.

1. Non-blocking leaderboard sort

Sort 200k scores while the game keeps running:

Event (scores ready)
  -> Parallel Sort (Float)   (Values = Scores, Ascending = false)
     Started   -> save Task Handle (for a cancel button)
     Progress  -> update UMG progress bar
     Completed -> Results = sorted scores -> rebuild leaderboard UI
     Failed    -> Print String (Error Message)

2. Radius query on a huge point cloud

Find every pickup within 30 m of the player, preserving order:

Parallel Filter (Vector)
  Values       = PickupLocations (TArray<Vector>)
  Center       = Player location
  Min Distance = 0
  Max Distance = 3000
  Completed -> spawn markers for Results

3. Closest enemy of 5,000 actors

Get All Actors Of Class (Enemy)
  -> Closest Actor (Async)   (Actors = enemies, Target = player location)
     Completed -> Actor is the nearest enemy
                  (null only if it died mid-task; Index stays valid)

Positions are snapshotted on the Game Thread when the node runs. The search happens on workers.

4. Procedural heatmap of player deaths

Heatmap Generator (Async)
  Points     = DeathLocations
  Bounds Min = (-10000, -10000)   Bounds Max = (10000, 10000)
  Width      = 128   Height = 128   Radius = 500   Normalize = true
  Completed -> Values (row-major, index = Y * Width + X)
            -> drive a dynamic material / debug tiles

5. Seeded terrain mask

Noise Generator (Async)   (Width = 256, Height = 256, Scale = 0.03, Octaves = 5, Seed = 1337)
  Completed -> Values in 0..1 -> threshold at 0.6
            -> spawn foliage on Async Loop (spread across frames)

6. Encrypted save file (background, zero hitches)

// Save
SaveData (String)
  -> Encrypt String (Async)   (Password = "...")
     Completed -> Result (Base64)
       -> Async Save (Text)   (FilePath = "Saved/SaveGames/slot1.pfsave")
          Completed -> show "Saved" toast

// Load
Async Load (Text)   ("Saved/SaveGames/slot1.pfsave")
  Completed -> Decrypt String (Async)   (same password)
     Completed -> parse SaveData
     Failed    -> wrong password / corrupt file: show an error, never garbage

7. CSV-driven content

CSV Import (Async)   (FilePath = "Content/Data/items.csv", First Row Is Header = true)
  Completed -> Headers = column names
            -> Rows = array of Cells
    -> Async For Each (Indices)   (Array Length = Row Count, Iterations Per Frame = 50)
       Loop Body -> Get row by Index -> spawn/register item
       Completed -> done, UI unlocked the whole time

8. Task group with a loading screen

Start:
  Run Background Task (A)   Started -> add handle to TaskHandles
  CSV Import (Async)  (B)   Started -> add handle to TaskHandles
  Async JSON Read     (C)   Started -> add handle to TaskHandles
  -> Wait For All Tasks (TaskHandles)
     Progress  -> loading bar (fraction of tasks finished)
     Completed -> remove loading screen

9. Serialized saves with Task Queue

Multiple systems can request saves at any time, and they must never overlap:

// Anywhere in the project
Task Queue   (Queue Name = "SaveQueue")
  Execute   -> perform this system's save logic
  Completed -> queue slot released; the next request runs

10. Thumbnail generation

Folder Scan (Async)   (Directory = "Saved/Photos", Pattern = "*.png")
  Completed -> Async For Each (Indices) over Results
     Loop Body -> Image Resize (Async)
        Source      = Results[Index]
        Destination = Results[Index] + "_thumb.png"
        New Width   = 256   New Height = 144   Format = JPEG   Quality = 85

11. Performance comparison rig (for your own benchmarks)

Generate Random Floats (Async)   (Count = 1,000,000)
  Completed ->
    1) Get Game Time In Seconds -> run a Blueprint ForEach sum -> time it (freezes!)
    2) Parallel Reduce (Float) (Sum) -> Elapsed Ms (game keeps running)
  -> print both timings side by side

12. Line-of-sight batch check

Visibility Processing (Async)
  Origin        = sniper tower location
  Target Points = 300 patrol points
  Trace Channel = Visibility
  Ignore Actor  = tower actor
  Completed -> Visible (bool per point) + Num Visible

Uses the engine's asynchronous physics traces, so there is no Game Thread blocking.

Recipe conventions

Always wire Failed at least to a Print String. ParallelFlow errors are descriptive and tell you exactly what to fix.
Store Task Handles if the player can cancel, such as on level exit or a back button.
For arrays above roughly 100k elements, prefer the Parallel Arrays nodes over any Blueprint loop.

API: core types and the async node contract

All types live in the ParallelFlow runtime module, in ParallelFlowTypes.h. Blueprint categories mirror this document.

Type	Description
EParallelFlowTaskPriority	Low, Normal, High, Critical. Maps to Unreal task priorities at or below normal, so background work never starves the Game Thread. Low runs when workers are idle. Use Critical sparingly for latency-critical results.
EParallelFlowTaskState	Queued into Running into Completed, Failed or Cancelled. Exactly one terminal state per task.
FParallelFlowTaskHandle	Copyable id delivered by every node Started event. Used by Cancel Task, Is Task Running, Get Task Progress, and Wait For All/Any Tasks.
FParallelFlowError	Message, which is the human-readable cause, plus Source, which is the node name. Delivered on every Failed pin.
FParallelFlowTaskDebugInfo	Snapshot for debugging: handle, name, state, priority, progress, queue time in ms, execution time in ms, thread name, error message.
FParallelFlowSchedulerStats	Running, queued, completed, failed and cancelled counts, total launched, average and last execution ms, worker thread count, estimated CPU percentage, process memory used and peak in MB.
FParallelFlowCsvRow	Cells as an array of strings. One CSV row, because Blueprint arrays cannot nest.

The async node contract

Every async node inherits UParallelFlowAsyncAction and exposes these pins:

Pin	Payload	Notes
Started	Task Handle	Fired synchronously when the node activates
Progress	float 0-1	Throttled to roughly 30 per second. Final 1.0 guaranteed before Completed
Completed	typed results + Elapsed Ms	Exactly once on success
Failed	FParallelFlowError	Exactly once on error. Never silent
Cancelled	-	Exactly once if cancelled
Task (object pin)	the action	Cancel(), Get Task Handle(), Is Task Running()

All events fire on the Game Thread. You can safely spawn actors, update widgets and touch any Blueprint object in those events.

API: node reference

Async Flow (ParallelFlowFlowActions.h)

Node	Inputs	Completed payload
Run Async	-	Elapsed Ms (continues next frame)
Async Delay (Frames)	Frame Count	Elapsed Ms
Async Delay	Duration (real seconds)	Elapsed Ms
Run Background Task	Iterations (int64), Priority	Checksum, Elapsed Ms. A deterministic CPU workload
Async Loop	First/Last Index, Iterations Per Frame	Iterations, Elapsed Ms. Body pin Loop Body(Index)
Async Do N	N, Iterations Per Frame	as Async Loop
Async For Each (Indices)	Array Length, Iterations Per Frame	as Async Loop
Async Repeat	Count (0 = forever), Interval Seconds	as Async Loop
Async While	Interval Seconds	runs until Break Loop or Cancel
Async Sequence	Step Count	one step per frame
Parallel Split	-	Branch A-D fire on consecutive frames, then Completed
Wait For All Tasks	Task Handles	Finished Tasks, Elapsed Ms
Wait For Any Task	Task Handles	first finished handle
Task Queue	Queue Name	Execute fires in FIFO turn. Completed after release

Break Loop, on loop nodes, ends gracefully via Completed. Cancel ends via Cancelled.

Parallel Arrays (ParallelFlowArrayActions.h)

Element types are Float, Integer, Vector and String, with nodes suffixed accordingly.

Operation	Notes
Parallel Sort	Parallel merge sort. Float and Int: ascending or descending. Vector: by Length, X, Y or Z. String: lexicographic, with optional case sensitivity
Parallel Filter	Float and Int: [Min, Max] range. Vector: distance ring around Center. String: Contains, NotContains, StartsWith, EndsWith, LengthBetween. Order-preserving
Parallel Map	Built-in transforms. Float: Abs, Negate, Sqrt, Square, Scale, Offset, Clamp. Int: adds Modulo. Vector: Normalize, Scale, Offset, Abs, GridSnap. String: Upper, Lower, Trim, Reverse
Parallel Reduce	Float to float with double-precision accumulation, Int to int64, Vector to vector (Sum, Average, Min, Max; vector Average is the centroid). Min or Max of an empty array fires Failed
Parallel Find / Search	First matching index, or -1. Float and Vector accept a tolerance. Search (String) is the first containing substring
Parallel Count	Range count (Float/Int) or substring count (String)
Parallel Unique	Float: tolerance-based, result sorted. Int, String and Vector: order-preserving, and Vector supports a tolerance grid
Parallel Shuffle	Seeded Fisher-Yates. Deterministic
Parallel Reverse / Merge	Merge optionally sorts the result
Generate Random Floats / Integers / Points In Box	Seeded, background generation

Chunking, from the library and synchronous: Get Chunk Count, Get Array Chunk (Float/Integer/Vector/String).

Math Processing (ParallelFlowMathActions.h)

Node	Completed payload
Distance Calculator	float[] distances, parallel to input points
Nearest Point	Index, Point, Distance
Closest Actor	Actor (resolved on the Game Thread; null if destroyed mid-task), Index, Distance
Grid Processing	Vector[] row-major grid, with optional seeded jitter
Heatmap Generator	float[] Width x Height density field, smoothstep falloff, optional normalize
Noise Generator	float[] Width x Height multi-octave Perlin, 0-1, seeded
Voronoi Processing	int[] Width x Height cell, mapping to nearest-seed index
Path Distance	Total Length plus cumulative length per point
Visibility Processing	bool[] per target plus visible count, using async physics traces
Bounding Box	Center, Extents, Min, Max

File Processing (ParallelFlowFileActions.h)

Node	Notes
Async Save (Text/Bytes)	UTF-8 text with optional append, or raw bytes. Creates directories
Async Load (Text/Bytes)	Missing file fires Failed with the path
Async JSON Read	Validates, returns pretty JSON plus top-level keys. Parser errors fire Failed
Async JSON Write	Validates before writing. Pretty or compact
CSV Import / Export	RFC 4180 with quotes, escapes and embedded newlines. Custom delimiter, optional header row
File Copy	1 MB chunks, progress, and cancel deletes the partial file
File Move / Delete	Descriptive failures such as missing source or locked file
Folder Scan	Wildcard pattern, optional recursion, files and/or directories
Compress / Decompress (Bytes/File)	Zlib, Gzip, LZ4 or Oodle. Self-describing container, so decompress auto-detects the codec. Reports original size plus ratio
Hash File / Bytes / String	MD5, SHA-1 or CRC32. Files stream in 1 MB chunks. Lowercase hex digest
Checksum File	CRC32 shorthand

Relative paths resolve against the project directory.

Utility (ParallelFlowUtilityActions.h)

Node	Notes
Image Resize	PNG, JPEG or BMP in, PNG or JPEG out. Bilinear. JPEG quality 1-100
Pixel Processing	Grayscale, Invert, Brightness, Contrast, Tint
Screenshot Save	Requests an engine screenshot, and completes when the PNG exists, with a 10 second timeout
String Processing (Stats)	Characters, words and lines of multi-MB text
String Processing (Find & Replace)	Returns the result plus a replacement count
Encrypt / Decrypt (String/Bytes)	AES-256, password-derived key using stretched SHA-1 x10,000, PKCS#7, and an integrity prefix. A wrong password fires Failed, never garbage. String output is Base64

Function library (ParallelFlowLibrary.h)

Group	Functions
Task control	Cancel Task, Cancel All Tasks, Is Task Running, Get Task Progress, Is Valid Task Handle
Debug	Get Scheduler Stats, Get Active Tasks, Get Task History, Clear Task History, Log Scheduler State
Conversion	Bytes to Base64, Bytes to Hex, String to UTF-8 Bytes
Arrays	Get Chunk Count, Get Array Chunk (x4), Make Index Array, Make Float Range
Memory	Get Memory Stats, Estimate Array Memory (KB)

Console commands

ParallelFlow.DumpTasks logs stats plus every active task.
ParallelFlow.CancelAll requests cancellation of everything.

Extending in C++

Subclass UParallelFlowAsyncAction, or UParallelFlowTickedAction for Game-Thread-driven nodes:

01Declare your five delegates (Started, Progress, your typed Completed, Failed, Cancelled) and override the four Broadcast one-liners.
02Add a static factory with meta = (BlueprintInternalUseOnly = "true", WorldContext = "WorldContextObject") that calls Setup(...).
03Override ExecuteAction() and hand a lambda to LaunchBackgroundWork(...). Inside it, use WorkerHandleCancellation, WorkerReportProgress and WorkerFail, and finish with WorkerComplete<YourClass>(...). Capture plain data plus WeakThis only, never UObjects.

The internal parallel algorithms in ParallelFlowParallelAlgo.h are reusable for custom workloads.

FAQ

Question	Answer
Does ParallelFlow really run my Blueprint code on other threads?	No, and nothing safely can. The Blueprint VM is not thread-safe, so ParallelFlow never executes Blueprint graphs off the Game Thread. Instead it gives you two tools: built-in heavy operations such as sorting, filtering, hashing, image processing and spatial math that run as thread-safe C++ on worker threads, and frame-spreading loops (Async Loop and friends) for your own per-element Blueprint logic. That combination covers the vast majority of my Blueprint freezes the game cases without ever risking a crash.
Which thread do the Completed, Failed and Cancelled events fire on?	Always the Game Thread. You can safely spawn actors, update widgets and touch any Blueprint object in those events.
What happens if I stop PIE or open a new level while tasks are running?	Tasks are asked to cancel, worker threads finish their current step and exit, and pending callbacks detect that their node object is gone and do nothing. No crashes, no dangling references. The scheduler statistics still record the tasks as cancelled.
Is there a task limit?	No hard limit. Tasks queue through the Unreal task system, which schedules them across the available worker threads. Launching thousands of tiny tasks works but is wasteful. Prefer one Parallel Arrays node over a thousand single-element tasks.
Why is my task Progress pin not firing every frame?	Progress dispatch is throttled to roughly 30 updates per second per task so massive workloads cannot flood the Game Thread. The final 1.0 update is always delivered before Completed.
Do the priorities starve my game?	No. Low, Normal and High map to the Unreal background task priorities, and even Critical maps to normal task priority, never above. Rendering and gameplay always win.
Can I cancel a task from anywhere?	Yes. Keep the Task Handle from the Started event and call Cancel Task from any Blueprint, or Cancel All Tasks for everything. It is also available as the ParallelFlow.CancelAll console command and a button in the debug window.
Cancelling does not stop my task instantly. Why?	Cancellation is cooperative. The worker polls the cancel flag at safe points, meaning every few thousand elements, between file chunks, and between sort phases. This is what makes it crash-proof. Worst case latency is a few milliseconds.
Does the debug window work in packaged games?	The window itself is editor-only. In packaged builds use the Blueprint debug nodes (Get Scheduler Stats, Get Active Tasks, Get Task History) to build your own overlay, or the console commands.
Are file paths relative to something?	Yes. Relative paths resolve against your project directory (FPaths::ProjectDir()). Absolute paths are used as-is. Screenshot filenames without a path go to Saved/Screenshots.
How secure is the encryption?	Encrypt and Decrypt use AES-256 with a key derived from your password (two stretched SHA-1 chains, 10,000 iterations each) in ECB block mode with PKCS#7 padding, plus an integrity prefix so wrong passwords fail cleanly. That is strong protection for save files and local data against casual tampering. It is not a substitute for a vetted cryptography suite in adversarial scenarios, since there is no IV or nonce and no HMAC. See Known Limitations.
Parallel Unique (Float) changed my array order!	Documented behaviour: tolerance-based float dedupe sorts the array first, and that is what makes it fast at scale. The Integer, String and Vector Unique variants preserve first-occurrence order.
Can two Task Queue nodes with different queue names run in the same frame?	Yes. Queues are independent, and ordering is only guaranteed within a queue name.
Does it work in shipping builds and all platforms?	Yes. The runtime module uses only engine Runtime modules and is allowed on Win64, Mac, Linux, Android and iOS. The editor module, which is the debug window, never ships.
UE 5.3 and above?	This release targets UE 5.2 exactly. Newer engine versions get their own releases.

Known limitations

Honest fine print. Every limitation below is a deliberate trade-off in favour of engine stability.

Blueprint execution model

Blueprint bodies never run on worker threads. The Blueprint VM is not thread-safe, so nodes with Blueprint body pins (Async Loop, Async For Each, Task Queue, Parallel Split, sequences) spread execution across frames on the Game Thread. True multi-threading is available only through the built-in C++ operations: Parallel Arrays, Math, Files and Utility.
Parallel Map, Filter and Reduce use built-in operations, not arbitrary Blueprint lambdas, for the same reason. If you need a custom per-element transform on workers, that transform must be C++. The plugin action framework (UParallelFlowAsyncAction) is designed to be subclassed for exactly this.
Parallel Split fires its branches on consecutive frames, not simultaneously, because Blueprint execution is inherently sequential on the Game Thread.

Data model

Array inputs are copied once when a node runs, because Blueprint cannot safely share arrays with a worker thread. One copy in, moved through the pipeline, one result array out. For a 1M-float array that is 4 MB per direction.
Blueprint arrays are limited to int32 element counts and single dimensions. CSV rows wrap their cells in a struct because Blueprint cannot nest arrays.
Parallel Unique (Float) returns a sorted array, because tolerance-based dedupe requires sorting. The Integer, String and Vector variants preserve order.
Parallel Reduce (Integer) Average truncates toward zero, and Product can overflow int64 for large inputs.
The compression container and encrypted payloads are little-endian. All platforms UE 5.2 ships games on are little-endian, so this only matters if you parse the files with external big-endian tooling.

Timing and scheduling

Cancellation is cooperative. Workers stop at their next check point, typically within milliseconds, never instantly. The std::inplace_merge phases of a running sort finish their current merge before checking.
Ticked nodes such as Async Delay and the loops run on the core ticker. They measure real time and keep running while the game is paused. This is intentional, for loading screens. Use gameplay timers if you need pause-aware delays.
Task execution order across different priorities is up to the Unreal task scheduler. Only Task Queue nodes guarantee strict ordering, within one queue name.

Files and platform

File nodes operate on loose files, not assets in .pak files. Reading packaged game content requires the asset registry or pak APIs, which are outside this plugin scope. Writing to Saved/ works on every supported platform.
Folder Scan progress is coarse, because directory sizes are unknown up front.
Screenshot Save depends on an active game viewport. It fails with a descriptive error after 10 seconds if the renderer never produces the file, for example on a headless or dedicated server.
Image nodes support PNG, JPEG and BMP input. Output is PNG or JPEG.

Encryption

AES-256 in ECB block mode (the Unreal built-in FAES), PKCS#7 padding, stretched-SHA1 key derivation, and a magic-prefix integrity check. Strong enough for save-file protection and casual tampering, but not designed for adversarial network security: there is no IV or nonce, so identical plaintexts produce identical ciphertexts, and there is no authenticated encryption (HMAC). If you need bank-grade crypto, use a dedicated library.

Visibility Processing

Uses the engine's async physics traces, so results arrive after the physics system processes them, typically the next frame. Requires a valid world, and it is not available in pure editor-utility contexts.

Debug window

Editor-only by design, which keeps shipping builds lean. Runtime introspection is available through the Blueprint debug nodes and console commands.
Finished-task history is capped at 512 entries, and older entries drop off.

Engine version

Built and tested against Unreal Engine 5.2 only.

Example project walkthrough

This guide builds the demo level that ships with the example project, and doubles as a construction manual if you are wiring it yourself. Each station is one Blueprint actor demonstrating a subsystem. All graphs use only ParallelFlow nodes plus stock UMG, and build time is roughly 30 to 45 minutes for the full map.

Level layout

One map, PFDemo_Main, with seven demo stations on podiums plus a wall-mounted stats screen. A shared UMG HUD (WBP_PFDemo) shows an FPS counter in the top-left, proving the game never hitches, a progress bar, a status text block and Cancel buttons.

Station 1: async array processing

BP_Station_Arrays. On interact, run Generate Random Floats (Async) with Count 500000 and Seed 42. Completed goes into Parallel Sort (Float), whose Completed sets the status text to Sorted 500,000 floats in {Elapsed Ms} ms. Chain Parallel Filter (Float) with Min 250 and Max 750, and Parallel Reduce (Float) with Average, off the sorted result, and append their timings. Wire every node Progress into the shared HUD progress bar and every Failed into the status text.

Station 2: parallel sorting race (performance comparison)

BP_Station_Race demonstrates why ParallelFlow exists. Generate Random Floats (Async) with Count 200000. Path A, the wrong way, is a Blueprint ForEach min-search over the array: watch the FPS counter die while it runs, and cap the count if needed. Path B is Parallel Sort (Float), where the FPS counter never moves. Print both durations side by side on the podium TextRender.

Station 3: background calculations (math)

BP_Station_Math. Grid Processing (Async) with a 100x100 grid, Cell Size 120 and Jitter 40, whose Completed spawns instanced static mesh markers via Async For Each (Indices) at 200 Iterations Per Frame, so even the spawning is spread out. Noise Generator (Async) at 128x128 with the Seed exposed on the actor colours the markers by noise value. Closest Actor (Async) runs every second via Async Repeat at Interval 1.0 against all markers, highlighting the marker nearest the player.

Station 4: task groups

BP_Station_Groups. One button starts three Run Background Task nodes with different iteration counts and priorities (Low, Normal, High). Collect the three handles from Started into an array, feed them into Wait For All Tasks, let Progress drive a segmented 3 of 3 display, and let Completed fire a celebration particle. A second button runs the same trio through Wait For Any Task to show race semantics.

Station 5: progress bars and cancellation

BP_Station_Cancel. Run Background Task with Iterations 2000000000, which is long-running on purpose. Progress drives the HUD bar. A big red CANCEL button calls Cancel Task with the stored handle. Cancelled sets the status text to Cancelled at {bar percent}%, demonstrating that the Cancelled pin fires rather than Completed, and that the worker stopped cooperatively.

Station 6: files and encryption

BP_Station_Files. Serialize a small struct of player stats to a JSON string, then Async JSON Write to Saved/Demo/stats.json. Encrypt String (Async) the same JSON, using the password field on the podium, then Async Save (Text) to Saved/Demo/stats.pfenc, then Hash File (Async) with MD5 and print the digest. The load path is Async Load (Text) into Decrypt String (Async), then parse and populate the podium display. Enter a wrong password to see the descriptive Failed path, which never produces garbage output. CSV Import (Async) on the bundled DemoData/items.csv, at 5,000 rows, spawns one pickup per row via Async For Each.

Station 7: large data and the debugger

BP_Station_Debug. A STRESS button launches two Parallel Sort nodes at 1M elements each on Low priority, a Heatmap Generator at 512x512, a Voronoi Processing at 256x256 with 64 seeds, and a Compress (Bytes) of 50 MB of generated data. Open Window > Developer Tools > ParallelFlow Debugger and watch the scheduler juggle them: states, worker threads, progress, average times, CPU estimate and memory. The podium screen mirrors a subset at runtime using Get Scheduler Stats and Get Active Tasks on an Async Repeat at Interval 0.25.

HUD (WBP_PFDemo)

FPS counter: 1 divided by Get World Delta Seconds, updated on Tick. The whole point of the demo is that this number never dips while stations run.
Progress bar and status text bound to Blueprint-exposed variables that every station writes through a Blueprint Interface (BPI_PFDemoHud).

Packaging the demo

The demo uses only runtime nodes, so it packages as-is. The Debugger window is editor-only, and Station 7 runtime panel demonstrates the shipping-safe alternative.

Stuck on something?

We answer every serious message ourselves. Discord is the fastest way to get an answer from the person who built the plugin.

Ask in Discord Email support