Giomancer

You mean intermission texts? No reason not to put them in, really, especially if you already have an idea.

Aha! What happened, as it turns out, is that I "got lucky"; I discovered that acc was just including the default files, which would have been great until I added global variables. The fixed snippet looks like this: Thanks for explaining what was up!

Not sure if this is an ACC bug or a WadScript one, but here goes: When I call ACC using execresult(exec)) and my args use the [-i]nclude option, ACC will fail (printing the usage help) unless I either have the [-d]ebug option or "null". Running ACC from the command line, however, is normal. Examples: args = [acsFile]; // works; outputs object file. args = ["-i" + includeDir, acsFile]; // fails; prints help text args = ["-i" + includeDir, null , acsFile]; // works; outputs object file. I am using the latest releases of both, using bash on Win10. Not the worst thing ever as it was simple enough to work around, but I thought I'd mention it.

Chocolate-Hexen Vanilla analog Chocolate-Hexen-Plus-Plus Raised limits Crispy-Hexen (works but is not 'crispified') Limit removing Doomsday Fancy things! DSDA-Doom Supports Hexen, but I believe the fancy stuff is mostly Doom-side. k8Vavoom Not recommended for 'vanilla' experience. Might kill your dog. (<3 ketmar) Vavoom Fancy things! EDIT: Don't forget to make sure your Hexen IWAD is properly patched to version 1.1.

To give you more details, the process in question is a windows-native command line utility called pngout. Your idea for a workaround was partially successful, at least, as the rest of the doommake script was able to print to the console. Unfortunately, however, pngout also refused to print to the buffer, so I made do with declaring the output stream as null, which worked.

This loop each (pngFile : pngList) { arguments = ["/c3", "/f0", "/d8", "/kgrAb", "/y"]; arguments->listadd(pngFile, 0); println("Compressing " + pngFile + "..."); execresult(exec(exepath, arguments, envvars(), exeworkdir, stdout(), stderr(), stdin()); } iterates properly but only displays to stdout the first time through. Worse, the loop stops the rest of the script from displaying its own output, though I've confirmed that everything does get built correctly. I've spent the past day or two trying to figure out what's going on, trying different things, and I'm fairly sure I'm simply too much of a novice to understand. With the output-quashing loop What the script outputs normally; note the textures and project wads print their success.

Somewhat related, but the game Radix: Beyond the Void (published in 1995) has been converted to the Doom engine by Jim Valavanis using his port DelphiDoom as a base: RAD Engine. It's a backdoor into the Doom world, but it's worth thinking about.

Short version: you are absolutely correct. Still, you're pointing at the exact reason I believe a port similar to the one I mentioned would be a good thing if it were made. Plenty of current Doom standards are de facto (Boom 2.02, MBF 2.04, DeHackEd, DECORATE, etc.); they only exist at all—as standards, at least—because they were copied/inherited by other ports: good (or popular, anyway) ideas tend to spread themselves around. @kraflab has taken the "implement first" route with DSDhacked; the main difference is that they have given us a spec instead of forcing programmers interested in the idea to dig through the DSDA-Doom source. Like I said, you're not wrong; without either a referential implementation or a serious discussion-with-intent, all of this is just a thought exercise.

@MTrop edf.7z The 7z file contains: doommake.properties merge-edfs.script doommake-libee.script doommake.script Since my current project is for Eternity, I decided to start with adding EDF handling. The most difficult part was trying to decide how to deal with reading a single file then the whole directory. The way the merge script works currently requires a cleanup step in post, but I keep wondering if there isn't a more elegant way to do it. EDIT: Finished, cleaned up, and updated!

Based on earlier talks with ketmar and following this thread, I would like to see a fork of Pooch that abandoned all DeHackEd support and implemented this theoretical DECOLITE system as well as a scripting language like RookScript or Scheme or Lua.. I bet people would go to town on that sort of thing. Too late for my birthday, but if anyone wants to shoot for Christmas..

Here's one, an experimental WinMBF branch by AlexMax that I called "LBF" (Lua's Best Friend). @AlexMax had another experimental WinMBF branch using AngelScript that I called "AngelMBF". These might be useful to look at.

So I started playing around with DoomTools about a fortnight ago, and it's been interesting. I've put most of my efforts into learning DoomMake and ripping apart its various scripts and customizing things to my liking (f/e, "doommake clean" cleans both the 'build' and 'dist' directories, while "doommake release" builds a distcopy). I've started working on "libraries" to extend what I can do within the framework of DoomMake.. I'll post if/when I have something working.

Sweet! I always find it preferable to dig up original sources rather than nick them out of WADs. (So I say, but how many sprites and textures do I have floating around that have no known origin? Sigh.)

Slightly off topic, but do you have a source for Turbo's pistol sprites, @Jimmy? Unless they were for private use, of course.

The usual suspects: Delphi Doom, Doom Legacy, Edge, Doomsday, and Risen3D.