xaymar / hellextractor Goto Github PK

The current export format, Wavefront OBJ, is extremely limited:

• Only a single normal layer.
• Only a single texture coordinate layer.
• No bones.
• No weights.
• No supported for vertex colors.

Ideally we should switch to an easier to work with format. glTF seems to be a reasonable option.

Width: 4 bytes

secrets.GITHUB_TOKEN doesn't have permission to create releases can you check
https://github.com/Xaymar/Hellextractor/settings/actions

Describe the Feature

This file appears to only contain c-style null terminated strings.

uint32_t __unk;
struct {
  uint32_t length;
  char text[length];
}; // So far, always only one.

Possibly only used to mark the .wwise_bank as used?

Width: 4 bytes

Yeah, see title. unordered_set does not guarantee the order of inserted elements, it just means that it doesn't do the added sorting. So the element order is entirely random, which I guess is faster, but not what we want.

Width: 8 Bytes

Describe the Feature

For what it's worth, we've never seen the first 16 bytes change. They probably have no meaning for us at all, so just strip them off.

Describe the Bug

C:\Users\User 1\Hellextractor>hellextractor.exe
'hellextractor.exe' is not recognized as an internal or external command,
operable program or batch file.

Did all Building steps, but receiving this stuff everytime.

And, because of it:

Executing: extract -o ./output "c:\program files (x86)\steam\steamapps\common\Helldivers 2\data"
Start-Process : This command cannot be run due to the error: The system cannot find the file specified.
At C:\Users\User 1\Hellextractor\hellextractor.ps1:113 char:5

• Start-Process -FilePath "./hellextractor.exe" -ArgumentList $comm ...
  

• ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : InvalidOperation: (:) [Start-Process], InvalidOperationException
  • FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

Last known working version

No response

Width: 4 bytes

Seems that bitsquid (stingray) partially moved to 64bit offsets and header includes some clues for read buffers
E.g. aligned offsets seems to suggest that during load they allocate full buffer size or smth like that.
Here's file header as I see it:

    struct file_header_t {
        le hash::hash_name name;
        le hash::file_type type;
        
        // aligned to alignment
        le u64 offset;
        // unaligned raw aux buffer
        le u64 stream_offset;
        // aligned to gpu_alignment
        le u64 gpu_offset;
        
        // aligned to 0x200
        // seems to be an offset of read buffer that have size of 0x200 per element
        le u64 buffer_offset;
        // aligned to 0x600
        // seems to be an offset of read buffer that have size of 0x600 per element
        le u64 gpu_buffer_offset;
        
        le u32 size;
        le u32 stream_size;
        le u32 gpu_stream_size;
        
        le u32 alignment;
        le u32 gpu_alignment;
        le u32 index;
        
        file_t<size> inline_file @ offset;
    };

Describe the Feature

Hello can you also make one for Helldivers 1?

Describe the Feature

Common structure so far

uint32_t __unk;
uint32_t offset;
uint64_t dep_name_hash;
... actual data ...
... seek(offset) ...
uint32_t __unk;
uint32_t __unk;
uint32_t __unk;
uint32_t __unk;

With 2023178 most of the format of the .texture files was figured out. We know how to read the file and even what it does, and should be able to export it completely without errors.

The header (0xC0 bytes) simply tells us how we could stream mip levels in the texture file, so that we use less memory overall. This is why the header for the texture itself is in the main file, but the data is in the stream file. As for the data in the gpu_resources file, that is simply an exact clone of the data in stream, usually starting at mip level 2 (1/4th resolution).

As far as it seems, all textures are .DDS files. There are references to .TGA files, however I have yet to find an actual tga file. Might be useful to inspect the first 4 bytes and decide based on that.

Describe the Feature

As far as files go, it appears as if these files have a mostly common 12 byte header.

uint32_t __unk;
uint32_t __unk;
uint32_t offset;
... seek(offset) ...
uint32_t __unk;
uint32_t __unk;
uint32_t __unk;

Describe the Feature

If this is out of scope for the Hellextractor, please remove this request.

I did a very simple test with a bik file (b2b8b34553f957cb.bik) from the extraction using a very basic ffmpeg command line command using ffmpeg essentials build and command ".\ffmpeg.exe -i b2b8b34553f957cb.bik b2b8b34553f957cb.mp4", which resulted in an encoded mp4 with the video and sound from the bik file.

If it is of interest to make the exports from Hellextractor as user friendly as possible it could be interesting to implement ffmpeg into the tool, possibly with a video file format flag (mp4, mkv etc).

Some bik video files are without sound, so not sure if those have sound separated out due to them being played back separately in engine.

Mostly affects .unit files. Seems like the code believes there's no more data, but there should be 100+mb of additional data.

Describe the Feature

Removes the need for people to manually enter a xorpad.bin for tools like wwiser. Bank headers (BKHD chunks) are "encrypted" from 0x8-0x10 with this key: ACBC1192387010A3 that is xor'd with the data in the bank to get the proper info for tools to work on them.
Example: Init.bnk (9ba626afa44a3aa3: content/audio/Init.bnk) Before: 20BC11921B4AD6F3 After: 8C000000233AC650

Describe the Feature

This heavily relies on the completion of #1

Windows Defender identifies hellextractor.exe as Trojan:Win32/Wacatac.B!ml
File: hellextractor.zip->Hellextractor.exe

It would be good to prevent using files or conversions that makes this error happen, as it doesn't make the file seem trustworthy.

Everything about the .unit file structure.

Known Information

• X is Up, forward is either Z or Y
• Vertex Data:
  • Types:
    • 0: Position
    • 1: Color or Normal
    • 4: Texture Coordinates
    • 6: Unknown
    • 7: Unknown
  • Formats:
    • 2: float32[3]
    • 26: uint8[4] or sint[4]
    • 29: float16[2]
    • 24: Unknown
      • Only seen together with type 6 or 7. Usually no space left at this point.

Related links:

• https://reshax.com/topic/507-helldivers-2-model-extraction-help/

Describe the Feature

With the recent few commits, Hellextractor now works on Linux with seemingly no issues. Might be useful to have a linux binary as well now. Flatpak seems to be a decent option here.

Width: 4 bytes