It was a wrong (and maybe stupid) assumption, that the config dir
(~/.yq2) is always the first element of the search path. When there's
at least one pak file in the config dir, it's added at a random
location. Work around this by probing all directories. This fixes
issue #107.
The savegame list is generated by calling FS_FOpenFile() for each
possible savegame name. When a file handle is returned the savegame
exists, otherwise the savegame slot is empty. But FS_FOpenFile()
searches in every directory known to the VFS. If a savegame file
isn't found in $moddir but in baseq2, the file in baseq2 is opened
and a baseq2 savegame is displayed in the mods / addons savegame menu.
The fix is compromise between a clean solution and invasiveness:
- Refactor FS_FOpenFile() to include FS_FOpenFileRead(). FS_FOpenFile()
was used only to open read only files, limit its's possibilities to
do exactly that.
- Introduce a new flag "gamedir_only" to FS_FOpenFile(). When true
only the gamedir directories are searched and not other directories
like baseq2.
- Change all callers to FS_FOpenFile()s new signature.
- Use the new gamedir_only flag to limit the searchpath for savegames
to the gamedir.
This makes it behave a little more like -basedir in Quake 1 and
fs_basepath in ioquake3.
This lets "+set basedir" take precedence over the SYSTEMDIR,
which is useful if you have the demo and full-game data installed
in different base directories to be able to test the demo for
regressions.
With this change the homedir is no longer selected in the filesystem,
but in platform dependend functions. This allows us to use WINABI calls
for selection, resulting using the apropriate diretory on localized
versions of Windows XP.
Under Windows all config data is written to %USERPROFILE%\AppData\
Local\YamagiQ2. To archive this code was added that translates Windows
pathes with backslashes into Unix pathes with normal slashes.
