Unreal Blueprint Master Controller

2026-01-13 16:02 UTC gpt-5-2-thinking Open in ChatGPT ↗

Yes — and it’s a super common pattern in Unreal. Coming from Unity, you’re basically looking for a “GameManager” + “settings container” approach. In Unreal you can do this a few different ways depending on scope (per-level vs whole game), lifetime (reset on level load or persist), and who needs access.

Here are the cleanest options (Blueprint-friendly), and when to use each:

1) GameMode / GameState (level rules + shared runtime values)

Use when: the values are about the current match/level and you’re okay with them resetting on level change.

GameMode exists only on the server (or single-player), good for authoritative logic.
GameState replicates to clients, good for “everyone needs to know this” in multiplayer.

Blueprint pattern

Put “important parameters” on BP_GameMode (single-player) or BP_GameState (multiplayer visible).
Other Blueprints get them via:
- Get Game Mode → cast to your BP
- Get Game State → cast to your BP

This is the closest to a “master controller” that’s level-scoped.

2) GameInstance (global manager that persists across level loads)

Use when: you want one manager that survives map changes (like Unity’s DontDestroyOnLoad).

Great for global settings, progression, difficulty, config, matchmaking, user selections, etc.
Access anywhere: Get Game Instance → cast to your BP_GameInstance

Tip: If you’re storing “tweakable parameters”, pair this with Data Assets (below) so you don’t end up with a huge “god object” Blueprint.

3) World Subsystem / GameInstance Subsystem (modern “manager” pattern)

Use when: you want a real “manager service” without stuffing everything into GameInstance/GameMode.

World Subsystem: one per loaded world (resets per level).
GameInstance Subsystem: persists across levels.
Nice because it’s clearly a service and easy to access from anywhere.

If you’re comfortable with slightly more “Unreal-y” architecture, this is often the cleanest.

4) Data Assets (hold parameters cleanly, then your “manager” reads them)

Use when: the main pain is “I need a single source of truth for tuning”.

Create a Primary Data Asset / Data Asset like DA_LevelConfig:

holds floats, curves, references, etc.
assign it per level (in GameMode, LevelScriptActor, or a placed actor)
then everyone reads from it

This gives you Unity-like “ScriptableObject configs”.

5) A placed “Manager Actor” in the level (simple and very Unity-like)

Use when: the manager is specific to that one level, and you want to see it in the Outliner.

Create BP_LevelManager (Actor)
Place it in the level
Other actors find it:
- Get All Actors Of Class (BP_LevelManager) (works, but don’t spam every tick)
- Better: store a reference once at BeginPlay, or have the manager register things.

This is the quickest to set up and very understandable.

How to “pass parameters” cleanly (recommended approach)

Instead of the manager “pushing” values into every blueprint constantly, do this:

Option A: Blueprints “pull” from manager on BeginPlay

Each blueprint, on BeginPlay:
- Get Manager reference
- Read needed values
- Cache locally

Option B: Use an interface (best for decoupling)

Create Blueprint Interface: BPI_ReceivesConfig
- Function: ApplyConfig(ConfigStruct)
Manager finds relevant actors and calls ApplyConfig once.
Actors implement the interface however they want.

This keeps your level logic modular and avoids hard casts everywhere.

Option C: Use Event Dispatchers (for live updates)

If your parameters can change at runtime (difficulty slider, dynamic weather, etc.):

Manager exposes an Event Dispatcher like OnConfigChanged
Listeners bind to it and update themselves only when needed.

What I’d do in your situation (practical default)

If you currently have “a few blueprint scripts that manage things in my level” and you want clarity:

✅ Start with a BP_LevelManager actor + a Config Data Asset

DA_LevelConfig holds all tweakable values
BP_LevelManager references that asset and exposes getters/events
Other blueprints:
- get the manager once
- read what they need (or implement an interface)

When/if you later need persistence across levels, move the manager part into GameInstance or a Subsystem, but keep the Data Asset approach because it scales nicely.

If you tell me:

do you need the values to persist across level loads?
is this single-player only or multiplayer?
are the parameters mostly static “tuning”, or do they change during play?

…I’ll point you to the best exact Unreal class (GameMode vs GameInstance vs Subsystem vs placed Actor) and a clean Blueprint setup for it.

Totally fair — in Unity you often push references into things from a central manager (or you drag refs in the Inspector), so Unreal’s “let actors find the manager” can feel backwards at first.

In Unreal, both directions are valid. The reason I suggested “others hold a reference to the manager” is mainly:

the manager is the single source of truth
lots of actors can read it without the manager needing to know them
it avoids the manager becoming a hard-wired spiderweb of references

But if you prefer “manager drives everything,” you can absolutely do that too.

Two solid patterns (pick the one that feels least weird)

Pattern A — Others reference the Manager (pull)

Mental model: “This is my service / config object; anyone can query it.”

How it looks:

You place BP_Manager in the level.
In any blueprint that needs parameters, on BeginPlay:
- Find manager once (GetActorOfClass)
- Cache it in a variable
- Use it whenever needed

Why this is common in Unreal:

less manual wiring
works even if you spawn things dynamically
fewer fragile references if you duplicate levels

Key tip: “Get Actor of Class” is fine once on BeginPlay (don’t do it every tick).

Pattern B — Manager holds references to everything (push)

Mental model: “This is my Unity GameObject manager that controls systems.”

How it looks:

BP_Manager has variables like LightController, AudioController, ProjectionController etc.
You assign those references in the editor (like Unity inspector), or the manager finds them on BeginPlay.
The manager pushes parameters / calls functions on them.

This is 100% valid, especially for a simple “experience” project.

Two ways to populate those references:

Manual (Inspector-style): Expose variables on the manager, then drag-drop the actors in the level.
- In Blueprint variable settings: check Instance Editable (and optionally Expose on Spawn).
Auto-discover: On BeginPlay, manager uses Get All Actors of Class (or by Tag) and stores them.

For small scope, manual is super clean and very Unity-like.

The best “Unreal-feeling” compromise

Pattern C — Registration (manager doesn’t search, actors don’t search)

This is the least weird once you see it:

Manager exists.
Each “system” actor, on BeginPlay:
- finds manager once
- calls RegisterSelf(this)
Manager now has a list of registered actors and can push updates.

So:

actors only do one small “hello” handshake
manager gets control and can push changes
no huge editor wiring

This is very scalable and still feels “manager-driven”.

Since your scope is simple and likely all placed in the level:

✅ Use a Manager Actor + manual references

Place BP_Manager
Add variables for your key blueprint controllers
Mark them Instance Editable
Drag-drop the references in the Details panel
Manager sets parameters / triggers events

That will feel closest to Unity and it’s super readable.

Concrete Blueprint sketch (no code, just the nodes)

In `BP_Manager`

Variables:
- AudioController (type: BP_AudioController ref) ✅ Instance Editable
- LightController (type: BP_LightController ref) ✅ Instance Editable
- TimingController etc.
On BeginPlay:
- Set parameters on each controller (or call Init(Config))

In each controller blueprint

Create a function like InitFromManager(ManagerRef) or ApplyConfig(ConfigStruct)
Manager calls it once.

If you tell me what your “few blueprint scripts” are (like lighting, media playback, cues, triggers, timeline), I’ll suggest the cleanest structure (and whether you should use a struct/config asset, event dispatchers, or just direct calls).

For a “manager actor in the level”, you usually make a Blueprint Class based on Actor.

The typical choice

Blueprint Class → Actor
Name it something like BP_LevelManager / BP_ExperienceManager.

Why Actor:

it can be placed in the level (like a Unity GameObject)
it has BeginPlay / Tick if you need them
it can hold variables, references, dispatchers, functions, timelines, etc.

When you’d pick something else

GameMode Blueprint: if you want “one per level” but not place it in the scene, and you’re fine accessing it via Get Game Mode. (Still valid for simple experiences.)
ActorComponent Blueprint: if you want “manager logic attached to something else” (like your camera rig / root experience actor). Components can’t live alone; they attach to an actor.
Level Blueprint: quick glue logic, but it becomes messy fast and isn’t reusable. I avoid it for anything beyond tiny one-offs.

Practical setup (recommended)

Create BP_LevelManager (Actor) and:

Add a SceneComponent as the root (default is fine)
Create variables for the other controllers (mark Instance Editable so you can drag-drop references)
Put initialization in Event BeginPlay
Optional: add Event Dispatchers for “OnConfigChanged”, “OnCueTriggered”, etc.

One extra tip for “finding it”

Give it a clear identifier so anything can grab it reliably:

Add an Actor Tag like LevelManager
Then others can Get All Actors with Tag (once) and cache it

If you want, tell me how many “controller” blueprints you have and what they do, and I’ll suggest whether you should keep them as Actors, convert some to Components, or make them plain “data/config” with the manager driving them.

This is a very important Unreal concept, and it’s exactly where Unity devs usually get confused at first. I’ll explain it using Unity equivalents and then give you clear “when to use which” rules.

Short answer (Unity mental model)

Actor

≈ GameObject

Exists by itself in the level
Has a transform
Can be placed in the level or spawned
Owns Components
Can be referenced directly in the Outliner

Actor Component

≈ MonoBehaviour (without its own GameObject)

Cannot exist alone
Must be attached to an Actor
Has no transform (unless it’s a SceneComponent)
Adds behavior, logic, or data to an Actor
Reusable and modular

Slightly deeper (important distinctions)

Actor

Top-level object in the world
Has location/rotation/scale
Can:
- Tick
- Receive BeginPlay
- Spawn other actors
- Be referenced in the editor
Examples:
- Camera rig
- Light controller
- Media playback controller
- Your BP_LevelManager

Think:

“This thing exists in the world.”

Actor Component

Lives inside an Actor
No independent transform
Shares the lifetime of its owner
Accessed via GetOwner()
Great for logic reuse

Think:

“This is behavior that belongs to something else.”

Scene Component (subtype of Actor Component)

This is where Unreal differs a bit from Unity.

Has a transform
Can be attached hierarchically
Examples:
- CameraComponent
- StaticMeshComponent
- LightComponent
Still not a standalone object

Unity analogy:

A Transform + Renderer attached to a GameObject

Practical examples (projection / experience context)

Good use of Actor

BP_LevelManager
BP_LightingController
BP_MediaController
BP_TriggerZone
BP_TimelineConductor

These are:

Conceptually separate systems
Easy to place and wire visually
Easy to enable/disable or replace per level

Good use of Actor Component

“Fade in/out logic”
“Audio reactive behavior”
“Timed cue playback”
“Projection mapping logic” (if reused on multiple actors)
“State machine logic”

Attach these to:

Your Manager Actor
Your Camera Actor
A Projection Screen Actor

Rule of thumb (very useful)

Ask yourself:

Can this exist on its own in the level?

Yes → Actor
No, it’s just behavior → Actor Component

In your manager case

You should almost certainly use:

✅ Actor for the manager
Optional:

Break its logic into Actor Components if it gets big

Example:

BP_LevelManager (Actor)
- BP_CueSystemComponent
- BP_TimingComponent
- BP_ConfigComponent

This keeps the presence of the manager clear, while keeping logic clean and modular.

One Unreal-specific gotcha

In Unity, you often add/remove MonoBehaviours freely.

In Unreal:

Components are usually designed ahead of time
Dynamically adding components is possible but less common

So start simple: Actors first, Components when you see repetition.

If you want, next I can:

sketch a Unity → Unreal mapping table for common patterns you’re used to, or
walk through how you’d refactor one of your existing Blueprints into Actor vs Component cleanly.

This is a very sharp observation, and you’re not wrong — the confusion comes from a philosophical difference between Unity and Unreal, not a technical one.

In Unity:

GameObject = empty container
MonoBehaviours = where the code lives

In Unreal:

Actor = container and primary behavior unit
Components = specialization / reuse, not mandatory

So the key mindset shift is:

In Unreal, an Actor is closer to “GameObject + its main MonoBehaviour combined.”

Why Unreal puts “code in the Actor” by default

Historically and architecturally, Unreal assumes:

An Actor represents a thing
That thing’s core behavior belongs to the Actor
Components are add-ons, not the default place for logic

So it’s perfectly idiomatic Unreal to have:

lots of logic
state
event dispatchers
orchestration
directly in an Actor blueprint

This feels wrong if you’re thinking “Actors are just containers,” but in Unreal they’re not.

A more accurate mental mapping (this helps a lot)

Unity

GameObject
 ├─ Transform
 ├─ MovementController (MonoBehaviour)
 ├─ AudioController (MonoBehaviour)
 └─ GameManagerLogic (MonoBehaviour)

Unreal

Actor (BP_LevelManager)
 ├─ Root Scene Component
 ├─ AudioComponent
 ├─ TimelineComponent
 └─ (Logic lives directly on the Actor)

So Unreal collapses one layer compared to Unity.

When SHOULD logic go into Actor Components?

Use Actor Components when one of these is true:

The logic is reusable across many Actors
- e.g. “Fades audio”, “Plays timed cues”, “Responds to MIDI”
The Actor would become too big
- You want separation of concerns
The logic is optional or swappable
- Some actors have it, some don’t

If none of those are true → keep it in the Actor

Your manager specifically

For a Level / Experience Manager:

✅ Logic directly in the Actor is correct
❌ Putting everything into components is unnecessary

A good Unreal-style structure:

BP_LevelManager (Actor)
 - References to controllers
 - High-level flow logic
 - Cue triggering
 - State variables

Only split into components if you notice:

repeated logic
complexity growing
“this could be reused elsewhere”

Why Unreal doesn’t push “everything into components”

A few practical reasons:

Actors already have lifecycle events (BeginPlay, EndPlay, Tick)
Fewer indirections = simpler Blueprints
Easier debugging (you click the Actor and see everything)
Components are slightly heavier conceptually

Unreal devs generally think:

“If this is the thing, put the logic on the Actor.”

Unity devs think:

“If this describes the thing, put it on a component.”

Neither is wrong — just different defaults.

A simple rule you can safely follow

For now, without overthinking:

Default to putting logic in the Actor.
Use Actor Components only when reuse or clarity demands it.

That rule will not get you into trouble in Unreal.

If you want, next I can:

show a Unity GameManager → Unreal LevelManager side-by-side example, or
help you refactor one of your existing Blueprints and say exactly what should stay in the Actor vs move to components.

Great screenshot — this actually shows exactly where the Unreal mental model clicks (and where it currently doesn’t).

You’re very close, you’re just missing one crucial Unreal step: casting.

What’s happening in your screenshot (important)

Scaler_BP is an Actor reference (blue pin)
Get Component by Class returns a Component reference
Right now, Unreal only knows:

“This is some component of that class”

It does not yet know:

“This is my specific Blueprint class, so I can access its variables”

That’s why you can’t see or read parameters yet.

The key rule (Unreal-specific)

To access variables or functions on a Blueprint class, you must CAST to it.

This applies to:

Actors
Components
Anything Blueprint-derived

Case 1 (most likely): The parameter lives on the Actor

If Scaler_BP is a Blueprint Actor and the parameter is a variable on it:

Correct setup

You do NOT need Get Component by Class at all.

Do this instead:

Drag from Scaler_BP
Cast To BP_Scaler (or whatever the class is called)
From the cast output pin → access variables directly

Blueprint flow

Scaler_BP
 → Cast To BP_Scaler
   → Get TileScale_Min
   → Get TileColor_A

✅ This is the cleanest and most common solution.

Case 2: The parameter lives on an Actor Component

If the parameter is inside a component attached to Scaler_BP:

Correct Blueprint flow

Scaler_BP
 → Get Component by Class (ScaleByMatComponent)
 → Cast To BP_ScaleByMatComponent
   → Get Radius
   → Get Softness

Important details

Component Class must be the Blueprint component class, not a base class
You still must Cast, even if you already filtered by class

This is the step you’re missing in the screenshot.

Why Unreal forces this (Unity comparison)

In Unity:

var scaler = scalerGO.GetComponent<Scaler>();
scaler.radius = 5;

In Unreal:

Get Component by Class ≈ GetComponent
Cast To ≈ “treat this as my concrete type so I can access members”

Unreal just makes the type step explicit.

VERY IMPORTANT: Use specific types for references

Right now your variable is:

Scaler_BP → Type: Actor

That works, but it’s generic.

Better:

Change the variable type to:

Scaler_BP → Type: BP_Scaler (Object Reference)

Then:

❌ No Cast needed
❌ No Get Component needed
✅ You can directly read parameters

This is the Unreal equivalent of:

“I know exactly what type this reference is”

Clean recommended setup for your manager

For a simple experience:

In Manager:

Variable: Scaler → BP_Scaler reference
Instance Editable → drag-drop in editor

In BP_Scaler:

Variables live directly on the Actor
Optional: internal components if needed

Access:

Manager → Scaler → Get TileScale_Min

No casting, no searching, no component lookup.

Rule of thumb (bookmark this)

Actor variable?
→ Reference Actor (typed) → Get variable
Component variable?
→ Get Component → Cast → Get variable
You see “Cast To” everywhere?
→ Your references are too generic

If you want, next we can:

refactor this exact setup into a “clean Unreal” version, or
decide whether ScaleByMat should even be a component or just live on the Actor.

Ah — this is the missing Unreal puzzle piece, and your screenshot makes it very clear 👍
Short version:

You cannot reference an Actor Component directly from the level Outliner.

That’s by design in Unreal, and it’s why your Scaler_BP slot says None.

Let’s break this down cleanly and then fix it.

Why this is happening (critical concept)

Outliner only shows Actors
Actor Components live inside an Actor
Therefore:
- You can drag an Actor
- You cannot drag an Actor Component

So this variable:

Scaler_BP → Actor Component

❌ cannot be assigned in the level
❌ cannot be picked from the Outliner
✅ must be obtained via its owning Actor

This is exactly what you’re running into.

The correct Unreal pattern (2 good options)

✅ Option 1 (RECOMMENDED): Reference the Actor, then get the Component

This is the most Unreal-idiomatic and cleanest fix.

Step 1: Change the variable type

In TileManager_BP:

Change:
```
Scaler_BP → Actor Component
```

To:

ScalerActor → BP_ScalerActor (Actor reference)

Now you can assign it in the Outliner.

Step 2: Get the component from the actor

Blueprint flow:

ScalerActor
 → Get Component by Class (BP_ScaleByMatComponent)
 → Cast To BP_ScaleByMatComponent
   → Set Scale Min / Max

You only do this once (BeginPlay or Init), cache the component, and reuse it.

Why this is good

Matches Unreal’s ownership model
Clear hierarchy
Editor-friendly
No hacks

This is what Epic expects you to do.

✅ Option 2: Make the component a Default Component of the actor

If the scaler is always part of that actor:

In `BP_ScalerActor`

Add BP_ScaleByMatComponent as a default component
Name it something clear (ScaleByMatComp)

Then in code:

Get ScaleByMatComp → Set Scale Min

No Get Component by Class, no casting needed.

This is the cleanest setup if the component is not optional.

❌ Option 3 (don’t do this): Try to expose components to the Outliner

Unreal intentionally does not allow this:

Components are implementation details
Actors are the public-facing objects

Trying to fight this will always feel painful.

How this maps to Unity (this should click)

Unity:

[SerializeField] Scaler scaler;

Unreal equivalent:

Reference the Actor
Then access its Component

Unreal does not support:

[SerializeField] ScalerComponent scaler;

…from the scene directly.

Your specific fix (step-by-step)

Change Scaler_BP variable to:
- Type: BP_ScalerActor (Object Reference)
Assign it in the Outliner
On BeginPlay:
- Get its ScaleByMat component
- Cache it in a variable
Use cached component everywhere

Rule to remember forever

Outliner = Actors only
Components are accessed through their owning Actor

Once you internalize this, Unreal suddenly becomes much less frustrating.

If you want, next I can:

help you decide whether ScalerBP should really be a component or just live on the actor, or
refactor this exact Blueprint graph into the cleanest possible Unreal version (with fewer casts and nodes).

Yes — the way it’s set up right now is inefficient, but it’s easy to fix.

What’s inefficient in your graph

You’re doing this every Tick:

Get Component by Class (a search)
Then setting parameters

The sets themselves might be fine, but searching for the component every frame is the expensive/pointless part.

The simple fix: cache the component once

Do the lookup once on BeginPlay, store it in a variable, and on Tick just use the cached reference.

Blueprint structure

BeginPlay

Get Component by Class
(Cast if needed)
Promote to variable → ScalerComp

Tick

Use ScalerComp directly → Set Scale Min/Max

This removes the repeated search.

Bigger question: do you need Tick at all?

Only use Tick if the values truly need to change every frame.

If values change only when you tweak them / trigger an event:

✅ Call UpdateParams only when something changes:

when user input changes a slider
when you trigger a cue
when you load a preset
when a timeline updates (timeline can drive updates without global Tick)

If values are driven continuously (e.g., audio-reactive, time-based animation):

✅ Tick is acceptable
…but still cache the component, and consider driving via:

Timeline
Timer (10–30 times/sec is plenty for many “experience” effects)
Material parameter collection (if you’re updating materials globally)

Another inefficiency: setting even when nothing changed

Even if Tick is required, don’t set parameters if they’re identical.

Common pattern:

store last values (LastScaleMin, etc.)
compare
only Set when different (or when difference > tiny threshold)

This can matter if you’re pushing params to materials/components a lot.

Rule of thumb

GetComponent / GetAllActors / Find: do once, cache
Tick: only if truly continuous
Most “experience” controls: work great with event-driven updates or timers

If you tell me what drives Tile Scale Min/Max (UI sliders? timeline? audio analysis?), I’ll recommend the best update method (Tick vs Timeline vs Timer vs event dispatcher) for your case.

Great question — this is exactly the right thing to clarify 👍

Short, correct answer

Your cached variable should be the specific component class, not a generic Actor Component.

So:

✅ Variable Type: BP_ScaleByMat (Actor Component reference)
❌ Not: Actor Component
❌ Not: Actor

Why this matters (very important)

If you store it as:

Actor Component → you’ll need to cast every time
BP_ScaleByMat → you get direct access to variables & functions

This is Unreal’s equivalent of:

[SerializeField] ScaleByMat scaleByMat;

Correct setup step-by-step

1️⃣ Create the variable

In TileManager_BP:

Name: ScalerComp
Type: BP_ScaleByMat (your Actor Component Blueprint)
Variable category: References
NOT Instance Editable (this is runtime-cached)

2️⃣ Cache it once (BeginPlay)

Blueprint flow:

BeginPlay
 → ScalerActor (BP_ScalerActor reference)
 → Get Component by Class (BP_ScaleByMat)
 → Cast To BP_ScaleByMat (if needed)
 → Set ScalerComp

If BP_ScaleByMat is the exact class you request, the cast is often unnecessary.

3️⃣ Use it everywhere else

On Tick / UpdateParams / Events:

ScalerComp → Set Scale Min
ScalerComp → Set Scale Max

No searching, no casting, no overhead.

Very common gotcha (watch out)

If your component:

is added dynamically at runtime
or might not exist

Then:

Check IsValid(ScalerComp) before using it

But if it’s a default component on the actor, you’re safe.

One more Unreal-style improvement

If BP_ScaleByMat is always present on the scaler actor:

👉 Add it as a default component
👉 Skip Get Component by Class entirely

You then do:

ScalerActor → Get ScaleByMatComp

That’s the cleanest possible setup.

Final rule to remember

Cache references using the most specific type you know.
Generic types cause casts. Specific types remove them.

Once you follow this consistently, your Blueprints get much simpler and faster.

If you want, next I can:

refactor your exact graph into a minimal “clean Unreal” version, or
help you decide whether ScaleByMat should really be a component or just live on the actor itself.

Yep — you fixed the expensive part. ✅

In your new graph you:

Get Component by Class once (in CacheComponents)
Store it in ScalerComponent
Then UpdateParams just uses the cached reference

So you’re no longer doing the component lookup every frame, which was the main inefficiency.

What’s still potentially inefficient

You’re still calling UpdateParams on Tick, which means you’re still doing 4 sets every frame:

Set Scale Min
Set Scale Max
Set Color A
Set Color B

That’s not crazy expensive, but whether it’s “efficient enough” depends on whether those values actually change every frame.

If the values change rarely (UI tweak, cue change, preset load)

Then ticking is unnecessary overhead. Better:

call UpdateParams only when a value changes

If the values change continuously (audio reactive, time animation)

Tick is fine — and now that you’ve cached the component, it’s a normal Unreal pattern.

Two quick improvements (high value)

1) Add an IsValid check (prevents null issues)

Right before setting:

IsValid(ScalerComponent) → Branch → then set values

This avoids runtime errors if the component wasn’t found.

2) Only set when changed (best practice if ticking)

Cache last values in the manager:

LastScaleMin, LastScaleMax, LastColorA, LastColorB On Tick:
compare
only set when different (or different beyond a tiny tolerance for floats)

This makes Tick basically free when nothing changes.

Practical recommendation for an “experience”

Most “projection experience” controls don’t need per-frame updates unless you’re doing reactive visuals.

A very clean approach:

BeginPlay → CacheComponents → UpdateParams
When you change a parameter (slider/cue/etc.) → call UpdateParams
No Tick at all

So: is it efficient now?

✅ Lookup/caching: efficient now
✅ Safe/normal if you really need per-frame updates
⚠️ Tick-driven sets: only “efficient” if values truly update continuously

If you tell me what drives those params (timeline? UI? audio?), I’ll tell you whether Tick is appropriate or which alternative (timeline/timer/event) fits best.

Excellent question — and you’re thinking in exactly the right direction.

Short answer first:

❌ There is no direct Blueprint equivalent of Unity’s OnValidate.
✅ But Unreal gives you a couple of editor-time hooks that together cover the same use cases.

Let’s map this cleanly.

Unity `OnValidate` → Unreal equivalents

What `OnValidate` does in Unity

Fires when:
- a serialized value changes in the Inspector
- the object is loaded
Works in the editor
Lets you “push changes immediately”

Unreal options (from most useful → most niche)

✅ Option 1 (BEST MATCH): Construction Script

This is the one you’ll use most.

What it is

Runs:
- when you change a variable in the Details panel
- when the actor is moved
- when the actor is placed
Runs in the editor
Does not run in packaged builds the same way

How to use it

Move your “preview/update” logic into the Construction Script:

Construction Script
 → CacheComponents (editor-safe)
 → UpdateParams

Now when you tweak:

TileScale_Min
TileScale_Max
Colors

…the result updates immediately in-editor, just like OnValidate.

Important rules

❌ Do NOT use Tick in Construction Script
❌ Do NOT spawn actors
❌ Do NOT do expensive logic
✅ Setting component/material parameters is perfect

✅ Option 2: PostEditChangeProperty (C++ only)

This is the true OnValidate equivalent — but:

C++ only
Not available in Blueprint

Since you’re Blueprint-only, ignore this.

✅ Option 3: Editor Utility Widgets / Editor Utility Actors

Useful if:

you want buttons like “Apply Params”
batch-update multiple actors
build tools

Probably overkill for your case, but good to know.

The clean setup for your manager (recommended)

Editor-time preview

Construction Script
 → CacheComponents (guard with IsValid)
 → UpdateParams

Runtime init

BeginPlay
 → CacheComponents
 → UpdateParams

Runtime changes

When slider/cue changes → call UpdateParams
No Tick needed

One VERY important caveat (many Unity devs get bitten)

Construction Script:

runs a lot
runs in the editor
should be idempotent

Meaning:

Running it 100 times should not break or accumulate anything.

You’re good because:

you’re just setting parameters
you’re not spawning or allocating

Mental model (this helps a lot)

Think of it like this:

Unity	Unreal
`OnValidate()`	`Construction Script`
Inspector change	Details panel change
Editor-only	Editor-only
Push values	Push values

Final recommendation for your graph

❌ Remove Tick
✅ Use Construction Script for live preview
✅ Use UpdateParams as the single “apply” function
✅ Call it from:
- Construction Script
- BeginPlay
- Any runtime cue/slider

This gives you the exact same workflow you’re used to in Unity — just Unreal-flavored.

If you want, next I can:

show you how to guard Construction Script logic properly, or
help you split “editor preview” vs “runtime only” cleanly.

You’re probably not sitting on some catastrophic mistake — a noticeable hitch when you stop PIE (Play In Editor) is very common in Unreal, because the editor has to tear down the runtime world and restore the editor world. That said, there are a few “usual suspects” that can make the hitch way worse, and they’re worth checking.

Why Unreal can lag when you stop the game

When you hit Stop, Unreal typically does a bunch of this at once:

Garbage Collection (cleaning up all runtime-spawned objects)
Stopping async systems (media playback, audio, streaming, async loading)
Rebuilding editor state (restoring actors, re-running Construction Scripts)
Undo/transaction bookkeeping (editor bookkeeping for what changed)

So a small hitch is normal. A big hitch usually means something is creating lots of objects or work during play.

The biggest “major fuckups” that cause stop-lag

Here’s the shortlist that bites people most often:

1) Creating new objects every Tick

The #1 culprit in Blueprint projects is accidentally creating stuff per-frame, like:

Create Dynamic Material Instance on Tick
Spawn Actor on Tick
Create Widget on Tick
Add Component on Tick
Repeated Get All Actors of Class on Tick

Your current graph (Set a few variables on a cached component) is not inherently bad — unless inside that component you’re creating new resources each call.

✅ Check your Scale by Mat component:

Do you create a Dynamic Material Instance anywhere inside the update path?
- If yes: create it once (BeginPlay/Construction), store it, and only set parameters after.

2) Heavy Construction Script

Construction Scripts can run a lot, and when you stop PIE, the editor restores actors and can trigger construction work again.

If your Construction Script does expensive scanning (GetAllActors, loops, etc.), stopping can hitch.

Rule: Construction Script should be “set a few values”, not “search the world”.

3) Timers / delegates / media not being stopped

If you started things like:

Timers (Set Timer by Event/Function)
Event dispatchers bindings
Media players / video textures
Audio capture / analysis plugins

…make sure you stop/clear them on EndPlay.

In Blueprints:

Event EndPlay
- Clear and Invalidate Timer by Handle (or Clear Timer)
- Unbind delegates (if you bound any)
- Stop media playback

4) Printing/log spam

If you have Print String on Tick (or frequent logging), it can lag horribly, and sometimes the hitch is more noticeable on stop as the log flushes.

Quick sanity checks you can do immediately

These will tell you fast whether your setup is “normal Unreal hitch” or “something is wrong”.

A) Turn off Tick and see if Stop becomes instant

In your manager:

disable Tick entirely (or don’t call UpdateParams from Tick)
only call UpdateParams from BeginPlay

If the stop-lag drops massively → your per-frame work is the issue (or something your per-frame calls trigger).

B) Check if you’re creating Dynamic Material Instances repeatedly

Search in your project for:

Create Dynamic Material Instance If that’s inside UpdateParams or anything called often, that’s a red flag.

Correct pattern:

Create DMI once → store → SetScalar/Vector parameters later.

C) Use these stats while playing

Open console (~) and run:

stat unit (frame breakdown)
stat game (game thread)
stat blueprint (blueprint time)

If stat blueprint shows big numbers while running, stopping will often hitch because you created lots of stuff.

About your specific graph

From what you’ve shown:

✅ caching the component is good
✅ setting a few vars is fine
⚠️ ticking it is only a problem if it’s triggering expensive work downstream (materials, arrays, searches, allocations)

So the next place to look is inside the component / whatever those Set nodes ultimately do.

If you want the fastest “is there a bomb?” test

Tell me:

In your Scale by Mat component, are you touching materials? (and do you create DMIs?)
Are you using Construction Script anywhere for this system?
Are you using Media Player/video?

And I’ll point to the most likely culprit with a concrete fix.

Short answer: there is no single built-in “Color Gradient” parameter in Unreal materials like a Unity Gradient, but you can build the exact same thing in a few standard ways, and they’re first-class, efficient, and very common.

Once you see the patterns, it’s straightforward.

The Unreal way to think about gradients

In Unreal materials, a gradient is usually:

A value from 0–1 → used to LERP between colors

That 0–1 value can come from:

UVs
world position
distance
time
a scalar parameter
a texture

And the colors are usually Vector Parameters.

The most common gradient patterns

✅ 1) Two-color gradient (most common)

This is the direct replacement for a simple Unity gradient with 2 keys.

Nodes:

LinearInterpolate (Lerp)
VectorParameter ColorA
VectorParameter ColorB
Alpha = 0–1 value

Color = Lerp(ColorA, ColorB, Alpha)

Alpha sources could be:

TextureCoordinate.X
TextureCoordinate.Y
Distance math
A scalar parameter you drive from Blueprint

This is exactly what you’re already doing with Color A / Color B.

✅ 2) Multi-color gradient (Unity-style gradient)

There are three main ways to do this.

Option A — Gradient Texture (VERY common & flexible)

This is the closest to Unity’s Gradient asset.

Create a 1D or 2D texture that contains your gradient
Sample it in the material
Use a scalar (0–1) as the UV lookup

TextureSample(GradientTex, float2(Alpha, 0))

Pros

Unlimited color stops
Artist-friendly
Very cheap at runtime
Easy to swap gradients

Cons

Not “pure parameter” (but totally normal in Unreal)

👉 This is the industry standard solution.

Option B — Curve Atlas / Color Curve (advanced, editor-driven)

Unreal does support color curves, but not as a simple drop-in parameter.

Create a Curve Linear Color
Add it to a Curve Atlas
Sample the Curve Atlas in the material

This gives you:

Time/value → color mapping
Editable curves in editor
Centralized control

Pros

Very powerful
Great for time-based or procedural gradients

Cons

More setup
Overkill for simple gradients

Option C — Chain of Lerps (simple but limited)

For 3–4 colors max:

Lerp(
  Lerp(ColorA, ColorB, t1),
  ColorC,
  t2
)

Pros

No textures
Fully parameterized

Cons

Gets messy fast
Not scalable

What Unreal does NOT have (by design)

❌ No “Gradient” parameter type
❌ No inspector gradient editor like Unity
❌ No key-based gradient UI in materials

Unreal prefers:

Textures or math instead of special parameter types

Based on everything you’ve shown so far:

If you need 2 colors → keep what you have

Color A
Color B
Lerp

You’re already doing it correctly.

If you need multiple colors / artistic control

✅ Use a gradient texture

Make a small 256×1 texture
Sample it with a scalar parameter
Drive that scalar from your manager

This integrates perfectly with your Blueprint setup.

Unity → Unreal mental mapping

Unity	Unreal
Gradient	Gradient Texture
Gradient.Evaluate(t)	TextureSample(UV = t)
Color keys	Pixels in texture
OnValidate	Construction Script

TL;DR

❌ No built-in gradient parameter
✅ Gradients are made via Lerp + parameters or gradient textures
🎯 Gradient textures are the cleanest, most scalable solution
🚫 You are not missing some hidden Unreal feature

If you want, I can:

sketch a minimal material graph for a gradient texture, or
recommend which approach fits best with your current TileManager → ScaleByMat setup.

Got it — you don’t need a “gradient” for color; you want an easing curve / non-linear remap for the Lerp alpha (or for any 0–1 interpolation). Unreal materials handle this really well.

In Unreal terms, you want to take a linear t (0→1) and turn it into t' (still 0→1 but curved), then use t' for your interpolation.

The core pattern

t' = Ease(t)
result = Lerp(A, B, t')

Where Ease(t) is any non-linear mapping.

Best ways to do non-linear interpolation in Unreal Materials

1) Power curve (fast, simple, very common)

Use Pow to bias the curve.

Ease-in (slow start, fast end): Pow(t, k) with k > 1
Ease-out (fast start, slow end): 1 - Pow(1 - t, k) with k > 1
More intense curve: increase k

Nodes:

Pow
OneMinus (1-x)
ScalarParameter for k (e.g. CurvePower)

This is my go-to because it’s cheap and easy to art-direct.

2) Smoothstep / S-curve (soft transition)

Unreal has a SmoothStep material function (or you can build it).

Great for “soft” transitions and avoiding harsh changes
Also useful when your t comes from distance fields, masks, etc.

If you don’t see a SmoothStep node, search for:

Material Function: SmoothStep (or use built-in Saturate + polynomial style function)

3) “Ease” Material Function (if available in your version)

Unreal includes material functions for easing in many setups (often named things like Ease, CheapContrast, SmoothCurve, etc., depending on engine version/content).

Search in the material editor:

right click → type Ease
also try SmoothCurve / SCurve

If it exists, it usually lets you pick ease-in/ease-out and exponent.

4) Curve Atlas / 1D LUT (closest to ShaderGraph “gradient-as-curve”)

This is the exact equivalent of using a gradient to represent a curve.

Option A: 1D texture LUT (simplest)

Make a 256×1 texture where the red channel stores your curve
Sample it at t:
- t' = TextureSample(LUT, float2(t, 0)).r
Then feed t' into Lerp

Pros: super art-directable, any curve shape
Cons: needs a texture asset

Option B: Curve Atlas (more “Unreal official”)

Create a CurveFloat or CurveLinearColor
Put it into a Curve Atlas
Sample that in the material

More setup, but very powerful if you want editable curves in-editor.

Where to apply it (the important part)

Non-linear interpolation usually means you apply the curve to Alpha, not to A/B.

Example:

You have a mask / distance / UV gradient giving t
You want to change the “feel” of the blend:
- t' = Pow(t, CurvePower)
- Lerp(ColorA, ColorB, t')

Practical “softness” example (common in your kind of project)

If your t comes from distance and you want a controllable falloff:

Normalize distance to 0–1
Clamp: Saturate
Apply curve:
- Pow(t, FalloffPower) or SmoothStep(edge0, edge1, t)

This gives you that “softness” control like Unity.

Since you already have parameters like softness and you’re driving stuff from a manager:

✅ Start with Pow-based bias

Add a scalar parameter CurvePower (default 1)
Use:
- Pow(t, CurvePower) for ease-in
- 1 - Pow(1 - t, CurvePower) for ease-out

If you later want full art-directable curves, upgrade to a 1D LUT texture.

If you tell me what your t is (UV.x? distance to brush center? time?), I can suggest the exact node chain (and whether you want ease-in, ease-out, or an S-curve).

Sure — Curve Atlases are Unreal’s “official” way to drive materials from editable curves, without baking your own 1D LUT texture by hand.

Think of it like this:

You author a Curve in the editor (nice UI, keys, tangents).
Unreal bakes that curve into a lookup texture inside a Curve Atlas.
Your material samples the atlas at t (0–1) to get a value (float or color).
You can swap which curve to use via a row parameter (so different instances can use different curves).

This is basically “gradient-as-curve” but formalized.

What assets are involved

1) `CurveFloat` (outputs a single float)

Use this for non-linear interpolation curves (EaseIn, EaseOut, custom falloff, etc.).

2) `CurveLinearColor` (outputs RGBA color)

Use this if you want a “color over time/value” curve (or multiple channels at once).

3) `Curve Atlas`

A container that holds many curves and bakes them into a texture for materials.

Step-by-step setup (editor)

Step 1 — Create a curve

Content Browser → Add (+)

Miscellaneous → Curve → Curve Float (or Curve Linear Color)

Open it and author your curve:

X axis is “input” (usually 0→1)
Y axis is the output value (for CurveFloat typically 0→1, but it can be any range)

Example for “ease in”:

point at (0,0)
point at (1,1)
shape it concave/convex with tangents

Step 2 — Create a Curve Atlas

Content Browser → Add (+)

search “Curve Atlas” and create it

Open the Curve Atlas:

Add your curve(s) to it (you’ll see them appear as “rows” in the atlas)

Each curve becomes a selectable row.

The atlas bakes curves into a texture behind the scenes so materials can sample them fast.

Sampling it in a Material

There are two common “material-side” workflows; naming varies slightly by UE version, but the concepts are the same:

A) Sample the atlas directly (the usual way)

In the Material Editor:

Right-click, search for Curve Atlas nodes.
Add:
- CurveAtlasRowParameter (lets you pick which curve row / expose it to instances)
- A CurveAtlas sample node/function (sometimes appears as a material function like “CurveAtlas” / “Sample Curve Atlas”)

Then you feed:

Atlas (the Curve Atlas asset)
Row (which curve)
Input T (your 0–1 value)

Output:

If it’s a CurveFloat: typically you’ll read a single channel (often R)
If it’s CurveLinearColor: you get RGBA color

If you don’t see obvious nodes: look in Material Functions for “CurveAtlas” or “SampleCurveAtlas”.

How you use it for non-linear interpolation

You take your linear t, sample the curve, and use the result as your Lerp alpha:

t_curved = SampleCurveAtlas(t)
Result   = Lerp(A, B, t_curved)

Where t might be:

distance remapped to 0–1
UV.x
time
your scalar parameter

Making it editable per Material Instance (the good part)

The “row parameter” is what makes it powerful:

Create a Material Instance of your base material
In that instance, you can choose which curve row to use (without recompiling)

So you can have:

one material instance with “soft falloff”
another with “hard edge”
another with “ease-in-out”

All using the same shader.

Blueprint control

You typically don’t drive the curve keys at runtime (curves are editor assets), but you can:

Swap the selected row (by setting the parameter on a Dynamic Material Instance)
Drive the input t at runtime (the thing you sample with)

So runtime control usually looks like:

t changes every frame
curve stays the same (but you can swap which curve row is used if needed)

When Curve Atlas is the right choice

Use it when:

you want a designer-friendly curve editor
you want precise custom shapes beyond Pow/Smoothstep
you want to standardize curves across many materials
you want easy swapping via material instances

If you just need “bias the blend,” Pow is simpler. If you want “this exact curve shape,” atlas is excellent.

One practical caveat

Curve Atlas sampling is still cheap (it’s just a texture lookup), but it’s a bit more setup than Pow. For your use case (projection experience + tweakability), it can be a great workflow.

If you tell me your Unreal version (UE 4.27 / 5.0 / 5.1+ etc.), I can name the exact nodes you’ll see in your Material Editor (they changed slightly across versions), and I can describe the exact mini-graph to wire it into your current ColorA/ColorB blend.

To add curves to a Curve Atlas you do it inside the Curve Atlas asset editor (not from the material).

Steps

Create / open your Curve Atlas
- In the Content Browser: right-click → Miscellaneous → Curve Atlas
- Double-click it to open.
In the Curve Atlas editor, find the Curves panel (often a Details panel section called Gradient Curves).
- You’ll see an array/list for curves.
Click the + (Plus) icon to add a new element/row.
For the new row, click the dropdown / asset picker and select your curve asset (typically a CurveLinearColor “gradient curve”). citeturn0search0

That’s it — each curve you add becomes a row in the atlas lookup texture. citeturn0search0

Drag & drop shortcut

In many UE versions you can also:

drag the curve asset(s) from the Content Browser
and drop them into the Curves list in the Curve Atlas editor

(If it doesn’t work in your version, use the + array method above.)

Important note about curve types

Curve Atlases for materials are built around “Gradient Curves” (i.e., CurveLinearColor). citeturn0search0
If you made a CurveFloat for easing, you can still use the system, but commonly you’d either:

use a CurveLinearColor and put your float in the R channel (R=G=B), or
just use a 1D LUT texture for a float curve.

If you tell me your UE version and whether you’re aiming for float easing or color gradient, I’ll tell you the cleanest “curve asset type” to use.

Perfect — UE 5.5.x is actually quite clean for this once you know where Epic hid the UI. Here’s the exact, concrete workflow for UE 5.5.4, no hand-waving.

Curve Atlas in UE 5.5.4 — Step by Step

1️⃣ Create the correct curve asset (important)

For material use, Unreal expects Curve Linear Color (even if you only want a float curve).

Content Browser → Right-click → Miscellaneous → Curve → Curve Linear Color

Name it something like:

CLC_Ease_Soft

Author the curve

Open the curve
X axis = input (usually 0 → 1)
Y axis = output (0 → 1)
Set R = G = B (keep them identical if you want a single float curve)
Alpha can be ignored

This is your “non-linear interpolation function”.

2️⃣ Create the Curve Atlas

Content Browser → Right-click → Miscellaneous → Curve Atlas

Name it:

CA_InterpolationCurves

Open it.

3️⃣ Add curves to the atlas (this is the part you asked about)

Inside the Curve Atlas editor (UE 5.5.4):

Look at the Details panel on the right
Find the section called Gradient Curves
Click the + button
A new row appears
In that row:
- Assign your CLC_Ease_Soft curve asset
- Optionally rename the row (e.g. SoftEase)

You can add multiple curves:

Soft
Hard
EaseIn
EaseOut
Custom shapes

Each one becomes a selectable row.

💡 You cannot add CurveFloat here directly — the atlas expects CurveLinearColor.

4️⃣ Use the Curve Atlas in a Material (UE 5.5.4 nodes)

Open your material.

Add these nodes:

CurveAtlasRowParameter
- This exposes which curve row to use in material instances
- Assign:
  - Curve Atlas → CA_InterpolationCurves
  - Default Row → e.g. SoftEase
CurveAtlas Sample
(Search for “CurveAtlas” in the material editor)

You will see a node/function similar to:

CurveAtlas Sample

Inputs:

Curve Atlas
Curve Row
Input Time / T (your 0–1 value)

5️⃣ Wiring for non-linear interpolation

This is the key pattern you’re after:

Linear T (0–1)
 → CurveAtlas Sample
 → Take R channel
 → Lerp Alpha

Example:

T = distance normalized to 0–1
Sample curve → output T'
Lerp(ColorA, ColorB, T')

This is exactly equivalent to using a Gradient as a curve in Unity Shader Graph.

6️⃣ Material Instance workflow (this is why it’s powerful)

Create a Material Instance:

You’ll see the Curve Row parameter
You can switch between curves without recompiling
Perfect for art-direction and presets

When to use this vs Pow()

Use Curve Atlas when:

You want precise control
You want to visually edit the curve
You want multiple curve presets
You want designers to tweak without touching math

Use Pow / SmoothStep when:

You just want a bias
You want the cheapest possible solution
You don’t need exact shapes

Performance (important reassurance)

Curve Atlas sampling:

✅ Is just a texture lookup
✅ Is very fast
❌ Is NOT why your editor lags
❌ Is NOT expensive compared to Tick logic or material instance creation

You are safe using it.

Mental model (lock this in)

Curve Atlas = Unreal’s official “curve → material” bridge
It’s a LUT generated from editor-editable curves.

If you want, next I can:

wire this directly into your current ScaleByMat setup, or
show how to drive the curve from Blueprint parameters cleanly, or
explain when to use CurveFloat + Timeline instead of a material curve.

Just tell me which one.

Good catch — you do NOT have to manually keep multiple channels in sync by hand unless you want to. Let me clarify what I meant and give you the cleanest workflow.

What I meant by “R = G = B”

You have two valid options when using CurveLinearColor as a float curve.

Option A (recommended): Edit only ONE channel

In UE 5.5.4, you can:

Use only the Red channel
Ignore G, B, A completely

In the material:

Sample the Curve Atlas
Take .r output
Use that as your curved t

You do not need G and B to match.

So you do NOT need to manually sync them.

Option B (rarely needed): Lock channels together

Only do this if you explicitly want RGB behavior.

In the Curve Editor:

Select all keys
Copy / paste between channels
Or manually edit with same values

But again — this is unnecessary for easing.

The correct mental model

Think of CurveLinearColor as:

“Up to 4 independent float curves packed into one asset.”

You are simply using one of them (Red).

Exact workflow (clean & minimal)

1️⃣ Create CurveLinearColor

Edit Red channel only
X: 0 → 1
Y: 0 → 1 (or any shape you want)

Leave other channels alone.

2️⃣ Add it to Curve Atlas

Atlas doesn’t care which channel you use
It just bakes the curve into a texture

3️⃣ Sample in Material

Use CurveAtlasRowParameter
Sample the atlas
Take R output
Feed it into Lerp Alpha (or wherever)

Why Unreal does it this way

Unreal uses CurveLinearColor because:

GPU wants RGBA textures
Curve Atlas is literally a texture
Multiple curves can be packed efficiently

You’re not expected to think of it as “color”.

TL;DR (important)

❌ You do not need to manually sync channels
✅ Just edit Red
✅ Sample Red in the material
✅ Use that as your non-linear interpolation

If you want, next I can:

show you a minimal material graph using the atlas, or
explain how to expose curve selection cleanly to Blueprint (Material Instance vs DMI).

In UE materials you don’t “pass” a Curve Atlas from Blueprint the way you’d pass an object reference in Unity. Instead, you bind the Curve Atlas inside the material graph, and then you can expose which row (which curve) to use as a parameter.

Here’s the practical workflow in UE 5.5.4:

1) Assign the Curve Atlas in the material (the “pass” step)

Open your Material (not the instance).
In the graph, Right-click and search for:
- CurveAtlasRowParameter
Place it.
Select that node and look in the Details panel:
- Set Curve Atlas = your CA_Whatever
- Set Default Row Name = one of the curves you added (row) in the atlas

That’s it: the material now “knows” which atlas it’s sampling from.

Key point: the atlas reference is usually hard-assigned in the material node, not fed in at runtime.

2) Sample the atlas and use it

Add the sampling node/function:
- Right-click → search “Curve Atlas” / “Sample Curve Atlas”
- In many setups it appears as a material function/node that takes (Atlas, Row, Input)
Wire:
- Row input ← the output of CurveAtlasRowParameter
- Input ← your t (0–1) value
Use the sampled output:
- For “float curve”, take Red channel (.r)
- Plug into Lerp Alpha (or whatever you’re remapping)

So the pattern is:

t_linear → sample curve → t_curved → Lerp alpha

3) How you control it per instance (most common)

Create a Material Instance of that material:

In the instance parameters you’ll be able to choose the Row (because it’s a Row Parameter).
You can swap curves without recompiling the material.

This is the usual way to “pass” different curves around in Unreal: swap the row in a Material Instance.

4) Can you change the Curve Atlas itself at runtime?

Usually: not in a clean/normal way.

Unreal’s Curve Atlas reference is intended to be set in the material graph.
At runtime you typically change:
- the Row
- the Input t
- or you swap the entire material/material instance if you need a totally different atlas.

If you truly need “runtime arbitrary curve injection”, the simpler GPU-friendly way is: ✅ use a 1D LUT texture parameter instead (TextureObjectParameter), because textures are easy to swap dynamically.

Quick checklist

✅ Curve Atlas assigned in CurveAtlasRowParameter node (material details)
✅ Row is controllable in Material Instance
✅ Sample output .r is your eased value

If you show me a screenshot of your material graph (or tell me what node name you see for sampling in 5.5.4), I can tell you exactly which pins go where and what the cleanest setup is for your current “ColorA/ColorB + interpolation” material.

Great, the image helps a lot 👍
What you’re trying to do is very normal in Unreal, but the idiomatic way is different from Unity’s “enable/disable GameObjects”.

I’ll give you a clean Unreal-native pattern that will feel logical once it clicks, and I’ll explicitly map it to how you’d do it in Unity.

The core Unreal difference (important mindset shift)

In Unity:

GameObject = visual + logic
Enable/disable GameObject = everything on/off

In Unreal:

Actor = container / identity
Mesh Component = visual
Actor Component = logic
Visibility and “enabled state” are separate concerns

So instead of toggling “the thing”, you usually:

swap the mesh
or swap which actor is active
or enable/disable logic, not the actor

The cleanest solution for your case (recommended)

✅ Pattern: One Tile Actor, swap the Mesh

This is the closest mental match to Unity and the most efficient.

Structure

BP_TileSurfaceActor (Actor)
 ├─ StaticMeshComponent (TileMesh)
 └─ BP_ScaleByMatComponent (your scaling logic)

How it works

Import multiple FBX tile arrangements
Assign them as Static Mesh assets
Your manager tells the Tile Actor:

“Use Mesh A” / “Use Mesh B”

Your scaling logic:

stays the same
keeps the same material
keeps the same texture-driven scale logic

Blueprint nodes

From your Manager:

TileActor → TileMesh → Set Static Mesh (NewMesh)

This is:

cheap
instant
editor-friendly
no actor spawning/destruction

Unity analogy

meshFilter.mesh = newMesh;

Alternative patterns (when you’d use them)

Option B — Multiple Tile Actors, toggle visibility

If different tile arrangements:

have different transforms
different origins
or different component setups

Setup

Place multiple BP_TileSurfaceActor in the level
Manager keeps an array of them

Switching

For each TileActor:
  Set Actor Hidden In Game (true)
TargetTileActor:
  Set Actor Hidden In Game (false)

Also disable logic:

ScaleByMatComponent → Set Component Tick Enabled (false)

Unity analogy

go.SetActive(false);

But in Unreal you split it into:

visibility
ticking
logic enablement

Option C — Spawn / destroy actors (least recommended for your case)

Good for:

procedural worlds
streaming
memory-heavy assets

Not ideal for an experience / projection setup.

What NOT to do (Unity instincts to avoid)

❌ Toggling Actor Tick to mean “active/inactive”
❌ Destroying and respawning meshes every time
❌ Rebinding materials every frame
❌ Recreating Dynamic Material Instances on switches

How your scaling component should be written

Your BP_ScaleByMatComponent should:

not care which mesh it’s operating on
operate on:
- a StaticMeshComponent reference
- or its owner’s primary mesh

Example inside the component:

Owner → Get Component by Class (StaticMeshComponent)
 → Cache it
 → Apply scaling/material params

Then swapping meshes “just works”.

Final recommendation (best practice)

Given your description and image:

✅ One Actor

with one StaticMeshComponent
swap the StaticMesh asset

✅ One scaling component

cached mesh reference
material logic untouched

This is:

fast
clean
Unreal-native
very similar to Unity once you adjust the mental model

If you want, next I can:

help you refactor your current component so it’s mesh-agnostic, or
show how to expose a StaticMesh parameter to your manager cleanly, or
explain when Hierarchical Instanced Static Mesh would be better for tile grids like this.

Good — the screenshot shows the exact situation: you imported the FBX “as an FBX Scene / actor”, so you now have an FbxScene_* actor with hundreds of child StaticMeshComponents (Object_1, Object_10, etc.). That import mode is great for preserving hierarchy, but it’s not the best shape if you want “swap one arrangement for another” like Unity.

So when I said “import multiple FBX arrangements”, I meant: import multiple FBX files into the Content Browser as assets, and then have one Tile Actor in the level that can switch which mesh(es) it uses.

Right now you’ve got:
✅ a placed actor (the FBX scene actor) + a component attached
…but that actor is a big hierarchy, not a single mesh you can swap easily.

Below are the two clean ways to get to Option A depending on what your FBX actually contains.

First: what is your “tile arrangement” really?

From the screenshot it looks like the FBX is many separate meshes (each tile as its own object). If that’s true, you have 2 good routes:

Route 1 (best for performance + swapping): Convert to (H)ISM or merge

Convert all those tile pieces into a single representation you can swap:
- either Merged Static Mesh (one mesh)
- or Hierarchical Instanced Static Mesh (best if they’re repeated tiles)

This makes swapping “Arrangement A → Arrangement B” easy and fast.

Route 2 (keep the hierarchy): Swap by hiding whole actors

Keep each FBX Scene as its own actor in the level and toggle visibility/tick.
This is more Unity-like but heavier if you have many.

Given you’re driving a texture-based scale effect, Route 1 is usually the “clean Unreal” solution.

Option A, Unreal-style (single Tile Actor you control)

What changes compared to your current setup?

Instead of attaching your component to the imported FbxScene_* actor, you create your own actor:

✅ BP_TileSurface (your “one thing”)

Contains either:
- one StaticMeshComponent (if merged)
- OR one HISM component (if instanced tiles)
Has your ScaleByMat component
Exposes a function like: SetArrangement(ArrangementAsset)

Then your manager references BP_TileSurface (typed) and tells it what to display.

So do you import multiple FBXs “into the level”?

No — not necessarily.
You import them into the Content Browser as assets, and place only one actor in the level that can swap what it uses.

However, with your current FBX Scene import, you can’t just “Set Static Mesh” because it’s not a single mesh — it’s a hierarchy of many components.

✅ Recommendation A: Re-import / convert to something swappable

Pick one of these:

A1) If the tiles are all the same mesh repeated:

Use Hierarchical Instanced Static Mesh (HISM)

One component draws thousands of tiles efficiently
You can still animate per-instance scale if your material uses world position / texture mapping (often good enough)
You can swap arrangements by swapping instance transforms

A2) If it’s unique geometry and you just want it as one object:

Merge the FBX scene into one Static Mesh

In editor: select the components → “Merge Actors” (or similar tool) → create merged mesh asset
Then your BP_TileSurface can simply Set Static Mesh

This gives you the clean “Option A” swap.

✅ Recommendation B: Keep your current FBX Scene actors, and just switch which one is active

This is the easiest short-term and very Unity-like.

Setup

Place ArrangementA actor (FbxScene_A)
Place ArrangementB actor (FbxScene_B)
Each has your scaling component (or you apply scaling through material params globally)

Switching (manager)

When switching:

Hide all arrangements:

Set Actor Hidden In Game(true)
Set Actor Enable Collision(false) (optional)
Set Actor Tick Enabled(false) (optional, not always needed)

Show the chosen one:

Hidden In Game(false)
Tick Enabled(true)

Bonus: also disable the scaling component tick on the inactive ones:

ScaleByMatComponent → Set Component Tick Enabled(false)

This is “Unity SetActive” but split across a few nodes.

The big question: does your component operate on “the actor’s mesh”?

Right now you’ve attached your component to the FbxScene_* actor. But that actor contains many mesh components.

So your scaling component needs to either:

iterate through all child mesh components and apply material params, or
work via something global like a Material Parameter Collection (MPC), so you don’t care which actor is active.

🔥 Best architecture for your use case:

Material Parameter Collection (MPC) if:

the scaling effect is purely in the material (driven by texture + a few scalars/colors)

Then your manager sets MPC values once, and whichever arrangement is visible “just uses it”. No per-actor component needed at all.

This is extremely clean for projection experiences.

What I need from you to choose the best path (no long back-and-forth)

Just answer these two (quick) things:

In your FBX, are the tiles separate objects (looks like yes) or is it actually one mesh?
Is your scaling effect implemented entirely in the material (scale via WPO etc.), or are you scaling transforms of individual tiles?

With those two answers, I can tell you:

whether you should use Merged Mesh, HISM, or MPC + visibility switching
and the clean Blueprint structure for it.

Good instinct to question that — if each arrangement is thousands of unique meshes and you truly need to “scale each tile independently” (as transforms), then yes: naïvely “swapping” could mean touching thousands of components, and that’s exactly what you want to avoid.

The reason Route 1 can be more efficient is not “because swapping is free” — it’s because it lets you stop managing thousands of separate render components and instead push the variation to either:

GPU instancing (when tiles repeat), or
one merged draw + shader-driven per-tile motion (when tiles are unique)

Let’s make this concrete.

Why thousands of separate meshes is expensive in Unreal

When you import an FBX scene like your screenshot (FbxScene_* with Object_1 … Object_1000), you end up with:

thousands of StaticMeshComponents
each component has transform, bounds, render state, attachment, etc.
toggling visibility / tick / materials can cause the renderer to rebuild a lot of state
stopping PIE often hitches because the editor has to tear down a huge object graph (GC + render proxies)

So even if the GPU can render them, the CPU/editor overhead of “thousands of components” is the killer.

Key question: what does “scale individually” mean?

There are two meanings:

A) “Each tile has its own transform scale”

That implies you need per-tile transforms.

B) “Each tile appears to scale based on a texture”

That can be done in the material (WPO / vertex displacement), without changing transforms.

From your earlier message (“animating the scale … based on an underlying texture”), it sounds like B, which is great — because B is the path to efficiency.

If your effect is shader-driven (recommended)

You do not need a separate mesh component per tile to get per-tile variation.

Instead you make the tiles look like they scale individually by doing the scaling in the material, driven by:

world position / UVs
a mask/texture
a per-tile “ID” or “center” encoded in vertex data (UV2 / vertex color) if needed

Why that’s more efficient

you can merge the whole arrangement into 1 mesh (or a few chunks)
you render it in very few draw calls
“switch arrangement” becomes: swap the static mesh asset (1 operation), not 10,000 operations
your manager updates a few scalar/vector params, not thousands

This is the closest Unreal equivalent to “GPU doing the work.”

If you truly need per-tile transform scale (harder)

If tiles are not the same mesh, you cannot instance them as one ISM/HISM.

In that case, you have two realistic strategies:

Strategy 1: Group by mesh type (often possible even if “not the same”)

Sometimes “not the same” really means “a few variants”.

If you have, say, 20–200 unique tile meshes, you can create:

one ISM/HISM component per mesh type
add thousands of instances across those components

Then “per-tile scaling” is doable via:

Per-Instance Custom Data (drives scale in material)
or updating instance transforms (heavier but still better than thousands of components)

This is a huge win vs 10,000 separate components.

Strategy 2: Accept separate components, but don’t swap by reassigning meshes

If every tile is unique and you must transform-scale them:

Don’t “swap arrangements” by changing thousands of meshes at runtime.
Instead: keep arrangements as separate actors and toggle whole actors (Hidden In Game), and disable tick on inactive ones.
Still heavy, but you avoid rebuilding mesh assignments constantly.

So: “Will I be swapping thousands of meshes per arrangement?”

You shouldn’t. That’s the whole point.

Best outcome

You swap one merged mesh (or a few chunks), and the “individual scaling” is done by the material.

Next best

You swap instance data (transforms/custom data) on a small number of ISM/HISM components.

Worst

You swap thousands of individual StaticMeshComponents.

Given:

“thousands of tiles”
“scale based on an underlying texture”
projection/experience (not gameplay)
UE editor hitching issues

✅ Aim for material-driven per-tile scaling + merged meshes (or chunked merges).

Then your manager just:

selects which mesh asset is active (arrangement A/B)
updates material params / MPC
done

Quick diagnostic: which path are you on?

Answer this and I’ll tell you the exact best architecture:

When you say “scale each tile individually”, are you:

actually scaling each tile’s transform, OR
using World Position Offset / material math to make tiles appear to scale?

If it’s (2), you’re very close to a highly efficient setup. If it’s (1), we’ll talk about grouping by mesh type / ISM strategies.

Perfect — that means you’re in the good case. If the “scaling” is purely shader-driven (WPO / material math) then you do not need to scale transforms per-tile, and you can structure this in a way that’s both Unity-simple and Unreal-efficient.

Here’s the clean approach:

Best architecture for you

1) Stop driving per-arrangement via a component on the FBX scene actor

Instead, drive the effect via either:

✅ Option A (best): Material Parameter Collection (MPC)

Your manager sets global parameters once, and any mesh using that material updates automatically.

Why it’s great

No need to hold references to thousands of mesh components
No need to create/copy DMIs for every object
Switching arrangements is just visibility
Very low overhead, very stable in editor

Manager does:

Set Scalar Parameter Value (MPC) (e.g. ScaleMin/ScaleMax/Radius/Softness)
Set Vector Parameter Value (MPC) (ColorA/ColorB)

All meshes with a material that reads the MPC will respond.

✅ Option B: One DMI per arrangement actor (acceptable)

If you need different params per arrangement, you can keep a DMI per arrangement, but create it once and assign it to all child mesh components once.

MPC is still cleaner unless you truly need different params simultaneously.

2) Switching arrangements: Unity SetActive equivalent in Unreal

If each arrangement is a big FBX scene actor, the easiest is:

Hide/show whole arrangement actors

In Manager:

For all arrangement actors:
- Set Actor Hidden In Game(true)
- Set Actor Enable Collision(false) (optional)
For selected arrangement:
- Set Actor Hidden In Game(false)
- Set Actor Enable Collision(true) (optional)

That’s your SetActive() equivalent.

Note: This doesn’t disable their components’ render state entirely like Unity, but Hidden In Game is the correct render toggle.

The big performance warning (this likely relates to your editor hitch)

You said: “scaling is happening purely in shader from a dynamic instanced material.”

The common major mistake is:

Creating Dynamic Material Instances repeatedly (on tick, or per swap), or creating one per tile and updating them.

Best practice

If you use MPC: 0 DMIs needed
If you use DMIs: create once per arrangement (or per material slot), then reuse forever

Recommended concrete setup (do this)

Step 1 — Convert your material params to MPC

Create Material Parameter Collection: MPC_Tiles
Add scalars/vectors:
- TileScaleMin, TileScaleMax, Radius, Softness, etc.
- ColorA, ColorB
In your material:
- Replace Scalar/Vector parameters with Collection Parameter nodes reading from MPC_Tiles

Now the manager can drive everything globally.

Step 2 — Manager updates MPC (no Tick unless needed)

When values change → call UpdateParams
In UpdateParams:
- Set Scalar Parameter Value (Collection)
- Set Vector Parameter Value (Collection)

Step 3 — Switching arrangements

Keep an array of arrangement actors (your FbxScene_* actors). When switching:

hide all
show the chosen one

No mesh swapping, no component crawling, no DMI assignment loops.

Why this is more efficient

You avoid iterating thousands of components to set parameters
You avoid thousands of DMIs (huge memory + GC + stop-PIE hitch)
Renderer state changes are minimal
The GPU does the scaling, as intended

Quick check: are you accidentally making one DMI per tile?

If yes, that’s very likely why Unreal hitches when stopping.

A fast test:

Search your blueprints for Create Dynamic Material Instance
If it’s called inside a loop over tiles, or called often, that’s the smoking gun.

TL;DR

Since your scaling is shader-only:

✅ Use MPC for parameters
✅ Toggle whole arrangement actors with Hidden In Game
❌ Avoid per-tile DMIs and per-tick object iteration

If you want, paste/screenshot the part where you create/assign the Dynamic Material Instance, and I’ll tell you if it’s the “one DMI per tile” trap and how to restructure it cleanly.

Cool — Option B is totally workable, and you can implement it cleanly without rewriting your shader logic. The goal is:

3 arrangement actors in the level (FbxScene_A, FbxScene_B, FbxScene_C)
each arrangement gets one Dynamic Material Instance (per material slot) created once
that DMI is assigned to all mesh components in that arrangement once
your Manager can:
- switch which arrangement is visible
- push params into the active arrangement’s DMI (or into all three if you want)

Below is a step-by-step Blueprint plan.

Step 0 — Decide where the “arrangement logic” lives

Create a Blueprint Actor to represent one arrangement, so your manager doesn’t have to deal with raw FbxScene_* actors.

Create: `BP_TileArrangement`

Parent class: Actor

Components

(Optional) a SceneComponent root (default)
You do not need to manually add thousands of mesh components here — you’ll reference the imported actor.

Variables (Instance Editable)

ArrangementRoot : Actor reference
(this will point to your placed FbxScene_* actor in the level)
BaseMaterial : Material Interface (optional, if you want to override)
DMIs : array of Material Instance Dynamic (runtime cached)
MeshComponents : array of StaticMeshComponent (runtime cached)

Functions

Initialize()
ApplyParams(ScaleMin, ScaleMax, ColorA, ColorB, Radius, Softness, …)
SetActive(bool bActive)

Step 1 — Place your three imported arrangements

In the level you already have things like:

FbxScene_HexStars_A
FbxScene_HexStars_B
FbxScene_HexStars_C

(Each is that big FBX hierarchy actor.)

Step 2 — Place three `BP_TileArrangement` actors

Place:

BP_Arr_A
BP_Arr_B
BP_Arr_C

In each one’s Details:

Set ArrangementRoot to the corresponding FbxScene_* actor.

This is your Unity “wrapper” around each arrangement.

Step 3 — Implement `Initialize()` in BP_TileArrangement

Goal: cache all mesh components + create DMIs once + assign.

Blueprint nodes (logic)

Initialize:

Validate

IsValid(ArrangementRoot) → if false, return

Get all static mesh components under that actor

ArrangementRoot → Get Components by Class (StaticMeshComponent)
- (If this node only works on “self” in your context, use:
  Get All Actors Attached / iterate children and collect their mesh components, but usually Get Components by Class works on an Actor ref.)
Save into MeshComponents

Create and assign a DMI You have two sub-cases:

Case A (simplest): all meshes use the same material (or you don’t care)

Take MeshComponents[0]
Get Material (Element 0) → call it Mat0
Create Dynamic Material Instance (Source = Mat0) → DMI0
Store DMI0 (in DMIs)
Loop MeshComponents:
- Set Material (Element 0, DMI0)

Case B (more correct): multiple material slots

For each material element index you need (usually 0, sometimes 0..N):

Create one DMI per slot
Assign per slot in the loop

Important: keep DMIs in an array by slot index.

Done.

✅ After this, your arrangement has stable DMI references and no more creation.

Step 4 — Implement `ApplyParams(...)`

This function just sets scalar/vector params on the cached DMI(s).

Example:

For each DMI in DMIs:
- Set Scalar Parameter Value (TileScaleMin, TileScaleMax, Radius, Softness…)
- Set Vector Parameter Value (ColorA, ColorB…)

No loops over thousands of meshes anymore. Only loops over DMIs (tiny).

Step 5 — Implement `SetActive(bActive)`

In this function, toggle the underlying arrangement actor:

If bActive == true:

ArrangementRoot → Set Actor Hidden In Game(false)
ArrangementRoot → Set Actor Enable Collision(false) (optional for experience)

If bActive == false:

ArrangementRoot → Set Actor Hidden In Game(true)

Optional extra: also disable any ticking logic you added elsewhere, but since your scaling is shader-only, visibility is enough.

Unity mapping:

HiddenInGame ≈ Renderer enabled
Collision toggle ≈ collider enabled

Step 6 — Manager setup

In your BP_TileManager (manager actor):

Variables

Arrangements : array of BP_TileArrangement references (Instance Editable)
ActiveIndex : int

BeginPlay

For each Arrangements[i]:
- Call Initialize()
- Call SetActive(false)
Set the default one active:
- Arrangements[0] → SetActive(true)
- Arrangements[0] → ApplyParams(current params)

Switch arrangement function

SetArrangement(Index):

Clamp Index
For each arrangement:
- SetActive(false)
Arrangements[Index] → SetActive(true)
Arrangements[Index] → ApplyParams(current params)
ActiveIndex = Index

That’s it.

Very important pitfalls (these cause editor hitch)

Do not create DMIs per mesh
- Create once per slot, assign to all meshes.
Do not re-run Initialize repeatedly
- Initialize once on BeginPlay (and optionally in Construction Script if you need preview, but careful).
Avoid looping thousands of components on Tick
- With the setup above you won’t.

Quick question that affects one step

Do your tiles use one material slot (Element 0 only), or do they have multiple materials per mesh?

If you don’t know, click one of the mesh components in the FBX actor and check “Materials” count in Details.
I can then tell you whether you should implement Case A or Case B in Initialize().

Yes — but a local one, and that distinction matters a lot.

Think of it like this (Unity mapping first, then Unreal):

The mental model (Unity → Unreal)

Unity

You would probably do something like:

One GlobalManager that decides which layout is active
Each layout is a Prefab with its own internal logic
The global manager just enables/disables prefabs and pushes parameters

Unreal (what we’re building)

BP_TileManager
→ global orchestration (which arrangement is active, global params)
BP_TileArrangement
→ self-contained controller for ONE arrangement
(knows how to find its meshes, assign DMIs, hide/show itself)

So yes:

BP_TileArrangement is a manager — but only for its own arrangement.

This is a very Unreal-idiomatic pattern and keeps things sane.

Why this extra “manager layer” is actually a good thing

Without BP_TileArrangement, your global manager would have to:

know about FBX scene hierarchies
iterate thousands of mesh components
know how many material slots there are
handle DMI creation and caching
handle visibility per arrangement

That would turn it into a god object.

By splitting responsibilities:

BP_TileManager (global)

High-level state (“Arrangement 2 is active”)
User input / cues / timeline
Global parameters

BP_TileArrangement (local)

Owns:
- its FBX actor
- its mesh components
- its DMIs
Knows how to:
- initialize itself
- apply parameters
- hide/show itself

Each class does one job.

This is normal Unreal architecture

Unreal expects you to:

wrap imported data (FBX scenes, meshes) in gameplay/logic actors
avoid putting logic directly on raw imported actors
compose behavior via actors + components

In other words:

The imported FBX actor is data.
BP_TileArrangement is behavior.

If you want an even more “Unity-like” framing

You can think of it as:

BP_TileArrangement ≈ Prefab root with scripts
ArrangementRoot (FbxScene_*) ≈ child GameObjects with renderers
BP_TileManager ≈ Scene Manager

Important reassurance

This is not over-engineering for Unreal.

It:

reduces editor hitching
keeps Blueprints readable
avoids per-frame or per-switch expensive loops
scales cleanly if you add more arrangements later

One last sanity check

You are not creating more managers at runtime. You will have:

1 global manager
N arrangement controllers (N = 3 in your case)

That’s totally fine.

If you want, next I can:

draw a one-screen architecture diagram (textual) for this setup, or
show how to refactor your existing component logic into BP_TileArrangement cleanly, or
explain how to later collapse this into MPC-only if you decide to optimize further.

Just tell me which one.

Not wrong at all. In fact, what you did is a very reasonable Unreal approach:

the FBX arrangement actor is “data / geometry”
your Actor Component is “behavior” (ScaleByMat)
your Manager drives parameters

That separation is good.

What’s not ideal is only this part:

the imported FBX Scene actor contains hundreds/thousands of StaticMeshComponents, so your component has to touch a lot of components (set materials, create DMIs, etc.).
If you do that often (or recreate DMIs), you’ll feel lag/hitches.

So: Actor Component on the arrangement is fine — you just want to make sure it’s implemented in an Unreal-friendly way.

Keep your current design (Option B) and make it clean

You can absolutely keep:

ScaleByMat Actor Component attached to each arrangement actor

…and then your global TILE_MANAGER just:

switches which arrangement is active
pushes parameters into the active arrangement’s component

No need to add BP_TileArrangement if you don’t want another wrapper actor. The wrapper was just to keep the manager clean, but it’s optional.

The “right” way to do it with your existing component

1) Each arrangement has its own ScaleByMat component

You already have this (circled in your screenshot). Good.

2) ScaleByMat caches everything once

Inside ScaleByMat component, on BeginPlay (or OnRegister):

gather all StaticMeshComponents under the owning actor
create DMIs once
assign the DMIs to those mesh components once
store the DMI(s) in variables

After that:

updating parameters should only call SetScalarParameterValue / SetVectorParameterValue on the cached DMI(s)
no loops over thousands of meshes during updates
no Create Dynamic Material Instance during updates

This is the big performance win.

3) Manager controls which arrangement is active

Manager holds:

an array of arrangement actor references (the FbxScene_* actors)
or directly an array of ScaleByMat component references (better)

Switching:

hide all arrangement actors
show the chosen actor
optionally disable component tick on inactive ones (if your component ticks)

So why did I suggest BP_TileArrangement earlier?

Only because raw FbxScene_* actors are messy to work with. A wrapper actor makes the editor + references nicer.

But if you’re comfortable: ✅ Keep the component on the arrangement actor
✅ Keep your manager separate
That’s totally legit.

The only time your current approach becomes “wrong”

If any of these are true:

❌ You create DMIs per tile, or repeatedly

If you run Create Dynamic Material Instance inside:

Tick
UpdateParams
or a loop that you call frequently

…you’ll get hitches and lag.

❌ You iterate thousands of components every time you change a value

If your manager slider changes ScaleMin and your component loops 5000 meshes to set material each time — that’s heavy.

Instead:

assign material once
then update only the DMI parameters

❌ You use Tick when you don’t need it

Tick is fine if you’re animating continuously, but if values change only on cues, make it event-driven.

A clean blueprint API (what your component should expose)

On your ScaleByMat Actor Component, create functions:

Initialize() (find meshes + create DMIs once)
ApplyParams(ScaleMin, ScaleMax, ColorA, ColorB, …)
SetActive(bool) (optional convenience: hide owner / disable tick)

Then Manager does:

On BeginPlay:
- call Initialize on all 3 components
On cue change:
- call ApplyParams on the currently active component
On arrangement switch:
- hide/show actors

Instead of your Manager referencing the arrangement actor, reference the component directly:

In Manager:

Arr1_ScaleByMat (type: your component class) – instance editable
Arr2_ScaleByMat
Arr3_ScaleByMat

This removes casting and searching.

You still hide/show the owner actor via:

GetOwner → Set Actor Hidden In Game

Bottom line

✅ Your idea (“component holds logic, arrangements just host it”) is solid.
Just ensure the component caches mesh refs + creates DMIs once, and your manager does event-driven updates, not per-frame loops over meshes.

If you show (or describe) where you create the DMI and how you assign it to the tiles, I can tell you immediately if you’re in the “one-time setup” safe zone or the “hitch-inducing” zone.

Yes — exactly. If your ScaleByMat component is already doing the “good stuff” (cache meshes once, create MIDs once, only set params on the MID), then the simplest, solid setup is:

Each arrangement is its own actor in the level (your FbxScene_* import)
Each arrangement actor has your ScaleByMat Actor Component attached
Your main manager just:
1. picks which arrangement is active
2. hides the others
3. pushes params to the active one (or to all, if you want consistency)

That’s the Unreal equivalent of your Unity “turn GameObjects on/off”.

Step-by-step for 3 arrangements (Blueprint-only)

1) In the level: place 3 arrangement actors

You’ll end up with:

FbxScene_Arrangement_A
FbxScene_Arrangement_B
FbxScene_Arrangement_C

Attach your ScaleByMat actor component to each (like you already did).

Tip: Give them clear names and/or a tag like Arrangement.

2) In your `TILE_MANAGER` Blueprint: store references

Create variables (Instance Editable) for clarity:

Option 1 (cleanest): store component references directly

ArrA_Scaler : ScaleByMat (Actor Component reference)
ArrB_Scaler : ScaleByMat
ArrC_Scaler : ScaleByMat

Then you can always get their owners to hide/show:

ArrA_Scaler -> GetOwner()

Option 2: store actor references

ArrA_Actor : Actor
ArrB_Actor : Actor
ArrC_Actor : Actor

Then you’ll do GetComponentByClass once. (Option 1 avoids this entirely.)

In the editor, you can’t pick components from the Outliner — so for Option 1 you’d typically:

drag the arrangement actor ref, then GetComponentByClass on BeginPlay and cache it (Unless you wrap them, but you said you don’t want that—totally fine.)

So practically you’ll likely do:

Manager stores actor refs (editable)
On BeginPlay → cache the ScaleByMat components for each actor

3) Manager BeginPlay: cache and initialize once

On BeginPlay (Manager):

For each arrangement actor:

Get Component by Class (ScaleByMat)
store into ArrX_Scaler
call Initialize (if you have such a function; otherwise let component BeginPlay do it)

Then set the initial active arrangement:

call SetArrangement(0) or similar

4) Switching arrangements (the “SetActive” equivalent)

Create a Manager function: SetArrangement(Index)

Inside:

Hide all:

ArrA_Actor -> Set Actor Hidden In Game(true)
ArrB_Actor -> Set Actor Hidden In Game(true)
ArrC_Actor -> Set Actor Hidden In Game(true)

Show selected:

SelectedActor -> Set Actor Hidden In Game(false)

Apply params to the selected component:

SelectedScaler -> ApplyParams(...)

Optional (if your component ticks)

If your component uses Tick for animation, also do:

Set Component Tick Enabled(false) on inactive scalers
Set Component Tick Enabled(true) on active scaler

If the scaling is purely shader-driven and you just push params, you may not need component tick at all.

What “enable/disable” means in Unreal (practical mapping)

Unity SetActive(false) roughly maps to a combo of:

Hide visuals: Set Actor Hidden In Game(true)
Stop CPU work: Set Actor Tick Enabled(false) (or component tick)
Disable interaction: Set Actor Enable Collision(false) (optional)

For your projection experience:

usually Hidden In Game + (optional) disable tick is enough.

One warning (small but important)

If you hide an arrangement actor, its components still exist — so don’t keep doing work on them. That’s why if any of your components tick, disabling tick on inactive ones is a good idea.

Bottom line

✅ Import each arrangement as its own actor + attach your component
✅ Main manager hides/shows and forwards params
✅ Disable tick on inactive arrangements if needed

If you want, tell me how you trigger arrangement changes (key press? MIDI? cues? UI), and I’ll show the cleanest SetArrangement blueprint graph layout (including safe IsValid checks and caching).

Yes — that’s the main way to stop your Actor Component from “running” when its arrangement is inactive if what you mean by “running” is Tick-based work.

✅ If your ScaleByMat component uses Event Tick

Do this on arrangement switch:

On the arrangement you’re deactivating:
- ScaleByMatComp → Set Component Tick Enabled(false)
On the arrangement you’re activating:
- ScaleByMatComp → Set Component Tick Enabled(true)

That prevents its Event Tick from firing.

Important nuance (Unreal specifics)

Disabling tick stops:

Event Tick
ReceiveTick logic
anything you do per-frame

It does not:

“turn off” the component completely
undo bindings or timers
stop latent actions you started elsewhere

So if your component also uses any of these, you should stop them too:

✅ If you use Timers

On deactivate:

Clear Timer by Handle (or Clear and Invalidate Timer…)

✅ If you use Timelines (inside the component)

On deactivate:

Stop the timeline

✅ If you bind to events / dispatchers

On deactivate:

Unbind (or guard inside the callback)

The simplest robust pattern

Add a bool in your component:

bIsActive

Make two functions on the component:

ActivateScaler()
DeactivateScaler()

Inside:

ActivateScaler:
- bIsActive = true
- Set Component Tick Enabled(true) (if you need tick)
DeactivateScaler:
- bIsActive = false
- Set Component Tick Enabled(false)
- stop timers/timelines if you use them

Then your manager just calls those functions.

Also hide the arrangement actor (separate concern)

Even if the scaler isn’t ticking, the mesh will still render unless you hide it:

ArrangementActor → Set Actor Hidden In Game(true/false)

So typical switch does both:

Hide/show actor
Enable/disable scaler tick

If your scaler is “purely shader driven”

If the component only:

sets MID parameters when the manager tells it to
and does nothing on tick

Then you don’t need tick toggling at all — just don’t call ApplyParams on inactive ones.

But if you’re seeing “it still runs”, it’s almost always because:

tick is enabled, or
timers/timelines are still active, or
you’re still calling it from the manager every frame

If you tell me what “running” means in your case (Tick? timeline? timer?), I’ll tell you the exact node(s) you should use to fully pause it.

Yes — that’s a totally valid (and often cleaner) solution. It turns your ScaleByMat component into a service that can “target” different arrangement actors. In Unity terms: one system + swap the target GameObject.

There are two big things to keep straight:

Your component must not assume GetOwner() is the arrangement anymore.
You need a safe/efficient way to retarget: cache meshes for the new arrangement, assign your MID(s), and stop touching the old one.

Below is a step-by-step blueprint-friendly way to do it, based on your graph.

What changes in your component

Right now you’re doing (circled in red):

GetOwner() → Get Components by Class (StaticMeshComponent) → set TileMeshes

That only works when the component is attached to the arrangement actor.

New approach

Add a variable to the component:

Variable

TargetActor : Actor reference (Instance Editable or set by Manager)
(optional) TargetTag if you want to auto-find

Then replace GetOwner() with TargetActor.

So your “Get Components by Class” becomes:

TargetActor → Get Components by Class (StaticMeshComponent)

Step-by-step implementation (recommended)

1) Put ONE `ScaleByMat` component on your Manager Actor

Manager actor in level: TILE_MANAGER
Add your Actor Component: ScaleByMat

Remove ScaleByMat from the arrangement actors.

2) Add a function to the component: `SetTargetActor(NewTarget)`

In your ScaleByMat component Blueprint, create a function:

`SetTargetActor(Actor NewTarget)`

Do:

If same target, return
- if NewTarget == TargetActor → return
Assign
- TargetActor = NewTarget
Rebuild caches for this target
- call CacheMeshesAndMaterials() (see below)
Apply current params
- call ApplyParams() (or whatever your “update MID params” function is)

This is your main “retarget” API.

3) Make caching target-based (your screenshot graph)

You currently:

clear MIDs
create a MID
then only if active, get components and set TileMeshes

Update this pattern

Create a function: CacheMeshesAndMaterials()

Inside CacheMeshesAndMaterials:

IsValid(TargetActor) → if false: return
TileMeshes = TargetActor → Get Components by Class (StaticMeshComponent)
Create MID(s) once (or reuse existing)
Assign MID(s) to the meshes (this is the only “big loop” and should happen only when target changes)

Important: don’t create a new MID every time if you don’t need to

You can keep one MID per material slot in the component and reuse it across targets, as long as all targets should share the same animated parameters.

If different targets need different materials, then you create per-target MIDs, but that’s more complex.

4) Manager switching logic becomes trivial

Manager keeps an array of arrangement actors:

Arrangements : Array<Actor>

When you want to switch:

Hide all
Show selected
ScaleByMatComp → SetTargetActor(SelectedArrangementActor)

This approach is good, but here are the tradeoffs

✅ Pros

Only one component to maintain
Switching arrangement becomes explicit: SetTargetActor
No duplicated components in the level
Easier to ensure only one thing is “running”

⚠️ Cons / gotchas

1) Retargeting can be expensive (but only on switch)

When you switch targets, you’ll likely loop over thousands of mesh components once to assign materials. That’s fine if you switch occasionally, but you don’t want to do it frequently.

2) Different arrangements might have different material setups

If some arrangements have different material slots / different base materials, your component needs to handle that.

3) You must stop using `GetOwner()` for mesh discovery

Owner is now the manager, not the arrangement.

How to make switching cheap (important optimization)

If you hide/show arrangements but want to avoid reassigning materials every time:

Strategy: “Initialize each arrangement once”

The first time you target an arrangement:
- cache its mesh list
- assign MID
Store that cache in a map:
- Map<Actor, CachedData> (in BP you can approximate using arrays or a struct array)

Then switching back to a previous arrangement doesn’t require scanning again.

If you don’t switch often, you can skip this complexity.

A simpler alternative (often best): Keep per-arrangement MIDs, but still only one “brain”

If you want switching to be instant and avoid reassignment:

Keep the MID assignment inside each arrangement once (your current working way)
But remove tick/logic duplication by making the component very thin, or use a shared function library.

But since you asked for a single component, your idea is absolutely viable.

Concrete changes to your screenshot graph

In the graph you posted:

Replace the circled GetOwner node with TargetActor variable
Add a guard:
- If TargetActor is invalid, do nothing
Don’t gate caching behind IsActive unless you really need it; instead:
- caching happens on SetTargetActor
- active state just controls tick/updates

Bottom line

✅ Yes, your “one component on manager + choose arrangement actor to read meshes from” is a solid design.
Just implement it as a retargetable component with a TargetActor variable and a SetTargetActor() function that re-caches and reassigns materials only on switch.

If you tell me how often you switch arrangements (rarely / sometimes / many times per second), I’ll tell you whether you should also add the “cache per arrangement so switching back is instant” optimization.

Great question — this is a very common Blueprint confusion, especially coming from C#/Unity where if is an expression and execution just “continues”.

The key mental shift

In Blueprints, a Branch is not like an if { } else { } block in code that then rejoins automatically.

A Branch is:

a fork in execution flow
it does not automatically rejoin

So what you’re seeing is expected behavior.

How to think about `if` in Blueprints

Unity / C#

if (needsReset)
{
    UpdateArrangement();
}
// execution continues here
SetMaterialParams();

Blueprint equivalent

You must explicitly rejoin the execution pins.

Correct Blueprint patterns (pick one)

✅ Pattern 1: Use a Sequence node (most common)

This is the cleanest and most readable.

Structure

Event Tick
 → Branch (NeedsReset)
     True  → UpdateArrangement
     False → (do nothing)
 → Sequence
     Then 0 → Set Material Params

But since Branch doesn’t rejoin, you do it like this:

Correct wiring

Event Tick
 → Sequence
     Then 0 → Branch (NeedsReset)
                 True → UpdateArrangement
     Then 1 → Set Material Params

Now:

UpdateArrangement runs only if true
Param updates always run

This matches your intent exactly.

✅ Pattern 2: Reset the bool immediately (what you tried)

If you really want a single branch:

Branch (NeedsReset)
 True:
   → UpdateArrangement
   → Set NeedsReset = false
   → Set Material Params
 False:
   → Set Material Params

This works, but:

more wires
easier to mess up
less readable

Sequence is cleaner.

✅ Pattern 3: Event-driven (best long-term)

Don’t put this logic on Tick at all.

Instead:

When arrangement index changes:
- set NeedsReset = true
- immediately call UpdateArrangement
- then call ApplyParams

No Tick, no Branch.

This is the most Unreal-native and efficient.

What you should do in your case (recommended)

Based on your screenshot:

Replace:

Event Tick → Branch(SwitchArrangement)

With:

Event Tick
 → Sequence
     Then 0 → Branch(SwitchArrangement)
                 True → UpdateArrangement
     Then 1 → Apply Material Params

And:

Set SwitchArrangement = false inside UpdateArrangement

This gives you:

“do this once when switching”
“always keep animating / updating”

Why your current setup feels wrong

You expected:

“After I run UpdateArrangement, continue as if branch was false”

Blueprints don’t do that implicitly — you must wire it.

Once you accept that execution flow is visual and explicit, Blueprint logic starts to feel predictable instead of weird.

Quick rule to remember forever

Branches don’t rejoin.
Sequences do.

If you want, I can:

redraw your exact graph with the correct nodes, or
show how to convert this whole thing to an event-driven version (no Tick, no Branch), which would be even cleaner for arrangement switching.

Absolutely — Sequence is one of the most important Blueprint flow-control nodes, and once it clicks, a lot of Blueprint logic suddenly makes sense.

I’ll explain it conceptually, visually, and with Unity comparisons.

What a Sequence node actually does

A Sequence node:

takes one execution input
fires multiple execution outputs
in order, left to right
every time it is executed

That’s it. No conditions. No logic. Just ordered execution.

Mental model (Unity / C#)

Think of a Sequence as this:

// Sequence
DoFirstThing();
DoSecondThing();
DoThirdThing();

Every time the Sequence runs, all of them run, in that order.

Blueprint visual model

[ Exec In ]
     |
  Sequence
   ├─ Then 0
   ├─ Then 1
   ├─ Then 2

When Exec In fires:

Then 0 fires
when that chain finishes, Then 1 fires
then Then 2, etc.

There is no branching — everything executes.

Why Sequence exists

Blueprints don’t have braces {} or block scopes like text code.

So Sequence gives you:

a way to say “do A, then B, then C”
without nesting wires everywhere
without duplicating logic

Sequence vs Branch (very important)

Branch (if / else)

Chooses one path
Does not rejoin
One of:
- True
- False

Sequence

Executes all paths
In a defined order
Always rejoins implicitly (because it never splits)

Your exact use case (why Sequence fixes it)

You want:

Sometimes update arrangement
Always update material params

Incorrect mental model (what you expected)

if (SwitchArrangement)
{
    UpdateArrangement();
}
// continue here
ApplyParams();

Correct Blueprint version

Event Tick
 → Sequence
     Then 0 → Branch (SwitchArrangement)
                 True → UpdateArrangement
     Then 1 → ApplyParams

Result:

If SwitchArrangement == true → arrangement updates
Params update every frame
No duplicated wires
No weird “branch doesn’t continue” issue

What Sequence is not

❌ It is not parallel
❌ It does not wait for async things
❌ It does not replace conditions

It is purely ordered execution.

Common mistakes (and fixes)

❌ Expecting Branch to continue

Branches don’t rejoin — you must explicitly wire continuation.

❌ Using multiple Branches instead of Sequence

If you have:

“sometimes do X”
“always do Y”

Use Sequence.

When NOT to use Sequence

Don’t use Sequence when:

you actually want mutually exclusive behavior → use Branch
logic should only run when something changes → use Events

Sequence is best for:

Tick logic
Initialization steps
“do this AND that” logic

One more useful trick

You can add more outputs:

Right-click Sequence → Add Pin

Very handy for setup code:

BeginPlay
 → Sequence
     Then 0 → CacheMeshes
     Then 1 → CreateMID
     Then 2 → ApplyParams

Clean, readable, no nesting.

TL;DR (remember this)

Branch = choose one path
Sequence = run all paths in order
Branches don’t rejoin — Sequences replace that need

If you want, send me your updated graph after using Sequence and I’ll sanity-check it for you.

Yep — logically this is correct. What you’ve built is the Blueprint equivalent of:

if (SwitchArrangement)
{
    UpdateArrangement();
    ApplyParams();
}
else
{
    ApplyParams();
}

So ApplyParams will run every tick, and when SwitchArrangement is true you also run UpdateArrangement first. ✅

Small improvement (to avoid duplicate nodes)

Right now you have two ApplyParams calls (one on True path, one on False path). That works, but it’s a bit redundant.

If you want to keep the Branch (no Sequence), you can still avoid duplication by “rejoining” the exec flow:

Option A: Rejoin with a reroute pattern

True → UpdateArrangement → ApplyParams
False → ApplyParams

You already have that.

Option B: Use a Sequence (cleaner) — but you said you don’t want it

Sequence would let you have only one ApplyParams node.

One important thing you still need

If SwitchArrangement is meant to be a one-frame trigger, make sure you reset it:

Inside UpdateArrangement, at the end:
- Set SwitchArrangement = false

Otherwise, it will keep re-running UpdateArrangement every tick forever.

Also: if you’re updating parameters every tick, that’s fine

Since you’re setting MID parameters, ticking is usually ok. But if the values only change occasionally, you can call ApplyParams only when they change.

Bottom line

✅ Your Branch setup is correct.
🔧 Just remember to set SwitchArrangement back to false after the switch, if it’s supposed to be a one-time action.

Yes — that’s exactly right.

`Set Actor Hidden In Game`

New Hidden = true → the actor will NOT be visible
New Hidden = false → the actor WILL be visible

Think of it as:

Hidden In Game = “invisible”

What this actually affects (important nuance)

When you set an actor hidden in game:

✅ What happens

All rendered components (Static Meshes, Skeletal Meshes, etc.) become invisible
The actor is no longer drawn

❌ What does not automatically happen

Tick is NOT disabled
Collision is NOT disabled
Actor still exists and can run logic

So if you want full “inactive” behavior (Unity SetActive(false) equivalent), you usually do:

Set Actor Hidden In Game(true)
Set Actor Tick Enabled(false)        // optional but recommended
Set Actor Enable Collision(false)    // optional

For your projection/experience:

Hidden In Game is the critical one
Tick disabling is only needed if the actor/component does work per frame

Very common pitfall (worth calling out)

People sometimes think:

“Hidden In Game means disabled”

It does not — it’s render-only.

You already have the right mental model now 👍

If you want, I can give you a tiny “Unity ↔ Unreal” cheat sheet for visibility / activation that you can keep handy while working.

There are two main ways to detect keyboard input in Unreal, and which one you should use depends on where you want the input handled. I’ll map this to Unity so it clicks quickly.

The Unreal way (important concept first)

In Unreal, keyboard input is owned by the Player Controller / Pawn by default, not by arbitrary actors or components.

So input works automatically in:

Pawn
Player Controller

For:

Actor
Actor Component

…you must explicitly enable input or route it.

✅ Recommended: Input via Player Controller or Pawn

This is the cleanest and most Unreal-idiomatic approach.

1️⃣ Create an input mapping (once)

Edit → Project Settings → Input

Under Action Mappings:

Add a new Action:
- Name: SwitchArrangement
- Key: e.g. 1 (or any key)

This is like Unity’s Input Manager.

2️⃣ Detect key down in Blueprint

In a Pawn or Player Controller Blueprint:

Right-click in Event Graph → search:

Input Action SwitchArrangement

You’ll get:

Pressed (key down)
Released (key up)

Example:

Pressed → TileManager → SetArrangement(0)

Unity equivalent

if (Input.GetKeyDown(KeyCode.Alpha1)) { ... }

✅ If you REALLY want to detect input in an Actor

(Useful for tools, managers, or quick tests)

Step 1 — Enable input

On BeginPlay in that Actor:

Enable Input
  Player Controller → Get Player Controller (0)

Step 2 — Use Key Event

Right-click in Event Graph → search:

Keyboard → 1

You’ll get:

1 (Pressed)
1 (Released)

⚠️ This works, but is not recommended for complex projects.

✅ Detect input in an Actor Component (advanced)

Actor Components cannot receive input directly.

Correct pattern:

Input happens in PlayerController / Pawn
That Blueprint calls functions on:
- Manager actor
- Components

Example:

PlayerController
 → On Key Pressed
 → TileManager → SwitchArrangement()

This matches your architecture perfectly.

Quick decision guide

Where you are	Correct method
Pawn / PlayerController	Input Action events ✅
Actor (manager)	Enable Input (ok for tools) ⚠️
Actor Component	Route input from controller ❌

Best setup for your project

Since you already have:

a Tile Manager
arrangement switching
projection / experience (not gameplay)

I recommend:

✅ Input in PlayerController
→ calls TileManager functions

This keeps:

input logic separate
manager reusable
no hidden “Enable Input” traps

Minimal example (clean)

PlayerController BP

Input Action NextArrangement (Pressed)
 → TileManager → SetArrangement(NextIndex)

If you want, I can:

show you the Enhanced Input version (UE5 modern system), or
give you a one-screen “Unity → Unreal input cheat sheet”, or
show how to quickly prototype input directly in your manager (safe setup).

Just tell me which.

Great question — this is exactly the right place to pause and wire things cleanly.
I’ll walk you through the correct Unreal-native way, step by step, and map it to Unity so it feels familiar.

First: clarify what your TileManager actually is

You said:

“my tilemanager which is an actor component”

So your setup is:

BP_TileManagerActor (Actor in the level)
- has a TileManager Actor Component attached (your logic)
Pawn (or PlayerController) handles input

That’s perfectly fine 👍

What we need is:

Pawn → TileManager Actor → TileManager Component

The core Unreal rule (important)

A Pawn never magically knows about arbitrary actors or components.

You must:

either assign a reference
or find it once and cache it

Exactly like Unity’s:

FindObjectOfType<TileManager>();

…but done explicitly and safely.

✅ Recommended solution (clean + explicit)

Step 1 — Give the Pawn a variable for the TileManager component

In your Pawn Blueprint:

Create a variable:

Name: TileManagerComp
Type: your TileManager Actor Component class
Instance Editable: ❌
Expose on Spawn: ❌

This is your cached reference.

Step 2 — Get the TileManager Actor once (BeginPlay)

On Pawn → BeginPlay:

Blueprint logic

Event BeginPlay
 → Get All Actors Of Class (BP_TileManagerActor)
 → Get (0)
 → Get Component By Class (TileManagerComponent)
 → Set TileManagerComp

Add safety:

Check array length > 0
IsValid before setting

This happens once, so it’s cheap.

Unity equivalent

tileManager = FindObjectOfType<TileManager>();

Step 3 — Use input to call the component

Now in the Pawn, add your input:

Input Action SwitchArrangement (Pressed)
 → TileManagerComp → SwitchArrangement()

You’re calling logic on the component, not the actor.

🔁 Alternative (even cleaner if you like editor wiring)

Option B — Assign via Instance Editable reference

If you don’t want Get All Actors Of Class:

In Pawn:

Create variable:
- TileManagerActor
- Type: BP_TileManagerActor
- Instance Editable = true

In Level:

Select Pawn
Drag your BP_TileManagerActor into that field

Then on BeginPlay:

TileManagerActor → Get Component By Class → Set TileManagerComp

This is 100% explicit and editor-friendly.

❌ What NOT to do

Just to reinforce good habits:

❌ Don’t put input logic inside the TileManager
❌ Don’t call Enable Input on random actors
❌ Don’t search for the manager every Tick
❌ Don’t assume GetOwner() will magically work

Final architecture (this is “the right way”)

Pawn / PlayerController
  └─ Handles input
     └─ Calls TileManagerComponent functions

TileManagerActor
  └─ Holds TileManagerComponent

TileManagerComponent
  └─ All arrangement + scaling logic

This is:

modular
testable
scalable
Unreal-idiomatic

One small quality-of-life tip

If you only ever have one TileManager in the level, consider:

tagging it with TileManager
using Get All Actors With Tag

It avoids hard class dependencies.

If you want, next I can:

show this exact setup with Enhanced Input (UE5 recommended),
or explain how to move input into PlayerController instead of Pawn (even cleaner for non-game experiences),
or help you expose Next / Previous Arrangement cleanly.

Just tell me 👍

A couple things jump out from your screenshot that would make this not fire at all:

you wired Released → Print String, not Pressed
the Blueprint you put this in may not be receiving input (common if it’s not the possessed Pawn/PlayerController)

Let’s fix it in the most reliable way.

1) Wire the correct pin

In your screenshot, the white exec wire comes from Released.

Connect Pressed → Print String

If you’re tapping quickly, Released should still fire, but start with Pressed to remove doubt.

2) Make sure the Blueprint is actually getting input

The input action event will only trigger in:

the possessed Pawn/Character, or
the PlayerController

If you put this node inside a random Actor or component, it won’t fire unless you explicitly enable input (which we’re avoiding “the right way”).

Quick test

Where is this graph?

If it’s in your Pawn, make sure that pawn is possessed.

3) Check possession & auto possess (most common issue)

If you’re using a custom Pawn in a level (experience projects often do), it might not be possessed.

In the level:

Select your Pawn actor
In Details → Pawn
- set Auto Possess Player = Player 0

OR set it globally:

Project Settings → Maps & Modes
- Default Pawn Class = your pawn

If the pawn isn’t possessed, it won’t receive input → your action won’t fire → no print.

4) Confirm the input mapping is correct

You’re using the legacy Input Action node (InputAction IterateArrangements), which requires:

Project Settings → Input
- Action Mappings:
  - IterateArrangements mapped to a key (e.g. Space, E, etc.)

Double-check it’s spelled exactly the same.

5) One more gotcha: UI can eat input

If you’re in a UI input mode (common in tools/experiences), keyboard input may be going to UI.

In PlayerController (or Pawn), you can temporarily test by forcing game input:

Set Input Mode Game Only
Show Mouse Cursor false (optional)

The fastest “make it work” recipe

Do this in your PlayerController Blueprint (most reliable):

Create/open your PlayerController BP
Put:
- InputAction IterateArrangements (Pressed) → Print String("Hello")
Ensure the GameMode uses that PlayerController
- Project Settings → Maps & Modes → Player Controller Class

This removes “pawn possession” as a variable.

Minimal checklist

✅ Pressed pin connected (not Released)
✅ Action Mapping exists + correct name + key assigned
✅ Blueprint is PlayerController or possessed Pawn
✅ Auto Possess Player 0 set (if using Pawn)
✅ Input isn’t being captured by UI

If you tell me which Blueprint this node is currently in (Pawn? PlayerController? TileManager Actor?), I’ll tell you the exact setting you need to flip to make it start firing immediately.

Got it — your Action Mapping exists and it’s bound to the I key, so the mapping itself is fine.

If your InputAction IterateArrangements event still isn’t printing, then it’s almost certainly one of these two issues:

That Blueprint is not receiving input (most common)
You’re running with Enhanced Input / a setup that doesn’t route legacy mappings (common in UE5 projects)

Let’s fix this quickly with the most reliable checks.

1) Make sure the event is in the right place

The node InputAction IterateArrangements (legacy input) will only fire in:

the possessed Pawn/Character, or
the PlayerController

If you placed it in:

your TileManager actor
an actor component
some random actor in the level

…it will not fire.

✅ Put the Print String test in your PlayerController BP or your Pawn BP that is actually possessed.

2) If it’s in your Pawn: ensure it’s possessed

In your level:

select your Pawn actor
Details → Auto Possess Player → set to Player 0

If you don’t have a pawn placed, set it in:

Project Settings → Maps & Modes
- Default Pawn Class = your pawn

If your pawn is not possessed, it won’t get input → no print.

3) You wired “Released” in the screenshot earlier

Just re-mentioning because it’s easy to miss:

connect Pressed → Print String

(Released should also fire, but Pressed is the clearest test.)

4) UE5.5 gotcha: Enhanced Input vs Legacy Input

Your screenshot shows the warning: Action/Axis mappings are deprecated.
Many UE5 templates use Enhanced Input and sometimes don’t route legacy input events the way you expect.

Easiest verification

Add this to your PlayerController:

Event BeginPlay → Set Input Mode Game Only

If you were in UI mode, this fixes “no keyboard input”.

The “works every time” solution in UE5.5: Enhanced Input (recommended)

If you want to do it the right UE5.5 way (and avoid this whole legacy confusion), do this:

A) Create assets

Create Input Action: IA_IterateArrangements
- Value Type: Boolean (or Digital)
Create Input Mapping Context: IMC_Default
- Add mapping: IA_IterateArrangements → key I

B) Add mapping context at runtime (PlayerController or Pawn BeginPlay)

In Blueprint:

Get Player Controller
Get Local Player
Get Subsystem (Enhanced Input Local Player Subsystem)
Add Mapping Context (IMC_Default, Priority 0)

C) Use the Enhanced Input event

In the Pawn/Controller:

Add event: IA_IterateArrangements
- use Triggered → Print String

This is the modern UE5 pipeline and it will behave consistently.

Fast diagnosis question (one line)

Where is your InputAction IterateArrangements node placed right now?

Pawn?
PlayerController?
TileManager Actor / Actor Component?

If you answer that, I can tell you the exact single setting/node change that will make it print immediately.

Thanks — this screenshot basically confirms the issue.

You do have the InputAction IterateArrangements event in your Pawn (Mover), but it’s almost certainly not possessed / not receiving input, so the event never fires.

Also, you’re currently printing off Released, not Pressed (minor, but let’s fix it too).

Here’s the exact checklist to make it work.

1) Wire Pressed to Print String

In your graph, connect:

Pressed → Print String

(Leave Released for later.)

2) Make sure `Mover` is the possessed Pawn

In Unreal, only the possessed pawn gets input events.

The fastest fix (per-level)

Select your Mover actor in the level (you already have it selected in the Outliner), then in the Details panel:

Details → Pawn → Auto Possess Player → Player 0

That’s the “I want this pawn to receive keyboard input” checkbox.

If that field isn’t visible, search in Details for: Auto Possess.

3) Make sure GameMode isn’t spawning a different pawn

If your project’s GameMode spawns a default pawn, it might be possessing something else instead of your placed Mover.

Go to: Project Settings → Maps & Modes

Default GameMode (or your active one)
Check:
- Default Pawn Class
  - either set this to Mover, or
  - set it to None (not always allowed), and rely on your placed pawn with Auto Possess

For quick sanity: set Default Pawn Class to your Mover BP.

4) Quick sanity test: enable input explicitly (debug-only)

If you want a “proof” test (not the final architecture), add this to Mover:

BeginPlay

Enable Input
- Get Player Controller (0)

If input suddenly starts working, that confirms possession/input routing was the problem.

(Once it’s working via Auto Possess, you can remove this.)

5) One more thing: Print String is “Development Only”

That’s fine in PIE (Play in Editor). It will still print.
But make sure you’re looking at the right place:

It shows in the top-left of the viewport, and also in the Output Log if configured.

Why this is happening (so it sticks)

Even though your Blueprint is a Pawn, it does not receive input unless it is possessed.

Unity comparison:

Unity: any script can check Input.GetKeyDown() anywhere.
Unreal: input events are routed through the PlayerController → possessed Pawn.

After it prints: calling your TileManager component

Your reference setup looks okay:

TileManager variable in Mover points to TILE_MANAGER actor (nice)
Then Get Component by Class (TileManager_BP) → call IterateArrangement

Once input fires, this part should work.

One improvement: cache that component once on BeginPlay, so you’re not doing GetComponentByClass on every press.

Do these two things and it will work

Auto Possess Player = Player 0 on your Mover
Wire Pressed → Print String

If it still doesn’t print after that, tell me whether you’re running PIE in:

“Selected Viewport”
“Simulate”
or “Standalone”

Because Simulate can also prevent normal input from firing.

All good — let’s slow this down and do it mechanically, step-by-step. This is one of those Unreal “hidden rituals” that feels dumb until you’ve done it once.

I’ll describe exactly what to click.

Goal

Add this logic to your Mover (Pawn) Blueprint:

BeginPlay
 → Enable Input
     Player Controller = Get Player Controller (0)

This is temporary / debug-only, just to prove input routing works.

Step-by-step in the editor

1️⃣ Open your Mover Blueprint

Double-click Mover in the Content Browser or Outliner
Make sure you are in the Event Graph

2️⃣ Add Event BeginPlay (if it’s not already there)

Right-click on empty space in the graph
Type BeginPlay
Choose Event BeginPlay

You should now see a red node:

Event BeginPlay

3️⃣ Add the Enable Input node

Right-click in the graph
Type Enable Input
Select Enable Input

You’ll get a node with:

Exec input
Player Controller input pin

4️⃣ Connect BeginPlay → Enable Input

Drag the white execution wire:
- from Event BeginPlay
- to Enable Input

5️⃣ Add Get Player Controller

Right-click in the graph
Type Get Player Controller
Select Get Player Controller

By default it uses Player Index = 0 (that’s correct)

6️⃣ Plug it in

Drag from Get Player Controller → Return Value
Plug it into Enable Input → Player Controller

You are done.

What the final mini-graph should look like

Event BeginPlay
   └── Enable Input
           └── Player Controller ← Get Player Controller (0)

That’s it. No extra settings. No magic.

Now test it

Press Play (PIE) — not Simulate
Press your key (I)
Your Print String should fire

If it works:

✅ The problem was possession / input routing → You can now safely remove Enable Input once you fix Auto Possess properly.

If it still doesn’t work:

Then tell me:

Are you pressing Play or Simulate?
Does any Print String fire anywhere?

IMPORTANT (why this feels so stupid)

In Unreal:

Pawns do not receive input unless possessed
Enable Input is a brute-force override
Unity does this implicitly
Unreal does it explicitly

You’re not doing anything wrong — this is just Unreal being Unreal.

After this works (next step)

Once input prints correctly, we will:

Remove Enable Input
Fix Auto Possess Player = Player 0
Keep input clean and correct

If you want, after you confirm it prints, I’ll tell you exactly which checkbox to flip so you never need Enable Input again.

Got it. If Enable Input + Get Player Controller(0) still doesn’t make Print String fire, then the issue is not your TileManager reference — it’s that your input event isn’t being generated/received at all in the current play mode/setup.

We’re going to isolate it in the fastest possible way.

0) First: make sure you’re not in Simulate

This is the #1 “nothing works” trap.

Click the Play dropdown (next to the green ▶️)
Make sure you’re using Selected Viewport (or New Editor Window)
NOT “Simulate”

If you are in Simulate, input events often won’t behave like you expect.

1) Prove that BeginPlay is running

In your Mover pawn:

Event BeginPlay → Print String(“BeginPlay”)

If you don’t see that print, then you’re not even running that pawn’s graph (wrong pawn, not spawned, level not playing, etc.).
If you do see it, we know the pawn exists and is executing.

Results:

✅ BeginPlay prints → continue to step 2
❌ BeginPlay does NOT print → you are not running that pawn at all (jump to step 5)

2) Don’t use Action Mapping yet — use a raw key event

Action mappings can fail if Enhanced Input/templates/etc. are involved.

In the same Mover pawn graph, add this:

Right click → type I → choose Keyboard Events → I

Wire:

I (Pressed) → Print String("I pressed")

Now test again.

Results:

✅ Raw key prints → your input pipeline works; the Action Mapping is the issue (step 4)
❌ Raw key still doesn’t print → input is not reaching this pawn (step 3)

3) Force the PlayerController to own input (strongest test)

Do this in your PlayerController (not Pawn).

Create/use a PlayerController BP:

Content Browser → Add → Blueprint Class → PlayerController
Call it BP_PC
In Project Settings → Maps & Modes:
- Default Player Controller Class = BP_PC

Now inside BP_PC Event Graph:

Add Keyboard I (Pressed) → Print String("PC I pressed")

Play and press I.

Results:

✅ Prints in PlayerController → input works, your Pawn isn’t possessed/receiving (step 5)
❌ Still doesn’t print → your editor/game window isn’t getting keyboard focus or input mode is wrong (step 6)

4) If raw key works but InputAction doesn’t

Then you’re likely in a UE5 template setup where Enhanced Input is expected.

Your legacy InputAction IterateArrangements event may not fire reliably. Fix is:

switch to Enhanced Input (IMC + IA) or
temporarily stick with raw key events for now

(If you want, I’ll give you the exact Enhanced Input steps for UE 5.5.4, but let’s first confirm where input is dying.)

5) If BeginPlay prints but raw key doesn’t in Pawn, yet does in PC

That means the Pawn is not the input receiver.

Fix:

Select your Mover pawn in the level
Details → Pawn → Auto Possess Player = Player 0
Also check Project Settings → Maps & Modes:
- Default Pawn Class = Mover (or ensure you’re not spawning a different pawn)

But note: even with Auto Possess, I still prefer putting input in PlayerController and calling into your manager.

6) If NOTHING prints even in PlayerController

Then it’s usually one of these:

A) The game window doesn’t have focus

Click inside the viewport after pressing Play, then press I.

B) You’re in UI input mode

In PlayerController BeginPlay, add:

Set Input Mode Game Only
Set Show Mouse Cursor = false (optional)

C) You’re running PIE with a configuration swallowing input

Try Play → New Editor Window (PIE) and test there.

Tell me ONE thing and I’ll pinpoint it

After you add the BeginPlay print in Mover, does it print when you press Play? (Yes/No)

That single result tells us whether we’re dealing with:

wrong pawn / not running
possession/input routing
or input not reaching the game window at all.