Scenario Sprite Animation

Worked example: a seamless idle loop from a still

1. Create a dedicated collection first (collection_create, tool catalog) and collection_add_assets (collection_id, asset_ids) every kept output as it lands. With no still to hand, generate and approve one first: it anchors every later step, so check subject-critical detail against the brief before animating, and budget it apart from the loop (references/lane-schemas.md). Flatten the character onto a plain field (a local edit is fine; assume video inputs drop transparency as reference inputs do) and upload_asset it. Confirm lane and budget with the user; unattended, take them from the task instructions, else the cheapest lane that fits, and dry_run before every paid run.
2. recommend with the loop requirement in the user's own words, prefer a non-deprecated pick, then model_schema_get. The schema decides the levers: duration and fps enums, a camera lock such as static, an audio toggle, and a native loop flag where present, replacing the end-frame anchor: never send both (dry_run accepts combinations that still fail at run time).
3. model_run with the same still as first and last frame and a prompt that names the motion explicitly ("weight shifts, cloak sways; the character stays in place"). jobs_wait re-called with pending_job_ids while the job runs.
4. If the sprite needs alpha, expect no video lane to emit it, so budget a removal pass; verify alpha survived on one downloaded frame before batching: inline display composites it away, and a transparent request can come back in a container without alpha (references/lane-schemas.md). Extract with the video-to-image-sequence tool and verify the frame order first (above). Confirm what was delivered before computing any stride (requests are not always honored): asset_get reports properties.duration, frameRate, nbFrames, width, and height; nbFrames is the delivered frame count the math needs, so read those and leave the rest of the record alone. At authoring time the extractor exposed only extractAllFrames and frameInterval, so confirm with model_schema_get: no start offset, end, or range. Any non-uniform selection (trimmed window, stride off an offset, hand-picked subset) means extractAllFrames: true then subsetting by asset id; a frameInterval that cannot express the window is never a reason to leave the platform. Frame math: extracted count = delivered frames / frameInterval, endpoint-inclusive; where the schema exposes fps, generating at sprite cadence (8 to 12 fps: a cycle typically needs 8 to 16 frames) beats decimating after.
5. Seam-check against the sequence's own motion, not by eye: a seam reads as a loop only relative to how much the frames already move. Compute the mean absolute pixel delta between consecutive frames (the motion baseline) and the delta across the seam; the loop closes when the seam sits at or below the baseline of the window being looped, not the whole sequence's, since per-step delta swings by orders of magnitude across a scene loop. On a near-static idle, asset_display of first and last frame is enough; on locomotion (hop, walk, attack) eyeballing passes visibly broken loops. If the seam is wide, do not re-run first: image-to-video models re-render off the input still, so frame 0 often diverges from every later frame (a large 0 to 1 delta is the tell) and no re-run fixes a loop anchored to it. Search start and end pairs inside the model's own rendering, excluding frame 0, and take the tightest closing window that still carries real motion. Trim to where the motion is: a duration longer than the action leaves a static tail, and the stride comes from the active window, not the delivered length. Only after a window search fails is a re-run (new seed where the schema has one, else reworded motion) worth the credits. Unattended, allow one re-run, then flag and stop.
6. Finish and package: a pixel-art target needs a snapping pass, which has traps of its own and is sometimes the wrong move (references/lane-schemas.md). Sheet via the grid maker, transparent background or a color when the brief is opaque; preview via sequence-to-video as GIF; the assembler has no background parameter, so a deliverable GIF takes opaque frames already on its field. asset_download frames with format="png" and the preview with format="gif", and omit format on a video asset, which rejects mp4.

Common mistakes

• Identical first and last frames with a bare prompt: that asks for a freeze, not a loop; the motion must be named.
• Treating margin or wording as containment for a traveling effect: what crosses the cell edge is gone, margin gets filled and crossed anyway, and containment wording cancels the throw. Keep the frames whose delivered edge band reads empty; the detached projectile is its own sprite.
• Assuming every model has a seed: many video schemas and several high-adherence image schemas have none, so reproducibility there is per-asset, not per-run.
• Counting on an interpolation filter: none exists in the catalog, and fps is the timing lever. Pixelating a non-pixel image is a different job from cleaning pixel art: the catalog carries a pixelate tool (grid size, palette) for the first and the snapper for the second, both found with search (target: "models", public: true, filters tags: ["tool"], query: "pixel" returns both; the descriptions tell them apart).
• Photo upscalers on pixel frames: they invent texture; use the pixel-preserving routes in scenario-game-assets.
• Shipping a sheet unstepped: per-frame steps return new ids and order lives only in the lists you pass, so carry the frame-to-output mapping (never rebuild it from listings or timestamps), then compare sheet to preview before delivery.
• Assembling deliverables locally because the frames are already on disk: analysis pulls the clip down, local assembly then looks free, and the frames never become assets, leaving the collection holding a sheet nobody else can reach.
• Ping-pong or loop flags set blind: watch the downloaded GIF and match the assembler to it.
• Launching every frame, direction, or clip at once: past the team's concurrency ceiling (the parallel-custom-jobs row in the scenario skill) a launch is refused with that 429 and creates no job, and on some video lanes the burst is accepted and comes back as failed, refunded jobs instead (directional cycles). Either way, launch in waves and relaunch every refused or failed item in the next one rather than dropping it.
• Softening an attack brief after a moderation block: the filter is the provider's, so try another general image model first per scenario-moderation, grid spec unchanged; rewording the beats loses what the lane exists to honor.