* fix(camera): let free look release the door peek camera
After walking through a door, the door camera (CAM_SET_DOORC) held the view and
only handed control back once the player moved or pressed a button, so the right
stick did nothing until then. With free look the camera appeared frozen after
every door.
Treat right-stick movement as a release condition too, using the same stick
threshold as free-look activation.
* refactor(camera): move door-cam free-look release to a VB_SHOULD hook
Reimplements the door peek camera free-look release as a vanilla-behavior
hook instead of inline logic in z_camera.c, keeping the decomp file close
to upstream.
- Add VB_RELEASE_DOORC_CAMERA wrapping the existing Camera_Special9 release
condition; the vanilla button/xzSpeed expression is left untouched.
- Move the right-stick / free-look threshold logic into a new enhancement,
FreeLookDoorCamRelease.cpp, registered with COND_VB_SHOULD and gated on
FreeLook.Enabled so the hook only exists while Free Look is on.
Behavior is unchanged from the previous fix; this only relocates the logic.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Free Look pinned the camera to the fixed "Camera Distance" setting, so it never
pulled in or out the way the vanilla camera does for the current situation.
Add an opt-in "Follow Default Camera Distance" setting (FreeLook.UseGameDistance)
that uses the game's per-mode default distance instead. The fixed distance slider
is hidden while it is enabled.
Closes#4050
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The custom-sequence registration loop printed each assigned seqNum to
stdout via a bare printf, spamming the console with context-free numbers
on every launch. Convert it to LUSLOG_DEBUG and include the sequence name
so it is hidden by default yet useful for diagnosing music-pack loading.
The audio thread will now self-pump every 5 ms in case the rendering loop
takes too much time before waking up the audio thread, causing audio
starvation.
This is what was causing audio stutters/cuts during world loading.
I had the issue constantly the first time I pressed start to get the game
menu.
To avoid issues, the first wakeup of the audio thread is behind a `primed`
flag and will wait unconditionnally for the rendering loop to wake us up.
This is to make sure the game has initialized properly and avoid a crash
on boot.
The resolved replacement id (which can exceed 255) rode a single
per-player seqToPlay slot, written at enqueue but consumed
asynchronously on the audio thread; back-to-back starts and
priority-queue promotions clobbered it. sSeqFlags[0x6F] was also indexed
by raw id, reading out of bounds past the authentic range.
- func_800F9280 resolves the replacement and packs the full 16-bit id
into the 0x82/0x85 play command; the handler reads opArgs & 0xFFFF.
Audio_QueueSeqCmd no longer pre-writes the shared slot.
- SyncInitSeqPlayerInternal uses the command-carried id and bounds-checks
it against the calloc'd sequence map (+0xF headroom for reserved-range
skips).
- Route sSeqFlags reads through a bounded Audio_GetSeqFlags helper.
- Warn and skip gracefully past the 16-bit id limit.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
We now have both tower collapse corrected, and other potential softlocks and bugs that would occur from weird network timing causing an UNSET of values in the game with these fixes.
* Fix bari's biris not respecting the seeded option
* Randomize Peehat Larvas
* Refactor `IsEnemyAllowedToSpawn`
* Fix the issue where some enemies spawn above the ceiling
* Partially fix twisted hallway issue
* Prevent Baris from spawning Baris
David Racine