Tick controls and frame order
Tick isn't the enemy; unnecessary per-frame work is. You control whether something ticks
(bCanEverTick, enable/disable), how often (TickInterval) and when in the frame
(tick groups, prerequisites). Get "when" wrong and one thing follows another a frame late: that's drift.
The controls
| Control | Does |
|---|---|
PrimaryActorTick.bCanEverTick | Whether a tick function is registered at all. False = it can never be enabled later. |
bStartWithTickEnabled | Registered, but starts off. |
SetActorTickEnabled(bool) | Toggle at runtime: tick only while needed. |
TickInterval / SetActorTickInterval | Every N seconds. Still scheduled by the tick system, in its group. |
TickGroup | When in the frame it runs. |
AddTickPrerequisiteActor/Component | "Tick me after that." |
| Components tick separately | Disabling the actor's tick does not stop its components. Each has PrimaryComponentTick. Common gotcha. |
bTickEvenWhenPaused | Pause behaviour. |
UTickableWorldSubsystem / FTickableGameObject | Tick something that isn't an actor. |
| Significance Manager, anim "only tick when rendered" | Less work for far or off-screen things. |
WadOfGore: the base character sets bCanEverTick = false (good). The weapon base sets it
true with no Tick (wasteful: see the weapon page).
Frame order
TG_PrePhysics → TG_StartPhysics → TG_DuringPhysics → TG_EndPhysics
→ TG_PostPhysics → TG_PostUpdateWork → TG_LastDemotableThe physics step runs between StartPhysics and EndPhysics. Kinematic things physics must see (moved collision) go in PrePhysics. Things that should see this frame's physics results (a camera following a ragdoll) go in PostPhysics.
The drift question, rephrased
"Within one frame, which updates first, the particles or the collision following them? If collision reads particle positions before Niagara updates, it's always one frame behind. That lag is the drift."
- Check both tick groups (Niagara has its own Tick Behavior setting).
- Force order:
AddTickPrerequisiteComponent(NiagaraComponent). - Tension: physics needs collision placed in PrePhysics; a follower in PostPhysics is right for rendering but a frame late for physics.
- GPU particles: reading positions back to the CPU has latency, so CPU collision following GPU particles always lags.
- Senior answer: one authority. Compute positions once in your code, move collision in PrePhysics, and push the same positions into Niagara. No drift, by construction.
The same bug in miniature: WadOfGore's hero anim instance reads a value the thread-safe update writes later in the same frame.
The timer trap (from Q5)
- A timer or Delay loop with an interval shorter than a frame is not smoother than Tick. The timer manager runs once per frame, and a looping timer can fire several times in one frame to catch up.
- So "avoid Tick" workarounds can cost more, and run at a point in the frame you don't control.
- Better lesson: "The problem was never Tick, it was unnecessary per-frame work." That's your ready-made "time I was wrong" story.
Quiz yourself
bCanEverTick = false: can you call SetActorTickEnabled(true) later?
No. The tick function was never registered. Use bCanEverTick = true + bStartWithTickEnabled = false if you want to toggle.
You disable an actor's tick. Do its components stop ticking?
No. Components have their own tick functions.
List the tick groups in order.
PrePhysics → StartPhysics → DuringPhysics → EndPhysics → PostPhysics → PostUpdateWork → LastDemotable.
A collision follower lags particles by one frame. Two fixes?
Tick prerequisite so it runs after the Niagara component. Better: make one authority (your code) compute positions, move collision in PrePhysics and feed the same positions to Niagara.
Why isn't a 0.001s looping timer smoother than Tick?
Timers are processed once per frame. A sub-frame interval just fires several times in the same frame to catch up.
Tell the corrected Tick story in one sentence.
"The problem was never Tick, it was unnecessary per-frame work. Per-frame work belongs in Tick, at the right point in the frame, and only while needed."