running pwads on Mac Zdoom?

For some reason I am having trouble getting pwads to run on my version of Mac Zdoom. Any help is appreciated!

version 2.7.1

cd ZDoom.app/Contents/MacOS/

./zdoom -file myHouse.wad

Doesn't it work by drag-dropping stuff?

printz said:

Doesn't it work by drag-dropping stuff?

No. It does not work. I thought it used to, but I don't really remember how I was loading wads in mac zdoom. I thought that was how I was doing it. Or dropping the wad into the MacOS folder within the app's resources. Neither are working now.

Ribbiks: I don't know where to write that command line. If you could give more info I'd appreciate it. Do I type it in Terminal? I never use Terminal. Not really familiar with it.

yeeup, terminal ftw, fire it up. and you'll need to navigate to wherever you have zdoom installed. so your actual cd command might look something like this:

cd /Users/Hellbent/Desktop/Games/Zdoom.app/Contents/MacOS/

./zdoom -file /Users/Hellbent/Desktop/myWads/myHouse.wad

It's ironic that on the platform which has always claimed to be "much more user friendly than dumb old DOS" and on which "things just work" compared to buggy old Windows, nowadays one has to use the command line as if he was a 55 year old UNIX guru ;-)

It's not ironic. Doom ports have only rarely been properly independent of the need for the command line. Don't take these programs as representative of Apple UI design (which has many flaws of its own IMO, but that's off-topic). :P

Well, it's not just Doom, actually. It seems that on the OS X based Macs, most of the advanced administrative stuff can only really be done via command-line tools in the most traditional UNIX fashion, with the user friendliness being not only lower than that of Windows (if we exclude stuff that uses the do-it-all net command), but even than that of many free linux distros. There simply aren't enough "for the rest of us" utils for some tasks. OK, users who need to do these tasks will probably not mind, but still.

Quite a change for a platform that until Mac OS 9 had no command line at all.

If you drag and drop a file on an executable file in Windows (not necessarily a .exe, it'll work with .bat, .com, and any other extension set to be executable) it'll result in a "virtual" command line. Like, drag foo.dat on bar.exe, and it'll execute "bar.exe foo.dat" (except with full paths for both).

ZDoom doesn't need the -file parameter. You type "zdoom mywad.wad" and it'll be the same as if you typed "zdoom -file mywad.wad". The only reason you could have for using -file on ZDoom is that it allows you to make the .wad extension optional (so "zdoom -file mywad" works, but "zdoom mywad" won't IIRC).

Now what happens if you make A + B? You get "dragging a wad file on the ZDoom icon just works (in Windows)". Drag foobar.wad on the ZDoom icon, and Windows will run the command "zdoom.exe foorbar.wad" and it'll work.

On Mac it doesn't work, of course. Because when you're a Mac user, you need to think different. And in this case, thinking different means opening a terminal to type a command line so as to do something that the user-friendly GUI is absolutely incapable of doing.

Gez said:

On Mac it doesn't work, of course. Because when you're a Mac user, you need to think different. And in this case, thinking different means opening a terminal to type a command line so as to do something that the user-friendly GUI is absolutely incapable of doing.

Incapable? No. Drag-and-drop has been a standard feature for Mac OS programs since dinosaurs roamed the earth. It's only Doom ports that usually haven't bothered implementing it.

It's just one of several anti-user design issues that have gone along with most Mac Doom ports for some reason, such as the particularly inexplicable requirement for IWADs to be stored in a library folder that's hidden by default, rather than looking for them in the port's directory or even prompting the user to locate them. It's unheard of for well-behaved Mac programs to just refuse to run unless the user drops some data files into an obscure location first, but Mac Doom ports do this under the misconception that it's more Mac-OS-standard this way. In my experience, even when programs do use library folders for user-specified data (such as plugins), the program itself will provide a straightforward interface for it, typically transparently installing the files where it wants them to go without hassling the user to dig around for it.

FWIW, the Mac version of Eternity has drag-and-drop, which is integrated very nicely into its built-in launcher interface which allows for command line options to be set either manually or via a GUI. It's a nice setup, both for its ease of use and for the ability to quickly skip past it and get the game started as-is just by pressing enter. I'd like to see that in more Doom ports.

Last I checked the ZDoom app supported drag and drop. The issue is unlike Windows, Mac's drag and drop is done through some programmatic interface instead of passing through the command line. Arguably a better solution of course.

Also if you want a 100% better experience on the Mac, install the osx_native DRD Team builds. You'll get better OS integration as well as considerably better performance.

esselfortium said:

rather than looking for them in the port's directory

/Applications is a lovely place for your IWADs isn't it?

The Mac clearly isn't designed for the model where you need to provide third party data, especially third party data not designed for the Mac. No matter what option you give it will be suboptimal. Not that this is really a knock on the Mac, Linux is more or less like that as well. At least in that case you could install the data to /opt/zdoom/ (ZDoom does look inside the app bundle if you want to compare to that I suppose).

Blzut3 said:

/Applications is a lovely place for your IWADs isn't it?

/Applications/Doom/ is.

When you need to store other data with the program, subfolders are still the way to go. Mac programs like Reason and Photoshop give you a folder to copy into Applications, housing the executable and other related files that the user should have access to.