Quick answer: Wait actions queue actions on the SOL (selected objects list). If the SOL changes mid-wait, the “deferred” actions act on the new selection. Use Timer behavior for object-specific delays.

A delay-based combo system uses Wait 0.5 then Spawn Effect. The effect spawns at wrong positions. The SOL changed between Wait and execution.

Why Wait Behaves Surprisingly

Wait pauses the rest of the event for N seconds, then resumes. During that pause, other events may have run and changed picked objects. After resume, actions use the CURRENT SOL, not the one when Wait started.

Use Timer Behavior

Add Timer behavior to the object. Start a tagged timer:

Player → Timer → Start 0.5 tag "combo_effect"

On Timer "combo_effect":
    Player → Spawn Effect

Timer is per-instance; firing event already has the timer’s owner picked. Safe across other SOL changes.

Or Pick at Resume

If you must use Wait, re-pick the object explicitly:

System → Set var caster_uid = Player.UID
Wait 0.5
System → Pick Player by UID caster_uid
Player → Spawn Effect

Verifying

Trigger combo; effect spawns at right position. Multiple players doing combos simultaneously don’t crosstalk.

“Wait is asynchronous; SOL is the state. For per-object delays, use Timer behavior.”

Timer Behavior is the unsung hero for Construct event sheets — use it liberally for per-object scheduling.