GhostlyDeath
Forum Retard
Posts: 1008
Registered: 08-05 |
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
code:
-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.
|
08-05-12 15:05 
