[Scummvm-devel] SCI: Some more TODOs

[Willem Jan Palenstijn]

On Sat, Feb 21, 2009 at 03:17:34PM -0500, Max Horn wrote:
> Hi Willem, all,
> 
> thank you for clarifying some bits, esp. how the character import/ 
> export in QfG 2 feature works, roughly.
> 
> First a general remark: We should not expose the full filesystem to  
> the games. I think that they should only be allowed (and need) to see  
> files in their game dir (and subdirs), and savefiles. Everything below  
> should be read and implemented with that in mind.
> 
> Based on what you wrote, I propose this:
> 
> 1) Change the implementation of K_FILEIO_FIND_FIRST /  
> K_FILEIO_FIND_NEXT to only iterate over files in the savegame manager.  
> Users can still import characters from external sources by copying  
> (and possibly renaming) those files to their savedir.

Assuming that FIND_FIRST/NEXT are only used for savegames and character
imports, that sounds like a good idea.


> 2) In order to avoid name classes, and incompatibilities between game  
> variants, we need to mangle the file names. How we do that would  
> depend on various factors that I don't know yet, so more input is  
> required: Are QfG2 character files compatible for all versions of  
> QfG2? Are they used to export a char from QfG1 and then import it into  
> QfG2 ? Is the character name supposed to be part of the filename?

I think the character files have a common format. (Although there were
regularly bugs in character import and export, I believe. Not sure if we
can do anything about that.)

You export a character from QfG x and then import it
into QfG x+1,x+2,x+3,x+4 . (Up to QfG5, but that is not SCI anymore.)

The character name is not part of the file name.

> One simple approach would be to prefix the file names with qfg_  
> automatically.

I'm not yet really familiar with game IDs, but would it be easy to
determine this prefix? We'd probably want all QfG games (including
Hero's Quest) to share a prefix (qfg sounds good), but as far as I know,
all other games should probably use a unique one (targetName?).

> 3) All the other file code in kFileIO may have to be extended to work  
> with both savefiles and files in the game's resource directory. That  
> is, when writing a file, a savefile would always be used. When reading  
> a file, we would first check whether a savefile with the right name  
> (after mangling) exists. If not, we'd look in the gamedir. (We do  
> something similar in SCUMM HE.)

Yes, agreed.

> 4) The SCI code doesn't seem to clearly distinguish between opening a  
> file for reading and for writing. We may have to hack around that.

file_open seems to open a file for reading/writing with 
_K_FILE_MODE_OPEN_OR_FAIL and for writing (truncating existing files)
with the other two modes (_K_FILE_MODE_OPEN_OR_CREATE,
_K_FILE_MODE_CREATE). I guess we could do the same for the writing
modes. Maybe for the _K_FILE_MODE_OPEN_OR_FAIL mode we could open the
file for reading, and then re-open it (properly seeking to the right
offset) for writing when necessary?


-Willem Jan