scenes: repair Re-Faze and guardian palette-loop timing

Open
  • Is something wrong?
#574 1 comment 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
8/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
godot, rust
Domain
game-dev

Research direction

Start with Event_ReFaze, Event_DeVarsDefeated and Event_SaLewsDefeated and the shared palette/timing support they call, after reading #470 and #519. Check the US-image offsets listed in the issue ($07160C through $0718CC) against the wait_census tests and docs/source-notes/README.md before editing. Done means the wait_census and focused scene timing tests pass for both Re-Faze branches and both guardians, and the new CRAM tests reject the original timing defects; the tower timing child's PR may need to land first.

Written by the indexing model from the issue text.

Description

later

Child of https://github.com/TusanHomichi/PSIV/issues/571. 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 #571; deliver one PR limited to Event_ReFaze, Event_DeVarsDefeated and Event_SaLewsDefeated, their shared palette/timing support, tests and census claims. Read #470 and #519. Reuse the explicit update-policy support delivered by the tower timing child, awaiting its PR if needed. Existing palette increase/restore operations and the runtime CRAM model are the owning paths; do not create another palette implementation.

For Re-Faze, block for the 63-frame DoMainUpdatesLoop at $07160C. Move the 64-frame loc_58666 restore at $071636 before FireBreath and give it VInt-only semantics. Add the 136-frame main-update wait at $071652 after FireBreath. In the Megid branch, transcribe the two 40-frame Pal_IncreaseTone loops at $071688/$0716B8, the ten-frame main-update wait at $0716E8, the forty-frame restore at $071708 and Pal_VariableFadeToPal2. Verify that fade's US helper semantics and termination rather than substituting an arbitrary fixed wait. Preserve the existing choice, technique, music, flag and battle outcomes on both branches.

For both defeated guardians, replace the erroneous FadeOut plus approximate Wait 40 with the first forty-frame brightening loop at $071772/$07183A. Add the second forty-frame brightening loop at $0717A8/$071870, block for the ten-frame main-update wait at $0717F8/$0718BC, and restore for forty VInt-only frames after the barrier sound at $071808/$0718CC. Confirm the surrounding palette save/copy ordering against retail.

Confirm US bytes, preserve protected inputs and stay within #571's authority; no unrelated palette certification, deployment or publication. Record any deliberate omission by offset and reason in docs/source-notes/README.md. Replace assigned Missing/Recorded/defect census claims with accurate plain Wait or Within claims for implemented loops. Leave unrelated #571 repairs open.

Verification: Run the US-image wait_census tests and focused scene timing tests for Re-Faze's YES and NO branches and both guardians, through the documented heavy-run lock. Assert each loop's count, update policy, sound/palette ordering and final gameplay outcome. Add runtime CRAM tests distinguishing brightening from fading, verifying restoration, and proving the variable fade blocks until its retail completion condition. Show the new checks reject the original timing/order defects. Run affected core/runtime palette tests and documentation checks.

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.