Am 08.11.2012 14:41, schrieb Fabian Greffrath:
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.
I think the patch attached to this mail solves this issue way more
elegantly. Whenever an iwad file is given on the command line, the
path to that file is made the first choice in the list of possible
iwaddirs. If it is an absolute path, the path itself is used for the
iwaddir and separated from the file name. If it is a relative path or
a single file name, the current directory is used for the iwaddir and
the relative path or file name is used for the main wad file name.
That way, if you have a doom.wad in your current directory and type
"vavoom -iwad doom.wad" it will take this file. If the file is absent,
then it will take the one from the next directory in the iwaddirs
array, i.e. typically /u/s/g/d/doom.wad. Thus, relative paths works as
before, but precedence is taken by files that satisfy the path based
on the current working directory. This is, IMHO, how all other tools
in *NIX are expected to work. It is, furthermore, consistent with
prboom's behaviour, at least in the limited range of tests that I
performed.
I have, however, not yet figured out how the '-doom', '-doom2' etc.
parameteres work in vavoom, but I think they are just shortcuts for
the '-iwad' parameter in case there is more than one valid iwad file
available in iwaddirs.
- Fabian
diff --git a/source/files.cpp b/source/files.cpp
index 069aca9..7750874 100644
--- a/source/files.cpp
+++ b/source/files.cpp
@@ -492,7 +492,16 @@ void FL_Init()
p = GArgs.CheckValue("-iwad");
if (p)
{
- fl_mainwad = p;
+ if (p[0] == '/')
+ {
+ IWadDirs.Insert(0, VStr(p).ExtractFilePath());
+ fl_mainwad = VStr(p).ExtractFileName();
+ }
+ else
+ {
+ IWadDirs.Insert(0, "./");
+ fl_mainwad = p;
+ }
}
p = GArgs.CheckValue("-devgame");
