Entities (and the player's pause-to-open-game-menu handling with them)
previously kept updating every frame regardless of the active scene,
matching an existing TODO in rpgUpdate(). Gating the entity loop itself
means the game menu (and any other entity-driven input) naturally can't
trigger mid-battle or before the initial scene hands off to the
overworld, without needing a scene check at each individual call site.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A new SCENE_TYPE_INITIAL now runs before the overworld: it checks
save-device availability and existing save data, then shows one of two
new dedicated modals - "no save device found" (Retry / Continue Anyway)
or "no save data found, create one?" (Yes / No) - before handing off to
the overworld. Both modals are self-contained UI elements mirroring
uiconfirm.h's shape, registered like any other global UI element.
Choosing "Continue Anyway" marks the session temporary (SAVE.temporary,
folded into saveIsAvailable()) so saving stays disabled for the rest of
the session instead of silently retrying, and the game menu's Save
action now reports that distinctly instead of the generic "no device"
message.
Also removes rpg.c's leftover TEST block (unconditional player-name
stamp + save write on every boot) now that this real flow owns save
creation.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Renames savefile_t to saveslot_t and folds last session's standalone
settings.h/.c module back in as savemeta_t, so there's one save system
(SAVE.slots[] + SAVE.meta) instead of two parallel ones - while letting
each platform pick its own physical format for the two concepts:
- Linux now writes human-editable JSON (slot0.json, settings.json, ...)
via yyjson's mutable writer API, so players can hand-fix a bad setting.
- PSP folds meta into the same sceUtilitySavedata binary payload as its
one save slot (SAVE_SLOT_COUNT_MAX=1 there - a future save picker will
let players manage multiple named saves via the OS's own browser).
- GameCube consolidates the 3 per-slot memory card files and the separate
settings file into one combined card file.
Also fixes two bugs surfaced while building this: the CRC finalize step
seeked to a hardcoded offset (only safe for one section per file, breaks
once meta+slots share a buffer), and save.c's async/sync dispatch left an
unconditional fallback call that doesn't exist on PSP-only platforms.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Deadzone (and future prefs like locale) now live in their own
settingsfile_t/settings.c, loaded eagerly at boot and saved immediately
on Apply, instead of inside savefile_t - a setting shouldn't reset or
diverge just because the player is on a different save slot, and this
also fixes settings changes not actually reaching disk until the next
full game Save.
PSP settings use a new plain sceIo path rather than sceUtilitySavedata,
since that dialog would flash its native icon on every settings tweak.
GameCube reuses the save system's existing memory card mount rather than
mounting it twice (settingsInit() now runs after saveInit()).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds three new pieces of save-file state, all following the same shape:
the save file is the single source of truth, not a separate live runtime
copy that gets synced in/out.
- globalitemstore.h/.c: per-global-entity-ID "collected" flags
(savefile_t.globalItemCollected), so a global item entity's init
callback can check whether it was already picked up in a prior session
without needing to keep the entity itself alive to remember that.
- Gamepad deadzone: removed input_t.deadzone entirely. The setting UI and
every platform's actual deadzone-applying code (inputGetDeadzoneDolphin/
SDL2, previously hardcoded per-platform literals that the settings menu
didn't actually affect) now read savefile_t.deadzone directly via
saveGet(SAVE_ACTIVE_SLOT). Default lives in savefile.h
(SAVE_DEADZONE_DEFAULT), stamped onto every slot in saveInit().
- Story flags: STORY_FLAG_VALUES (a live, codegen-initialized array) is
replaced by savefile_t.storyFlags, read/written via the existing
storyFlagGet()/storyFlagSet() call sites (now macros/functions over the
active save file instead of a separate array). tools/story.py now
generates STORY_FLAG_DEFAULTS (const) instead; storyFlagInitDefaults()
stamps those onto a save the first time it's used (file->exists false),
called from rpgInit().
Added SAVE_ACTIVE_SLOT (0) to savefile.h as the one shared "which slot is
actually being played" constant, replacing three different local/implicit
0s (uigamemenu.c, rpg.c, and now the settings/input call sites).
Verified round-trip on Linux (all three together in one save/load cycle);
both Linux and PSP build clean.
uiGameMenuSave() now attempts a real load first (via the existing generic
saveLoad()/saveExists() primitives) instead of writing blind. If a save
already exists, it saves straight over it as before. If not, it prompts
via the existing uiConfirm dialog ("No save data found. Create a new
save?") before writing - this is exactly the flow GameCube needs (no
native OS save browser to lean on, unlike PSP), but implemented generically
so it also applies correctly on every other platform without any
platform-specific UI code: saveIsAvailable()/saveExists() already reflect
each platform's real state (e.g. Dolphin's memory-card presence and
existing-file checks), so the same logic just does the right thing
everywhere.
Verified the two branches directly on Linux (temporarily wiring the same
saveLoad -> check -> uiConfirmOpen sequence into rpgInit): with no save
file, saveExists() is false and the confirm dialog opens; with one already
written, it's true and the confirm dialog is correctly skipped. Not
verified via actual menu navigation (no input-injection tooling available
here) or on Dolphin (no devkitPPC toolchain in this environment).
Rewrote savepsp.c/savestreampsp.c to use sceUtilitySavedataInitStart/
Update/GetStatus/ShutdownStart instead of sceIoOpen/Read/Write, so PSP
saves get a proper OS-generated PARAM.SFO (title/savedataTitle/detail) and
show up correctly in the native save browser.
This dialog spans multiple frames and, per this project's prior experience
with the network config dialog, must be pumped non-blocking one step per
real engine frame rather than blocked on synchronously - a raw-sceGu
blocking loop already froze the app on real hardware for that dialog,
since pspGL owns the GU context. So save.h's saveWrite()/saveLoad() are
now callback-based (savecallback_t onComplete) instead of returning a
result directly, mirroring networkRequestConnection()'s shape, with a new
saveUpdate() (wired into engineUpdate()) pumping the active op each frame.
Linux/Dolphin behavior is unchanged - their fallback path in save.c still
completes synchronously, just via an immediate callback call instead of a
direct return.
Two real bugs found via PPSSPP testing (not just code review): SAVE/LOAD
modes show a confirm screen even for brand-new data, which blocks forever
headlessly - switched to AUTOSAVE/AUTOLOAD, which write/read silently and
generate the identical PARAM.SFO. And PPSSPP's dialog status goes straight
from QUIT to NONE without a separately observable FINISHED in between,
which the first version misread as "disappeared without a result" even on
a successful save - fixed by tracking whether QUIT was already seen.
Confirmed end-to-end in PPSSPP: write, dialog completes, PARAM.SFO +
encrypted save.bin appear on the virtual memory stick, and a subsequent
load decrypts/deserializes back to the exact original data. Not tested on
real PSP hardware.
Adds savefile_t.playerName (SAVE_PLAYER_NAME_MAX) serialized via the
existing saveFileReadString/WriteString helpers, and stamps + saves it in
rpgInit() as a test that the save system now persists actual game data,
not just the header/version. Verified manually: written bytes end in
"Dusk\0" immediately after the version field, and loading it back returns
the same string.
- Fixed the actual reason saving never worked on any platform: saveWrite()
never stamped file->header/file->version before serializing, so every
written save file had a zeroed magic header and failed its own
validation on the next load. Confirmed via a manual write/load round
trip that this alone fully explains "saving doesn't work."
- Re-enabled saveInit()/saveDispose() in engine.c (previously commented out
under "Temporarily disable save code").
- Added SAVE.available + saveIsAvailable(), refreshed by every real
save/load/delete attempt. saveInit() no longer treats an unreachable
save medium as fatal to booting - it logs and continues, since a missing
memory card/stick shouldn't prevent playing.
- Hardened PSP's saveInitPSP() to actually detect a missing memory stick
(sceIoGetstat on ms0:/) instead of assuming success, and fixed
single-level sceIoMkdir to build the full PSP/SAVEDATA directory chain.
- Added busy-retry (CARD_ERROR_BUSY) and a not-mounted guard to Dolphin's
live savestreamdolphin.c path, extending the same handling already
backported into savedolphin.c.
- Added a "Save" entry to the game menu wired to saveWrite(0), showing a
clear message on success, on failure, and when saveIsAvailable() is false.
Backported from branch ac2 (commit 85b61097) - CARD_Mount was being called
without CARD_Init first, leaving per-channel control blocks and the DSP
unlock sequence unset. On real Dolphin/hardware this surfaced as a hard
MMIO crash instead of a clean CARD_ERROR_* failure.
Co-Authored-By: Dominic Masters <dominic@domsplace.com>
- Allow 2 chunks to be mid-load concurrently instead of 1 (MAP_CHUNK_LOAD_CONCURRENCY).
- Fix entitySetChunk silently losing track of an entity when its target chunk's
entity slots are full - it now stays detached (and retries later) instead of
claiming a chunk that never actually registered it.
- DCF format bumped to v5: chunks can now declare entity spawns (global/NPC via
the existing entityglobal registry, or one-shot item pickups) and map area
triggers, resolved via a new callback-ID registry (mapareagloballist.h)
mirroring the entity one. rpg.c's hardcoded TEST entity/item/area spawns are
gone - chunk_0_0_0.json now carries that data instead. The player is still
bootstrapped in code since it isn't map-authored content.
YourWishes