Ue5 Spawn Frame And Inheritance

Spawn Frame and Inheritance

Two actors, same code, different results — one is standing still and one is moving. That is the whole class of bug this skill covers, and it has two independent causes that produce similar symptoms:

Reference frame. A solution computed in the mover's frame, applied in world space, without the conversion. The error is a constant offset in the direction of motion, scaling linearly with speed. It has a signature that makes it easy to recognize once seen and nearly impossible to find by inspection: the bias is always in the same direction relative to travel, and it disappears when the mover stops.

Frame timing. A value read at the wrong point in the tick order, so it is one step stale or one step ahead. Error scales with speed and with step size, moves when frame rate changes, and vanishes under a debugger's slow stepping.

Both look like a bug in whatever consumes the value. Neither is.

Settle the frame contract first

1. Name the frame every quantity is expressed in — world, actor-local, or component-local — and write it into the variable names or the comment where it is computed. Most inheritance bugs are two correct calculations joined without a conversion.
2. Decide what a spawned object inherits, explicitly: the spawner's velocity, part of it, or none. All three are legitimate designs. Silence is what produces the bug, because the engine's default is "none" and the intuition of everyone reading the code is "some". See references/inheritance-rules.md.
3. Decide when in the frame the read happens and confirm what has updated by then — movement, animation, physics. A transform read before the mover's movement update is one step behind. See references/tick-order.md.
4. Convert once, at a named boundary. Solve in whichever frame is convenient, then convert at a single clearly marked place rather than mixing frames through the computation.
5. Test at speed. A stationary test passes for every bug in this skill. Nothing here is detectable at rest.

Load only what applies:

• references/inheritance-rules.md — what a spawned object should inherit, the three designs, and the conversion at the boundary.
• references/tick-order.md — read-before-update staleness, where the common one-frame errors come from, and how to place work deliberately.
• references/bias-diagnosis.md — reading the error's signature to tell which of the two causes you have, before changing anything.

Required answer format

When this skill fires, return:

1. Frame table — each quantity involved, the frame it is expressed in, and where it is converted.
2. Inheritance decision — what the spawned object inherits, how much, and why.
3. Tick placement — where in the order the read occurs and what is guaranteed updated.
4. Speed-scaling check — the predicted error if the decision were wrong, so the test has something to look for.
5. Test results — outcomes at rest, at cruise, and at maximum speed.
6. Not verified — anything whose frame or update order you could not confirm.

Hard rules

• Never mix frames in one expression. A term in local space added to a term in world space compiles, runs, and is wrong only when the actor moves.
• A spawned object's initial velocity is a decision that must appear in code, even when the decision is zero. Write it explicitly so the next reader sees a choice rather than an omission.
• Never read a mover's transform for a spawn without knowing whether its movement has already run this step. "It looked fine" is not the same as knowing.
• Do not fix a directional bias by adding a correction constant. A constant that cancels the error at one speed is wrong at every other speed, and it hides the cause permanently.
• Anything solved in a rotating frame needs the rotation handled, not just the translation. Turning platforms break translation-only conversions.
• Test at maximum speed as a required case, not as an edge case. At rest, all versions of this code are correct.

Verification

Speed sweep. Run the same seeded scenario at several mover speeds including zero, and plot the error. The shape is the diagnosis: flat at zero and rising linearly with speed is a reference-frame or inheritance error; rising with both speed and step size is a tick-order error; flat and nonzero at all speeds including zero is neither, and belongs to a different skill.

Frame-rate invariance. Run the same scenario at two very different fixed step sizes. Results must match within the simulation's stated tolerance. A difference that scales with step size is one-frame staleness — see ue5-deterministic-sim-tests for the harness.

Direction check. Plot error direction relative to the mover's travel direction. A consistent relationship — always behind, always ahead, always to one side — is proof of a systematic frame error rather than noise. Random scatter means look elsewhere.

Scope

This skill covers the moment of spawning or launching from something that moves, and the frame and timing questions around it. It does not cover which transform is legitimate to read in the first place (ue5-authoritative-vs-cosmetic), the flight behavior afterwards, or network-related timing such as lag compensation and client prediction reconciliation.

It assumes a fixed logic timestep. Under a variable timestep every effect here still exists and is additionally irreproducible, which is a harder problem this skill does not solve.