Doom Eternal *.resources unpacker

[iOrange]

Made a simple command-line unpacker for Doom Eternal *.resources game archives.

Usage:

Code: Select all

DoomEX.exe path_to_resources_file output_folder

Tool:

DoomEX.zip

Github: https://github.com/iOrange/DoomEX

[Ize]

Awesome! Will you add support for eternal to your doom resources explorer?

What's the best way to convert the meshes to a "usable" format right now? I'd love to 3d print the main menu podest and the doom slayer on it

[infogram]

Nice work! A friend also got QuickBMS working with it too: https://zenhax.com/viewtopic.php?p=54753#p54753
(also posted some info about working with the games string files there, if anyone wants to work on translations)

Any idea how hard it'd be to make a repacker for this?
I know DOOMExtract could repack 2016's files but this new IDCL format seems a lot different, maybe more needs to be figured out first before that can be done...

E: BTW it looks like your tool doesn't handle any decompression? I saw that QuickBMS had support for Oodle decompressing, maybe worth looking into adding that too? (unless the game doesn't even use it, that is...)

[GRiNDERKILLER]

Nice work but it doesn't decompress files. Or Am I wrong?

[OrangeC]

Hmm any idea for the .pck .snd files.

[iOrange]

E: BTW it looks like your tool doesn't handle any decompression? I saw that QuickBMS had support for Oodle decompressing, maybe worth looking into adding that too? (unless the game doesn't even use it, that is...)

Unfortunately the game is using Oodle for compression, and Oodle SDK is non-free, so I'm not quite sure how to handle this property.

My next step is to make a converter for textures and models

[iOrange]

Ok, so I added decompression. Just copy "oo2core_8_win64.dll" from Doom Eternal folder to DoomEX folder and run as usual.

Download:

DoomEX_v02.zip

Source code: https://github.com/iOrange/DoomEX

[Ize]

Decompression seems to work but i couldn't get any of the lightwave models to load in open 3d model viewer and the textures are in BIM format, whatever that is

[infogram]

Ok, so I added decompression. Just copy "oo2core_8_win64.dll" from Doom Eternal folder to DoomEX folder and run as usual.

Download: DoomEX_v02.zip

Source code: https://github.com/iOrange/DoomEX

Cool, thanks!
This new IDCL format looks crazy, got no idea how a repacker could be made for this, so many unknowns >.>
Maybe someone will figure out a way to let it load loose files instead of needing to pack, would save a lot of time.

Decompression seems to work but i couldn't get any of the lightwave models to load in open 3d model viewer and the textures are in BIM format, whatever that is

I think DOOM 2016 used bimage files for some textures (not all since a lot were mega-texture crap), I guess maybe BIM is the same thing, pretty sure I saw some work on bimage files being posted before.

[GRiNDERKILLER]

BIM seems to be almost same as MIB struct but in LittleEndian. But i saw that there is only header but no raw data at least at fonts. Looks like they are most probably in *.streamdb. But no clue where are offsets for them.

EDiT:Also seems like resources are somehow protected against editing. I tried edit plain text from false; to true;
and left same size of text and game refuse to start. On second run steam re-download whole resources.

EDiT1: Uff streamdb luckily are not protected. I cut half of last streamdb archive and game loads fine. And it was obvious on first look. Missing textures. So there will be fonts textures.

EDiT2: OK I finally find location of font textures if anyone interested. In: gameresources_0_1.streamdb. Now I must find right raw data. I think some clues should be in BIM headers.

[CharlieV]

Maybe it's just over my head but when I used it all that was extracted were <20kb files referencing the real files in the gameresources .streamdb archives. The tool for Doom 2016 was a great help to me a few weeks ago, but it seems the Wolfenstein games have been a lot of trouble and this will be closer to those, I'm in no rush I'll just be glad to see something comprehensive made for this eventually too no matter how long it may take

[ArtyDoesStuff]

Wow, the unpacker works like a charm! Thanks for that.

How's the research on texture/model conversion coming, also? I've looked through the unpacked files, and they're all in such strange formats. BITEXTURE, .entities, etc. It looks like It's going to be quite hard getting them ready to extract, though I don't think it's that much different than 2016 except that Mega Textures aren't a thing anymore. But that's just my thoughts, I could be wrong, but it's something to look into.

[infogram]

EDiT:Also seems like resources are somehow protected against editing. I tried edit plain text from false; to true;
and left same size of text and game refuse to start. On second run steam re-download whole resources.

Hmm, I did see some mention of hashes in the code that handles the IDCLs, maybe one of the unknown tables contains hashes/signatures.
I did see some table which had way more entries than the number of files, this could maybe be hashes of blocks inside the files, (no idea what the block-size or anything might be tho), but pretty sure I saw some string mentioning data-blocks anyway.

I saw WolfstoneExtract also has IDCL format pretty detailed too, not sure if it includes much more info than we already know about, but it does handle both version 11 and version 12 IDCLs though: https://bitbucket.org/ecwolf/wolfstonee ... e_idcl.cpp

(Also kinda off-topic but I decided to try figuring out what all those Oodle unknowns are, but then I found this project which is a pretty detailed disassembly: https://github.com/powzix/ooz
The kraken.cpp also has prototypes for the Oodle DLL exports (OodleLZ_Decompress / OodleLZ_Compress), which are a lot more complete than any other description I could find on the net:

Code: Select all

typedef int WINAPI OodLZ_CompressFunc(
  int codec, uint8 *src_buf, size_t src_len, uint8 *dst_buf, int level,
  void *opts, size_t offs, size_t unused, void *scratch, size_t scratch_size);
  
typedef int WINAPI OodLZ_DecompressFunc(
  uint8 *src_buf, int src_len, uint8 *dst, size_t dst_size, int fuzz,
  int crc, int verbose, uint8 *dst_base, size_t e, void *cb, void *cb_ctx, 
  void *scratch, size_t scratch_size, int threadPhase);

Hopefully this'll show up on google if anyone tries looking for them, took me a bit of digging to find, big thanks to powzix of course)

[GRiNDERKILLER]

I did some research on BIM so here is what i got so far. Alot of unk flags and skiped some bytes. But it should parse all BIM header.

• local int i;
  
  int64 id;
  int mipmapflag;
  int mainwidth;
  int mainheigth;
  int null;
  int mipmapcount;
  int64 null;
  byte flag;
  int flag;
  int compchar;
  int flag;
  FSkip(6);
  short flag;
  short flag;
  short flag;
  short flag;
  
  for(i=0;i<mipmapcount;i++) {
  
  struct {
  int64 mipnum;
  int width;
  int heigth;
  int flag;
  int mipmaplayersize;
  int flag;
  int64 id; //or something
  } mipmap;
  };

[exhaleme]

It seems porter and id-daemon have already figured everyhing out

https://twitter.com/dtzxporter/status/1 ... 1874179078
https://twitter.com/dtzxporter/status/1 ... 0879270913