WadExt WAD extraction tool

[Graf Zahl]

I finally got tired of the problems with the existing extraction tools so I decided to write my own.

https://github.com/ZDoom/wadext/releases

This is a simple command line tool that will extract an entire WAD into a mostly PK3-compatible folder structure, it will also decompile all TEXTUREx, ANIMATED and SWITCHES lumps into readable and reusable text lumps (ANIMDEFS and TEXTURES, respectively.) Most of the file formats used with ZDoom will be detected and get a proper extension applied.

Doom format graphics and sounds will be converted to common formats PNG and WAV, this can be disabled via command line.

Comments and suggestions are welcome. Please add any bug reports and feature suggestions to the Github tracker if you have an account over there.
Currently only working on Windows, if someone wants to make it work on Linux or maxOS, please drop me a line so that I can add you to the repo.

[Rachael]

This is amazing! Thank you, Graf! I hope this is better than Unwad... whose author has, sadly enough, gone completely MIA.

One thing though - would it be possible for it to default to extracting to a folder? i.e. "wadext 1.wad" would default to extracting to ./1/

[Graf Zahl]

Sure, that can be added.

[Rachael]

Thank you!

[eyesoftheworld94]

This is a god-send. Thank you Graf! Also, I do think this tool should be added to "resources/utilities" (and/or stickied) on most Doom sites (like here on the Resources subform) as well as DoomWorld, and the Doom Wiki. (as well as that Animator program/utility too)

[Kinsie]

Excellent stuff! This would have saved me a lot of hair loss in the past, and it'll probably save me some in the future, too!

[Xaser]

Heh, nice! For funsies, I pointed it at Zen Dynamics, pk3'd it, and it worked swell. Plus shaved 10+mb off the filesize.

[Ed the Bat]

I should fire this upon every WAD-format project I've made a revision for but didn't feel like going the extra mile to make it a pk3.

[Nash]

Thank you! This was desperately needed and now I no longer have to fiddle with bagheadspidey's unwad which will always crash if not invoked from the same directory it's in!

[CWolf]

Jesus, finally, it happened... Thank you very much.

[_mental_]

Currently only working on Windows, if someone wants to make it work on Linux or maxOS, please drop me a line so that I can add you to the repo.

I have made pull request with related fixes.

[MartinHowe]

Excellent idea, well done GZ I had been considering how to find time to write my own as I'm so fed up with UnWAD - now I don't have to

[Graf Zahl]

I'm so fed up with UnWAD

Is there anyone who wasn't? I actually tried first to fix this thing but if was so overloaded with GCC'isms and other bad design decisions that I passed. The ultimate insult was this inept third party file format matching library that was too stupid to find its data files and caused the crash. And that thing wasn't even GOOD! It missed nearly all the formats which are relevant for ZDoom and did a piss-poor job at some with bad identification marks.

[Nash]

Okay so I finally decided to replace my build scripts to get rid of Unwad...

I expected it to extract all the individual lumps (as seen in my SLADE screenshot), but instead it just made this folder called MAPS and made a WAD which is an exact copy of "nash test 01.wad" just named differently.

Also shown is the cmdline I use.

Am I using this wrong, or... ?

What I wanted to do with this is extract the SCRIPTS lump so that I can run acc.exe on it.

(This is part of a build script that attempts to compile all embedded scripts in every map WAD so that don't have to do it manually. Eventually when the project will have many maps, I do not want to: open map01 in GZDB, F10, hit compile, save, close, open map02 in GZDB, F10, hit compile, save, close, etc etc etc...)

I was using Unwad this way and it worked, except that I had to robocopy the entire Unwad folder in the build script because attempting to invoke it on a WAD from a different directory will just crash the program... >8[

[Graf Zahl]

Wadext does not extract separate level lumps, it keeps them together - except for that ENDMAP bug.