#86 Do not require absolute paths for 3rd-party IWADs

[Alexey Dokuchaev]

Inside IdentifyVersion() function in d_main.c, shortly after if (M_CheckParm("-iwad")), pathiwad is constructed either relative to doomwaddir or, if it is absolute path, used as is.

I have been using the following patch for a while, Unix-specific:

@@ -1441,7 +1441,7 @@ void IdentifyVersion()
     {
         // BP: big hack for fullpath wad, we should use wadpath instead in d_addfile
         char *s = M_GetNextParm();
-        if (s[0] == '/' || s[0] == '\\' || s[1] == ':')
+        if (strchr(s, '/'))
             snprintf(pathiwad, _MAX_PATH-1, "%s", s);
         else
             snprintf(pathiwad, _MAX_PATH-1, "%s/%s", doomwaddir, s);

The idea is that we search DOOMWADDIR only if specified file name does not contain any slashes (that is, now there is a difference between -iwad plutonia.wad and -iwad ./plutonia.wad). I frequently find it annoying having to speficy full absolute path to the WAD I want to try, when I know nice and short relative path to it.

My patch obviously have to be adjusted for Windows/OSX, but the idea should be quite clear.

[Wesley Johnson]

I use the following command
doomlegacy -iwad ../wads/id/doom2.wad -file ../maps/map01.wad

these are relative file names.
I do not understand why you cannot do the same.
Using the default directories or DOOMWADDIR should even work better.

[Alexey Dokuchaev]

these are relative file names.

Relative to what: DOOMWADDIR or current directory?

I do not understand why you cannot do the same.

Unless I misread the code, right now there is no way to load WAD file relative to the current directory.

[Wesley Johnson]

I use the following command
doomlegacy -iwad ../wads/id/doom2.wad -file ../maps/map01.wad
and that is relative to the current directory, and I have been doing this for years so I know it works.

Your solution would break using relative names in DOOMWADDIR, which is unacceptable. I have multiple levels of dirs organizing my wads, and it is a certainty that many other users do too.

If relative names are not working for you in some situation, then please issue a bug report with the details, the relative name submitted, the environment, and the resulting searches that it tried. You seem capable add a few printf to document the problem you are having.

[Wesley Johnson]

Relative names on the command line are relative to the current user directory, usually.
Names that are searched in DOOMWADDIR are specified relative to DOOMWADDIR.
Uses of "./" in those names may not work as that is a shell reference to the current directory, and it would foul appending a name to DOOMWADDIR.
DOOMWADDIR as a relative name would likely not work.

Has this been resolved, or is there still some operational problem with relative path names that needs attention ?

[Wesley Johnson]

The target code and search functions have changed significantly since this suggested patch.
I use relative paths, and they are working.
The search of relative dirs makes this moot.