[Scummvm-devel] SCI: _k_disable_delete_for_now ()
max at quendi.de
Tue Apr 7 00:19:02 CEST 2009
seems I overlooked yet another thread. Anyway, here's my late reply.
Am 31.03.2009 um 10:54 schrieb Lars Skovlund:
> I noticed that someone put a fixme in for this this function (in
That was me. (The SVN "annotate" feature is a great way to find out
who added a certain piece of code: <http://scummvm.svn.sourceforge.net/viewvc/scummvm/scummvm/trunk/engines/sci/engine/kgraphics.cpp?view=annotate
> The function is not actually a workaround
> for anything, more like a "prevent the user from doing something
> nasty" type of thing, and goes back to the ugly way in which savegame
> deletion is implemented in SCI (and even worse in SQ4/Floppy, for
> which the workaround is intended).
Yeah, well, from what you wrote, that's actually exactly what I would
call a "workaround" for buggy or bad behavior in the original game
resp. engine... ;-). Anyway, the comment was really referring to the
"if()" block it preceded, but having looked closer now, I think the
whole function deserves a good explanatory comment :-). I guess we can
just copy the text of your email for that.
For the rest, I am going to reply to Walter's reply, which already
added some remarks.
Am 31.03.2009 um 14:23 schrieb Walter van Niftrik:
> 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?
It would be possible to do what you describe, I think. Whether it
would work... Lars? :) Or, well, let's just try it. I'll take a look
at this one day, but you folks shouldn't wait for me, I am not going
to do much before my PhD defense in less than two weeks ;).
>> 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?
I don't see any reason right now to replace the save/load UI of
FreeSCI, and that's not "the plan" as far as I am concerned.
However, it would indeed be really nice to implement as many of the
"Advanced Engine Features" (AEF) as possible for SCI (see <http://wiki.scummvm.org/index.php/Advanced_Engine_Features
>). Among these is support for the GMM (Global Main Menu), which
allows a uniform and consistent way throughout all engines to access
certain functionality, via a uniform hotkey (currently Ctrl-F5 on
regular ports, potentially a custom trigger on e.g. gameing consoles).
Among this is the ability to quit, return to the launcher, access the
about dialog (with credits), and in the future, help dialogs. Well,
and load & save dialogs if the engine supports this.
Whether the later is possible in SCI or not, you guys will know better
than I -- me, personally, I haven't formed an opinion yet, I'll have
to dig into the source for that (but as mentioned above, don't hold
your breath on that right now).
(Another very nice AEF is the ability to load savestates from the
command line. Very handy when debugging stuff.)
> We also need to take into account that some games do not use standard
> SCI savegame dialogs, like Mother Goose. That game is also
> with our savegame slot remapping BTW, but that's another matter. ;)
Aha? Well, can't comment, don't know that game at all... If there are
issues, I hope they'll eventually be logged and then addressed :)
More information about the Scummvm-devel