Suggestion for standard IWAD location specification

DaniJ said:

Is a utility for editing DOOMWADDIR/DOOMWADPATH even necessary? On Windows I can use the operating system's own GUI to accomplish this. The five mouse clicks it requires to get me to that UI and what to do once there could simply be documented on the DOOM wiki.

If you have lots of IWAD files, and wanted to specify them all as absolute paths, I can see why using the system configuration dialog could be time consuming/clumsy to use. A graphical configuration program could be nice.

I agree a utility would be nicer/easier.

However, as has been pointed out already, the primary user of such a utility would likely be an inexperienced or new user. Asking them to download another app that they won't be familiar with, just to get started, is arguably more complicated than giving them direction within the OS they are already using. Not to mention that the app will obfuscate what is actually going on and removes the opportunity to educate the user in the process.

If you implement all these 100+ variables, there's two ways to do it
* Be lazy and use getenv() and call strcmp() about 10,000 times
* Use environ and the code is no longer "simple".

fraggle said:

Whatever you do, please don't use XML. There's no way I'm going to add an XML parser library as a Chocolate Doom dependency.

XML was just an example, you could use JSON or some other fancy format. But nothing terrible like INI and INF.

Gez said:

Looking at Ghostly's XML proposal, I don't see the point of separating filename from location, and the comment field seems useless.

The comment field was an example, for custom IWADs since Quasar wants to support them.

Quasar said:

You're still not allowing people to use multiple files that are named the same. As a port author I regularly test my code against all versions of DOOM, including shareware, registered, and retail. I don't believe I should be required to change the DOOMWADPATH to do that, or to rename the files from their original names either.

EE already supports DOOMWADPATH and *will* "guess" which doom.wad to use if you, for example, use "-iwad doom.wad" and it cannot first be found in the configuration file settings or in a higher priority IWAD location, such as in the current working directory, EXE directory, etc.

I simply do not consider a list of paths a suitable solution in place of an unambiguous pointer to specific files. They are two different things that have two different purposes.

You can use a direct path to the IWAD. If you want to support multiple versions, why not do a special attachment to an iwad parameter.

You could say do

 -iwad doom.wad:c4fe9fd920207691a9f493668e0a2083
 -iwad doom.wad:1.666
 -iwad doom.wad:#3
 etc.

It would complicate things a bit, but you probably wouldn't be using this feature much anyway except for testing purposes.

fraggle said:

If the only reason this is needed is to deal with the fact that the registered/retail versions of Doom 1 are both named doom.wad, this seems like massive overkill.

ReMooD accepts doomr.wad for Registered Doom and also doomu.wad for Ultimate Doom.

fraggle said:

For Chocolate Doom at least, you can use DOOMWADPATH to specify paths to IWAD files directly, not just the directories they're found in. So you can configure it in such a way that it is completely unambiguous, even if there are multiple IWADs in the same directory. Perhaps you should just adopt the same feature.

ReMooD doesn't do this, but it wouldn't be hard to add at all.

fraggle said:

But if we standardize on DOOMWADPATH, we can make a utility that edits that instead. It has the advantage that a good number of ports already support it anyway. We perhaps just need to ensure that all ports support specifying absolute IWAD paths as well as directory paths. I'd much rather we just work to properly standardize that than to go inventing some complicated new system to replace it.

To be fair, it's an extension that I added later. It seemed like a sensible thing to add.

Sounds like a good extension. If an existing port doesn't handle this extension it would endup thinking the IWAD is a directory and just EISADIR anyway.

DaniJ said:

I agree a utility would be nicer/easier.

However, as has been pointed out already, the primary user of such a utility would likely be an inexperienced or new user. Asking them to download another app that they won't be familiar with, just to get started, is arguably more complicated than giving them direction within the OS they are already using. Not to mention that the app will obfuscate what is actually going on and removes the opportunity to educate the user in the process.

I agree on that also. However, perhaps a source port could possibly add a GUI function internally itself also.

* A standard GUI for whatever OSes to change DOOMWADPATH around for IWADs and normal paths.
* A configurator in a port either a separate GUI, or built into the port itself.

And on both of those cases, the same variable could be saved and restored so essentially all of the ports can edit the values.

However for Linux, you'd probably have to probe some local terminal files. Environment could be in any of /etc/environment, /etc/profile, ~/.profile, ~/.bashrc, ~/.bash_profile, etc.

GhostlyDeath said:

You can use a direct path to the IWAD… …to support multiple versions, why not do a special attachment to an iwad parameter

 -iwad doom.wad:c4fe9fd920207691a9f493668e0a2083
 -iwad doom.wad:1.666
 -iwad doom.wad:#3
 etc.

A cleaner approach would be to disconnect the game version from the file paths and name, using separate argument(s) to specify the version of the game you want to play (Doomsday used to handle it like that before the 1.9.x series).

For example:
-doom1-ultimate -iwad doom.wad

DaniJ said:

A cleaner approach would be to disconnect the game version from the file paths and name, using separate argument(s) to specify the version of the game you want to play (Doomsday used to handle it like that before the 1.9.x series).

For example:
-doom1-ultimate -iwad doom.wad

I use -game/-gamemode/-gamemission (one of those) to force something.

The environment variable solution only works well on Windows systems.

Linux systems use config files except for a few environment variables.
Environment variables can get in the users profile or the default profile, or any one of several scripts in /etc that get run at login. None of these will load environment variables when you start a Doom program. At boot time and at login are choices.
Running a script or launcher to start Doom, which also sets the environment variables, is just another version of a config file but more indirect and messier.

I use file links often.

Yadex already has solved this. They have a config file with a line for each possible IWAD.

DoomLegacy already has a config file that is loaded and could handle this more easily than environment variables. That config file can be selected on the command line so debuggers can have their own, and the user can have several for different situations.

It also looks for UltDoom as doomu.wad before looking for doom.wad.
The table that handles this will eventually migrate into the config file, so the user can set not only the name, but all the compatibility switches that are in that same table.

DaniJ said:

A cleaner approach would be to disconnect the game version from the file paths and name, using separate argument(s) to specify the version of the game you want to play (Doomsday used to handle it like that before the 1.9.x series).

For example:
-doom1-ultimate -iwad doom.wad

So if the doom.wad found is actually only the registered version, we can bomb out with W_GetNumForName: E4M1 not found when they pick the fourth episode? Failing to see how that solves my original issue.

Quasar said:

So if the doom.wad found is actually only the registered version, we can bomb out with W_GetNumForName: E4M1 not found when they pick the fourth episode? Failing to see how that solves my original issue.

You should be able to check for E4M1 ahead of time and switch between registered/ultimate mode based on that. If you don't want to detect the version of the wad automatically for the user then what's the point? Only power-users are going to be aware of what version they're using.

If your port autodetects that the wad isn't what the user suggested it was, you might ignore the hint and select the appropriate game mode. Or if you'd rather bomb out, then do that.

I now fail to see the problem you are trying to solve Quasar. This method allows the user to rename their wad anything they want to, as the other argument can be used to disambiguate (i.e., if the user says its Ultimate DOOM then try that first, if that fails then run through your usual detection test order).

I just want to populate my configuration variables with default values. My configuration values allow specifying IWADs for every version of the game unambiguously. None of the suggested solutions apply to that problem so far but instead do something else entirely.

EE has no problems finding IWADs on its own for people who don't care what version they end up playing; I check all sorts of paths and places. That's not the issue and I don't need to add any more switches or hacks to improve that part of the engine.

I thought it would be a good idea to have a unified place, completely optional, on someone's system where they could spell out to any port exactly where they have all of their IWADs by precise version - no need to open every single file found and test its version to see if it matches a requested one - stored. No one seems to agree though so I'll probably be pursuing a unilateral solution at this point.

Eternity tends to cater to power users because it has a small user base. Noobs gravitate toward (G)ZDoom and just throw all their IWADs in one directory anyways.

I myself have the original games fully installed one per directory so that they can also be played in DosBox. I'm not going to change that, ever.

There is no need to go on the defensive. You haven't actually defined the problem you are expecting solutions for. Rather, you presented the community with a proposal to solve your problem and understandably it all went down hill from there.

It sounds to me like the game data recognition/management in Eternity is a lot like that introduced for the 1.9.x series of Doomsday. In Doomsday we also presently populate that data automatically during startup, by systematically processing known paths and data files. So, it might well be that we both need to solve the same problem.

As mentioned in my earlier post, the command line mechanism I described (in response to GhostlyDeath's suggestion) was what Doomsday used to use before we replaced that system.

So, can we start this discussion over?

Quasar said:

Noobs gravitate toward (G)ZDoom and just throw all their IWADs in one directory anyways.

I have all iwads, all pwads and all ports in one directory :)

Even Doomsday?

Yep, why on earth would you want a directory for each iwad?

Pwads are a different animal. Sometimes you need to look into the text file to find out exactly which level the map was designed for and sometimes you have deh files and even more than just one pwad, so it makes sense to store these on separate directories to avoid confusion and unnecessary clutter.

tempun said:

Even Doomsday?

No and that's because doomsday is hardly usable for me, because I don't like launchers and it's much harder to use port if its executable not in the dir with wads. Also, I do not have DOOMWADDIR variable defined, because it introduces some problems for deutex, for example. And yeah, prboom/+ has no support for DOOMWADPATH, it supports only DOOMWADDIR and that's enough for me.

For chocolate-doom, prboom(+), (g)zdoom and some other «noobish» ports I just press Enter on its exe in my file manager or use command line if I need some parameters. Something like that (old video for showing ability to start DOS executables just with single click in my file manager without having any direct sex with DOSBox)

DaniJ said:

There is no need to go on the defensive. You haven't actually defined the problem you are expecting solutions for. Rather, you presented the community with a proposal to solve your problem and understandably it all went down hill from there.

It sounds to me like the game data recognition/management in Eternity is a lot like that introduced for the 1.9.x series of Doomsday. In Doomsday we also presently populate that data automatically during startup, by systematically processing known paths and data files. So, it might well be that we both need to solve the same problem.

As mentioned in my earlier post, the command line mechanism I described (in response to GhostlyDeath's suggestion) was what Doomsday used to use before we replaced that system.

So, can we start this discussion over?

I don't know what else to say in order to describe the problem I see. The problem I see is that IWADs can be installed anywhere and potentially be named anything, and I don't see adding restrictions onto that as being user friendly or actually at all justified.

Every port has different ways of finding files. Fully describing the number of ways you can currently direct Eternity to an IWAD would take quite a while. In order to make life easier and cut down on the use of the command line or the need to drag IWADs around, EE added a built-in launching frontend which lets you select the game you want to play. This is driven by a set of 13 IWAD paths that can be configured in the base/system.cfg file. Configured being the key word.

You can either set them inside the program using the menu UI, or you can manually edit system.cfg. Either way involves pasting the paths of up to 13 files, and if you install Eternity on multiple devices with different layouts, you get to do it multiple times.

How nice it'd be, in my opinion, if there were a one-time-setup global place we could have users tell us where all their IWADs are, by exact version. We could just parse that file or load those variables or what have you and bam, instant unambiguous guess-free access to the IWADs without placing any unnecessary restrictions on where they are stored.

Is this a clear enough description?

This thread is worth an entire The Daily WTF front page article, and pretty much sums up what's wrong with IT (and user expectations) today.

entryway said:

No and that's because doomsday is hardly usable for me, because I don't like launchers and it's much harder to use port if its executable not in the dir with wads.

You don't need to use the launcher at all if you don't want to. Simply launch doomsday.exe with -vdmap "c:/path/to/my/add-ons/" "}data/jdoom/" from the command line and then dynamically load both the game you want to play (e.g, "load doom2") and your add-ons from the in-game console - e.g., if that dir contains hr.wad enter "load hr"

Maes said:

This thread is worth an entire The Daily WTF front page article, and pretty much sums up what's wrong with IT (and user expectations) today.

Not sure which part of the thread you're referring to, whether it's why it's taken so long to catch onto my original idea/issue, or that it doesn't look like there will be a consensus of any type.

I still myself like the ideas that involve either a single environment variable, or a script stored in some standard location. They're both better than my original idea of a billion environment varibles and solve the original problem perfectly. So, at least nobody can accuse me of being stubborn and trying to hang onto my original idea.

Thanks for the more detailed explanation Quasar. Now I get what you are trying to do and that is indeed the way Doomsday does it also.

Naturally it would be best for the community if we can come up with a solution that we can both use. If that means extending DOOMWADPATH then thats fine by me.

I was not going to add more to this, but .... you are describing a setup that is rather similar to mine, and I already have solved this problem for myself.

On my system with prboom and DoomLegacy are executing from the same directory ::
All wads in a separate directory ../wads
Big wads in a subdirectories ../wads/requiem
../wads/Boom ../wads/legacy ../wads/new
All id game wads are in a separate directory from everything else
../wads/id/doomu
Each Freedoom version is in a directory of its own
../wads/freedoom-iwad-0.8
Any iwad that gets used much gets a soft link
>> ln -s ../wads/id/doomu/doom.wad doomu.wad
PWAD I create get soft-linked to where they live
>> ln -s ../maps/map09.wad map09.wad

I am using soft links where you are using environment variables.
The system already supports them, and I do not have to write any code.

DoomLegacy playing ult doom:
>> doomlegacy -game doomu
Looks for doomu.wad, then doom.wad.
It finds the doomu.wad link and follows it to the id directory.

The files in their directories have their original names, only the
soft link names must differ.
Having the doom engine look for doomu for ultimate doom is the only requirement on the engine, and that is just so the user has the opportunity to fix the problem. It still looks for doom.wad if doomu.wad is not there. There is no searching of directories, nor looking in files to get the right one.

All of this is done in the Doom play directory and does not require editing my login profile, nor logging in as Root to change files in /etc.
DoomLegacy gets the environment variables, but I personally do not set them up because of the difficulty. (If I ever have set them up in the past, I have forgotten where or when).

My Edge directory is separate but has soft links to the same wad directories.
This requires no cooperation from Edge.

That is why I cannot accept using Environment variables, but other methods involving files local to the doom play directory are interesting. It is hard to beat using soft links though.
I thought windows had some version of file indirection now ??

A script would still be OS dependent. Different versions for Windows, BASH, Mac, DOS, etc..
A script would hardly be able to be a common solution.
The user changing it would also have to be careful to not make script mistakes.

A config file is better than a script. It is not difficult to write a script to convert a config file into soft links or environment variables, adapting it to what system works best on your OS.
That kind of script would naturally be customized to the OS anyway.
Then editing is easier, and the fragile script code is kept away from where the user is editing stuff.
Different ports could still use the same config file and just have a different script, or access it directly.

wesleyjohnson said:

I thought windows had some version of file indirection now ??

It's had hard links since forever, and full-fledged symlink support since Windows Vista; see the mklink command. (Windows 2000/XP have limited symlink support that doesn't actually work in a generic fashion like they do on linux)

Quasar said:
The only way to change this, believe it or not, is to set an ENVIRONMENT VARIABLE. What is this, the stone age? <...> Personally, I refuse to manipulate the system by adding environment variables. Give me an API function or forget it.

;)

chungy said:

It's had hard links since forever

I thought only NTFS had hard link support.

Never_Again said:

;)

To be fair that's a totally different issue ;) I was complaining about the fact you can't set the SDL video driver from inside the program without using setenv :>