C++ migration report
The C++ migration report ranks your Blueprints by how much they would gain from moving to C++. Each Blueprint with logic gets a C++ score from 0 (fine in Blueprint) to 100 (strong C++ candidate), a verdict and the reasons behind it. The report also lists what to fix before an engine upgrade.
Move the top of the list to C++ first and keep the rest in Blueprint. The score is a guide, not a rule: it only sees what is in the graphs.
Verdicts
Section titled “Verdicts”| C++ score | Verdict | Color |
|---|---|---|
| 60 – 100 | Strong C++ candidate | Red |
| 30 – 59 | Consider C++ | Amber |
| 0 – 29 | Fine in Blueprint | Green |
| – | No logic | – |
Structures, enums, Blueprint Interfaces and Blueprints without nodes have no logic. They get the verdict No logic and appear in the report only when they have upgrade notes.
How the C++ score is computed
Section titled “How the C++ score is computed”Each reason adds points. The score is the sum, from 0 to 100.
| Reason | Points |
|---|---|
| Event Tick runs nodes every frame | 10 + the number of nodes Event Tick runs, at most 40 |
| Loops inside Event Tick | 15 per loop, at most 30 |
| Other loops | 5 per loop, at most 15 |
| 8 or more math nodes (Kismet Math Library calls and Math Expression nodes) | half the number of math nodes, at most 20 |
| More than 300 nodes | 25 |
| More than 150 nodes (up to 300) | 12 |
| Complexity of 60 or more | (complexity − 50) ÷ 2 |
| Parent of 2 or more scanned Blueprints | 5 per child Blueprint, at most 15 |
| Used by 5 or more assets | 1 per asset, at most 15 |
| Function library with 3 or more functions | 15 |
Two kinds of Blueprints are weighed lower, and the report says why:
- Widget Blueprints: the sum is multiplied by 0.6. UI layout and bindings usually stay in Blueprint; move only the heavy logic.
- Animation Blueprints: the sum is halved. Only heavy Event Graph logic is worth moving (to
NativeUpdateAnimation); the Anim Graph is already optimized.
Event Tick means an enabled event that overrides ReceiveTick or Tick. Its nodes are all nodes reached by following the exec wires from the event. “Child Blueprints” are scanned Blueprints whose direct parent is this Blueprint, so scan the whole project to count them all.
Reasons
Section titled “Reasons”The reasons are listed with the most points first, in plain sentences, for example:
Event Tick runs 24 nodes every frame; a C++ Tick, a timer or an event costs far less.2 loops: every iteration pays the Blueprint VM cost, a C++ loop does not.Used by 7 assets: a shared system, one C++ version serves all of them.Function library with 4 functions: they map one to one to static functions of a C++ Blueprint Function Library.Before an engine upgrade
Section titled “Before an engine upgrade”Independent of the score, every Blueprint can get upgrade notes:
| Note | When |
|---|---|
| “N deprecated nodes: replace them before the next engine upgrade.” | The Deprecated node rule found deprecated nodes. |
| “Does not compile: fix the errors first, an upgrade only adds new ones.” | The Blueprint has compile errors. |
| “Compiles with warnings: today’s warnings are often the next version’s errors.” | The Blueprint compiles with warnings. |
The deprecated note needs the Deprecated nodes rule to be on. The compile notes come from the Blueprint’s compile status.
In the panel
Section titled “In the panel”The C++ migration tab shows the number of Blueprints with a score of 30 or more, for example C++ migration (3).
The page starts with a note: “N strong C++ candidates, N to consider. Scored from per-frame work, loops, math, size and how many assets depend on each Blueprint; ‘!’ lines are what to fix before an engine upgrade.”
The table lists every Blueprint with logic or with upgrade notes, highest C++ score first (equal scores: higher complexity first):
| Column | Shows |
|---|---|
| # | Rank |
| Asset | Thumbnail, name and folder |
| Kind | Asset kind |
| Verdict | The verdict, then the reasons (lines starting with -) and the upgrade notes (lines starting with !) |
| C++ score | The score, colored by verdict |
| Complexity | “complexity” and the complexity score |
| Action | Details: shows the Blueprint in the Blueprints table. Double-clicking a row does the same. |
When the panel is narrower than 1100 pixels, the #, Kind, Complexity and Action columns are hidden. If the scan found no Blueprint logic, the page says “No Blueprint logic was scanned.”
On the Blueprints page, the C++ column shows the score of every Blueprint (hover it for the verdict), and the details of a selected Blueprint show a C++ candidate fact and a C++ migration card with the verdict, the reasons and the upgrade notes. When a Blueprint has none, the card says “Nothing that needs C++.”
In the exported files
Section titled “In the exported files”| Output | Where |
|---|---|
| HTML site | migration.html (the C++ migration link in the top bar): the numbers of strong candidates, Blueprints to consider and Blueprints with upgrade notes, the average complexity, and a sortable table with Asset, C++ score, Verdict, Complexity and Why. Every asset page has a C++ candidate fact and a C++ migration section. The overview table has a C++ column. |
| Markdown | markdown/migration.md with the same table, a C++ candidate row and a C++ migration section in each asset file. |
| JSON | migration on every asset in scribe.json: score, verdict, reasons and upgradeNotes. |
| AI-ready text | A “C++ candidate” line and a C++ migration section in each asset’s text. See AI export. |
| Python | asset.migration with score, verdict, reasons and upgrade_notes. |
migration.html and migration.md are written with every HTML or Markdown export, also when Audit findings is off.