[Scummvm-devel] SCI: _k_disable_delete_for_now ()
Walter van Niftrik
walter at vanniftrik-it.nl
Tue Mar 31 14:23:49 CEST 2009
Lars Skovlund wrote:
> The result is basically that you
> can't implement savegame deletion for SQ4/Floppy unless you duplicate
> the exact naming scheme of savefiles (i.e. savefiles must be named
> SQ4SG.<number>) and the exact file format of the savegame index
> (SQ4SG.DIR). From the earlier discussions on file I/O handling -
> before as well as after the merge - I gather that this is not an
It sounds like we could intercept file opens of *SG.DIR and construct an
appropriate file on-the-fly. Similarly we could intercept truncates of
SCI-style savegame files to actually delete the appropriate savegame.
Would this work?
> The question then becomes what we want to do. Is the plan to
> eventually bypass the Save/Load UI completely and use the ScummVM
> native one?
Won't this be tricky to do, considering that the games are essentially
in full control when it comes to presenting the save/load dialog? I
guess it wouldn't be a problem to do this for saves/restores that are
initiated from the menu or from F5/F7, but what about
restore/restart/quit dialogs after dying?
We also need to take into account that some games do not use standard
SCI savegame dialogs, like Mother Goose. That game is also incompatible
with our savegame slot remapping BTW, but that's another matter. ;)
More information about the Scummvm-devel