Am 07.11.2012 09:40, schrieb Jon Dowland:
The first is to provide an alternative for boom, but 'vavoom' does not support
the -iwad flag used by /usr/games/boom, so we would need to write a wrapper.
Actually, vavoom *does* have this flag, c.f. source/file.cpp:492. It
is just not documented anywhere...
The difference is that vavoom expects a file name relative to
"iwaddir" as a parameter. That is, if you have both the
"doom-wad-shareware" and the "freedoom" Debian packages installed,
then "vavoom -iwad doom1.wad" will start the Shareware version and
"vavoom -iwad freedoom.wad" will start Freedoom. Even relative paths
are possible, e.g. "vavoom -iwad ../doom/doom1.wad" does also work.
However, what does *not* work is absolute paths like "vavoom -iwad
/usr/share/games/doom/doom1.wad", but that's exactly what is needed in
/usr/games/freedoom.
The attached patch fixed exact this, i.e. it checks if the passed
string is an absolute path (i.e. it begins with '/') and then
separates it into the path itself - which gets added to IWadDirs (yes,
there can be more than one) - and the actual file name, else it treats
the string just as before. However, this may confuse users who want to
pass the file name of an iwad in the current directory or in a
directory relative to it. But changing this would break the current
(though undocumented) behaviour, so I am not sure how to proceed.
- Fabian
diff --git a/source/files.cpp b/source/files.cpp
index 069aca9..a5c07d2 100644
--- a/source/files.cpp
+++ b/source/files.cpp
@@ -492,7 +492,15 @@ void FL_Init()
p = GArgs.CheckValue("-iwad");
if (p)
{
- fl_mainwad = p;
+ if (p[0] == '/')
+ {
+ IWadDirs.Append(VStr(p).ExtractFilePath());
+ fl_mainwad = VStr(p).ExtractFileName();
+ }
+ else
+ {
+ fl_mainwad = p;
+ }
}
p = GArgs.CheckValue("-devgame");
