Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Bashe

Strainge ChocoDoom behaviour with ZDL

Recommended Posts

I'm a fan of the ZDL launcher for my Zdoom games, but I wondered if it was possible to use it for ports other than Zdoom, so I gave it a shot.

I tried Chocolate Doom first, and when I got it all configured and ran Doom 2 with it, it worked like a charm. Then I decided to try using a PWAD and the strange behaviour began. When it started up, the wad was loaded, but my configuration was missing and it was using the game's default config for a first-time run. I was rather confused by this, considering it ran fine the first time, so I did some investigating, and oddly enough, I found a new chocolate-doom.cfg and default.cfg in my PWAD folder (which is kept in my Zdoom folder). I deleted the PWAD out of ZDL's list and just ran it straight with Doom 2 again, and the problem persisted, but this time the new configs were just in the Zdoom folder.

I really don't know what to say about this. I'm not sure if it's a Chocolate Doom bug, or a ZDL bug, but it's weird. It seems to make a new config whenever I change WAD folders and run the game, which is so weird. I'm using ZDL 3.1, an updated version of 3.0 made by Risen.

Share this post


Link to post

I'm not familiar with ZDL but at a guess it looks like ChocDoom expects to find default.cfg wherever the last-named wad's located. Have you tried adding -config <wherever it is> in the command-line arguments to force ChocDoom to use it's own default.cfg file?

Share this post


Link to post

2 words: WORKING DIRECTORY

A running application is given several environment settings by the operating system, among which is the "working directory". The working directory is controlled by the process that spawns the application's process. In the windows command console, the working directory is the directory you are currently at when you start the application.

For exmaple;
C:\MyWads\> C:\ChocoDoom\chocolate.exe -bla -bla

This will run chocolate.exe with C:\MyWads\ as the "working directory".

The working directory is automatically used inside the application when relative paths are specified by the programmer (or none at all). But a programmer can also get the directory where the application actually resides and use that instead. When Chocolate Doom read/writes your settings it uses a relative path instead of the absolute path where the application resides. This causes you to "lose" your settings when the game runs with a different working directory.

Share this post


Link to post

I didn't know that, Code. Now I do. Thanks!



Well, if worst comes to worst, I'll just create a giant clusterfuck folder for wads and cfgs and stuff to solve this problem.

Share this post


Link to post

The ideal behavior would be that Chocolate Doom would use the User's Local Application Data path for configurations and the absolute path to the location of the executable for dependencies such as .dll files, the IWAD and any other required resources. The working directory should only be used when files are specified with relative paths through command-line parameters (-iwad and -file). This goes for most applications really.

Share this post


Link to post

I completely agree but as another Windows-based developer working on applications in the DOOM scene; I know from experience that this community simply does not like to do things the "Right Way", on the Windows platform(s).

The DOOM community, by at large would much rather (for example) a source port simply dump everything it uses/needs into it's own base folder and be done with it. Despite the fact that concepts like User Local Application Data are there to make their life easier in the first place.

Share this post


Link to post

That is because everything in this Doom scene comes from a time when the Application Data directory didn't exist yet. That directory was only introduced in Windows 2000 (maybe early on other NT-based OSes, but those were not used for the common desktop-system at that time). Doom Builder 1 also uses the application's directory to store it's user settings because it was made on Windows 98. But at least it used the application's directory and not the working directory :P

Share this post


Link to post

If I read that right, you guys are talking about storing configuration files and iwad files in the documents and settings area?

If there was just a "C:\Documents and Settings\User\My Documents\My Games\Doom" and then inside that directory resided an IWAD folder, and then other folders specific to source port for holding configuration files, that would be pretty neat.

I'm satisfied with how things are right now, though. As it stands I could burn my entire doom directory to dvd, move it to another windows based pc, and have it be fully functionally without changing anything.

(I use batch files and .\ to make that work, that way it doesn't matter where I move directory, so long as I don't change it's contents too much.)

Share this post


Link to post
CodeImp said:

The ideal behavior would be that Chocolate Doom would use the User's Local Application Data path for configurations and the absolute path to the location of the executable for dependencies such as .dll files, the IWAD and any other required resources. The working directory should only be used when files are specified with relative paths through command-line parameters (-iwad and -file). This goes for most applications really.

On Unix systems, the configuration files and savegames get stored in your home directory, in ~/.chocolate-doom. For Windows, it just does what the original Doom did (ie. use the working directory). But you're probably right.

Share this post


Link to post

I'd hate to have to browse away from my DOOM folders to tweak a CFG. If using a user folder it would likely end up somewhere in C:\ when the DOOM stuff is in D:\. Programs that dump files in remote locations fail it, as far as I'm concerned. If multiple configurations are needed per user it shouldn't be hard for a program to create a CFG named after the current user, used for that user by default.

I guess a file telling the program where to store CFGs could also work for Chocolate Doom, such as choosing from:

Working directory (default)
DOOMWADDIR environment variable
Executable's directory
User's Local Application Data path

GreyGhost said:
I'm not familiar with ZDL but at a guess it looks like ChocDoom expects to find default.cfg wherever the last-named wad's located.

This weird behavior comes from ZDL, which somehow sets the working directory to be the PWAD's directory. Evidently ZDoom does not use this "feature" for anything, because Bashe is not having this problem using ZDoom and PWADs.

So, why is ZDL even applying the working directory to the location of an optional file? Apparently because of a bug that does not affect the engine it is made for (as it seems to use the application directory instead of the working directory). Maybe some other source code modification ZDL was tested with sets the working directory to an addon's directory.

Bashe said:
Well, if worst comes to worst, I'll just create a giant clusterfuck folder for wads and cfgs and stuff to solve this problem.

I'd just use some other launcher to run Chocolate Doom if I were you. You can also use the extra command-line arguments line to force the CFG to a location with -config like GeryGhost suggested. Arguably, the extra parameters box is shitty because it should allow a pull-down menu with various previously used options (including "none") so as to not have to retype the extra parameters every time depending on what is needed (unless the OS can and is set to recall such input). You'd be using the extra command with Chocolate Doom and not with ZDoom, that is.

Share this post


Link to post
myk said:

I'd hate to have to browse away from my DOOM folders to tweak a CFG. If using a user folder it would likely end up somewhere in C:\ when the DOOM stuff is in D:\. Programs that dump files in remote locations fail it, as far as I'm concerned. If multiple configurations are needed per user it shouldn't be hard for a program to create a CFG named after the current user, used for that user by default.

Editing configs manually is soo last century. A well written, modern, large-ish application/game shouldn't ever require they be tweaked by hand anyway.

Still, a setting which chooses between saving a config in the user's dir as opposed to working with configs in a central location, named similarly to the user shouldn't be much work. We reached the same compromise in Snowberry (Doomsday launcher).

Share this post


Link to post

DaniJ said:
Editing configs manually is soo last century.

That's kind of like saying "walking is a stone age mode of locomotion" just because Neanderthals would walk too. I find editing CFGs manually is often more convenient and transparent than browsing though menus (which might end up cluttered), having to open and navigate in a secondary GUI or typing commands in a console. And we're talking about Chocolate Doom here, which attempts to be a port of the plain game, where such manual editing has always been of some use. Some modern accommodations should help portability and usability, but stuffing every newer method on it just because doesn't make sense.

The fact is, CFG editing is not so uncommon nowadays. Not in professional software, but they're usually interested in keeping the user away from core files anyway. Most free software does leave configs in handy locations so people may access them directly if they find it convenient (and it's not bad for portability either because it makes the program into an unified bundle).

Share this post


Link to post

I was speaking more in general terms, not specifically directed at Chocolate Doom.

Personally, the only time I have to edit configs manually these days IS with DOOM ports that don't offer a better means.

Share this post


Link to post

I like inis and configs in their application directory, especially if they are applications that don't require anything else to be outside the directory. Equally, I dislike everything being lumped together in some centralised directory. Just my personal preference really. Probably something to do with me being familiar with older OSs. "Special directories" were one of the things that bugged me about the Mac that I used to own back in the days when a Mac was an all-in-one thing with a tiny black-or-white screen built in.

I know that some people might find that easier and it is useful for multi-user computers but I personally find it messy and I only have one account on my machines.

As for doing it "properly" the fact that MicroSoft seem to change their minds as to what "properly" is on a fairly regular basis makes it hard to keep up with what is supposed to be correct. Anyone with a range of software from a few different years will have a variety of methods being used on their computer, many of which would have been considered "proper" at some point.

[rant]What's more, I'm fed up with Windows assuming that I want more than one account on my machine and working as if I have that. Transparently merging "all users" and my account into one menu under the start button is just one example of how the system tries to kid me on that my OS is doing something that it isn't. Whenever I try to organise my menus manually, I have to look in both "all users" and my own folders to make sure I have found everything. If I'm doing that, I always transfer it to "all users" because it simplifies it and my account is all the users that will ever be on the machine. And I don't need special sub folders set up all over the place with my user account name on it to distinguish it from... oh yes, all the other accounts that don't exist on my machine.[/rant]

/in b4 the inevitable "ask me about Windows user accounts" comment :roll:

Share this post


Link to post
DaniJ said:

Personally, the only time I have to edit configs manually these days IS with DOOM ports that don't offer a better means.


I dunno, a lot of games - even modern ones - can be tweaked by editing config files. Doing so usually allows access to things that are not on a menu and it is possibly an easier method that trying to do it via a console. In fact, sometimes you need to edit the cfg to enable the console. ;)

Share this post


Link to post

Yes but the whole reason behind disabling the console by default in a release version is an attempt to stop people from messing with settings that might stop the application/game working correctly and/or lead to tech/user support headaches. I dare say there have been more than one instance where a user thought they "broke it" simply because the application-internal command console appeared.

I think it is fair to say that if a user can and is happy to, find and edit a config file manually, then they are responsible for fixing it if they "break" something.

Also, I bet that most modern users never even bother to find the config file(s) unless there is something they want/need to do that isn't available via a menu or an application-internal command console (which to be honest should be practically nothing more than enabling said console).

Share this post


Link to post
DaniJ said:

Also, I bet that most modern users never even bother to find the config file(s)



I'd rather guess that most of them don't even know what a config file is! :D

Share this post


Link to post
DaniJ said:

Also, I bet that most modern users never even bother to find the config file(s) unless there is something they want/need to do that isn't available via a menu or an application-internal command console (which to be honest should be practically nothing more than enabling said console).


You're probably right, or perhaps what Graf said. I suspect the first time they need to is shortly after doing somthing like typing "cheats for (insert kewl game here)" into Google.

Share this post


Link to post
Enjay said:

[rant]What's more, I'm fed up with Windows assuming that I want more than one account on my machine and working as if I have that.[/rant]

I've been living that nightmare since Windows NT4. :(

Share this post


Link to post

The "working directory" is not well defined for normal (GUI) applications. Linux (GNOME) behaviour is different from MacOSX which is different from Win32. Windows is actually sanest, usually being the directory the app you just double-clicked on, but I have seen to change to something weird (inside the system folder) when dragging an dropping files onto the app, and I couldn't say what it becomes when starting the app from the Start menu or a desktop link.

Hence you really need some policy for setting the working directory yourself. I prefer to set it to where the application EXE is, and find any needed data/config files there (you could probably call this the "local" model).

Share this post


Link to post

I remember a few years ago, Zdoom switched to using a user's directory to store the zdoom ini rather than just the zdoom directory. Oh boy, what confusion that caused for a while.

Share this post


Link to post

The Registry deserves to be nuked. This is the worst thing anyone has come up with:

All config data in one huge file, hard to edit and if it gets trashed you can reinstall your system. No, thank you.

It would have been fine if it had been restricted to the system but no: It was advertised as the primary place to store configuration data and Windows's system configuration devolved into an incomprehensible mess.

Share this post


Link to post

Oh yes. The registry is an awful, awful thing. As you say, system only would have been fine but allowing every man and his dog to add entries to it that are effectively hidden, likely to have impenetrable names and which just get lost in the morass of cryptic entries yet add layer upon layer upon layer of confusion and complexity to the registry, bogging it down and tying your machine in knots makes it a terrible, terrible strangle and liability just sitting there as an essential part of your machine. And that's when it's working "properly". Having one point on your machine that can easily cripple it if it goes wrong, then allowing, no, advising anyone and everyone to write their applications to make changes to it is more madness than Sparta.

Share this post


Link to post

Oh, I don't share your view. The user profile, the computer management console, the registry, etc. are all aimed at managing dekstops in a corporate environment. I happened to administer such network with 3000 desktop computers and boy how much these hated things help things organized.

Since MS didn't bother to release a substantially different OS for home usage we happen to play on a system aimed at large companies.

Share this post


Link to post

Oh god... the registry.. uhhahhhg. I COMPLETELY agree with you guys, that is a horrible place to be storing configuration data.

It's ok for storing CD-keys I suppose, but that's all that should be there.

Share this post


Link to post
rpeter said:

Since MS didn't bother to release a substantially different OS for home usage we happen to play on a system aimed at large companies.

Yeah, that's something else that bugs me. In fact, I suppose it is the root of the other annoyances that I mentioned. Why even bother calling it the "home" edition when so much of its protocols are clearly set up for business? (I know, I know, marketing.) From day 1 it became pretty clear to me that my copy of XP Home was really intended, at its core, to be sitting on some one's desk at work as part of a multi-user network. A number of things about it are inappropriate or clumsy for the way I, as a single home user, want to administer my machine.


That being said, I still don't see how putting all the settings in a single, critical file and then encouraging any old third party program to tamper with it is a good idea. Particularly if that file is then difficult to work with, repair or even make sense of much of the time.

Share this post


Link to post
entryway said:

FAT32? HDD from 1996?

It doesn't need to be FAT32, nor a hard drive from 1996 for the registry to give you hell.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×