Scenes: repair Eclipse Torch flashes and the shared object-update wait

Open
  • Is something wrong?
#593 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
6/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Active
Tech stack
godot, rust
Domain
cloud, documentation

Research direction

This is a multi-part, dependent task: it depends on a mounted-transition child and on #520's census publication, and it touches the palette and object-update path shared with #573 and #574. Do not start until those land. The payload names Event_EclipseTorchUsed, the flash sequence at $070266 through $07044C, docs/source-notes/README.md and the wait_census tests; it does not name the file or test to begin with. Done means both flash sequences, nine creations, and the 80-frame wait are asserted frame by frame, with documented deviations.

Written by the indexing model from the issue text.

Description

later

Child of https://github.com/TusanHomichi/PSIV/issues/589. Finish only this task in one fresh session and one PR. The parent's original authorization boundaries still apply; this child grants no additional authority. Do not read earlier sessions' transcripts.

Child of #589, discovered by #520 under #470 and #345. Deliver one PR limited to Event_EclipseTorchUsed's flash and nine-object sequence, necessary shared presentation support, focused tests, documentation and census claims. Build on the mounted-transition child, await #520's census publication, and reuse #573's explicit update-policy support. Reuse existing palette copy/restore and scene-object owners; inspect related palette work such as #574 before adding shared support, without taking over its scenes.

Transcribe the first white palette flash and its two-frame DoMapUpdateLoop at $070266; replace the existing approximate 40-frame wait with the VInt-only loc_58666 restore at $070270. Add the entire second flash: Deban sound, white palette, two-frame DoMapUpdateLoop at $0702A8 and forty restore passes at $0702B2. Preserve retail palette save/copy/restore ordering through the runtime CRAM model. Represent the nine $338 creations without invented one-frame waits per spawn, then block for the shared 80-frame DoMainUpdatesLoop at $07044C, running objects and map updates. Preserve subsequent dialogue, flag and return behavior.

Confirm US retail bytes and use the established runtime-to-Godot presentation path. Each assigned item must be implemented or explicitly recorded with its offset and reason as a deliberate deviation in docs/source-notes/README.md; update census claims and defects to match actual behavior. Preserve earlier children's fixes and unrelated census rows. Work in an isolated worktree from current origin/main, protect local assets and saves, use documented heavy locks and provide a PR receipt. No unrelated object-system migration, release, deployment or asset distribution; original authorization boundaries remain unchanged. Do not read earlier sessions' transcripts.

Verification: Run US-image wait_census tests, focused frame-by-frame Eclipse Torch tests, affected runtime palette/object tests and documentation checks. Assert both Deban/white/copy/restore sequences, both two-frame map waits, both forty-pass VInt-only restores, nine creations without per-spawn delays, and the subsequent eighty main-update frames. Verify CRAM restoration, object advancement, update policies and unchanged final outcomes. Include regression controls rejecting the missing second flash and original spawn/wait timing. Inspect native and matching retail captures at named white-flash and restoration frames, with viewport and compared region recorded; state any remaining presentation deviations explicitly.

If this is too big, publish any progress, split it with proj split FILE (a JSON array of title/body/check tasks), then end the session. Wait for the PR to land before declaring this task done.

Dominant language
Rust
Stars
1
Forks
0
Avg merge
8h 43m
Merged PRs (30d)
288

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from TusanHomichi/PSIV

All issues in TusanHomichi/PSIV

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.