ESOMod:DAT File Contents

The following is a brief description of the kinds of files found within the various DAT files. Note that the following information is based on initial beta tests and may be out of date.

 

ESO0000.DAT Sub-File Formats
This archive contains two file types that start with the magic bytes of:

:* FA FA EB EB -- Compressed sub-file data.
:* FB FB EC EC -- Index data for the compressed sub-files.

The index file always follows immediately after the compressed sub-file in the DAT file with the exception of the first file with file index 000000 which has no following index and appears to contain duplicate information from another sub-file.

List of Client Public Builds Datatypes
Exhaustive and up to date as of 6.3.6 minus very last ones that are acceptable guess yet require definitive confirmation
Enum values reflect 1:1 both mnf ID system for these and actual ingame enums. And are rather stable in between non major version (stable from 5 to 6 excluded, 6 to 7(U30) excluded and so on)
As usual, enums are either shuffled voluntarily or as other collateral effect every new major version (so this have low chance to be valid at 7.X or U30)
 

Getting Game Definition MNF Entry
Entry existence is rather consistent yet is not requiring actual existing definition file so expect inconsistencies when a definition is obsolete or not present in public build.
 
    uint64_t DefEnums::DFT::GetClientGameDataFileId(unsigned short DataType, int FileType)
    {
        FileType = filetype>=1;
        return ((uint64_t)(FileType | 0x60000000u)  =1;
        return ((uint64_t)(FileType | 0x60000000u)  
Filetype is Either 0 or 1, being what EsoExtractData call respectively "EsoFileData" versus related "EsoIdFile" if I recall correctly.
Usually will only be of any use the 0x0 one, as 0x1 type is expected to be related index and nothing more (again, Game history has proven such theory to have unexpected exception, even if this is now made cleaner each game update).
Correspondance in EsoExtractDataFormat for relevant entries (file index might not be up to date)
 

Compressed Sub-File Format
The general layout of this file is a short header followed by multiple sub-files/records each with a short header followed by zLib compressed data. All data in this file is in Big-endian byte order.

:* Header (16 Bytes)
::* dword MagicBytes = 0xFAFAEBEB
::* dword Unknown1 = 0x00000011
::* dword NumRecords (0-271024)
::* dword Unknown2 = 0x00000004
:* (0...NumRecords) Sub-File Data (variable size)

Each sub-file has the format:
:* Header (12 bytes)
::* dword UncompressedSize1
::* dword UncompressedSize2 (always the same as UncompressedSize1)
::* dword CompressedSize
:* byte CompressedData[CompressedSize]; (always starts with 78 9C)

The format of the uncompressed data varies but it usually (always?) starts with a 4 byte ID/Index which uniquely identifies the record.


Index Sub-File Format
The index sub-file contains a short header followed by 0 or more 8-byte records. All data in this file is in Big-endian byte order.

:* Header (20 bytes)
::* dword MagicBytes = 0xFBFBECEC
::* dword Unknown1 = 0x00000004
::* word Unknown2 (usually 0x0001, sometimes 0x0011)
::* dword Unknown3 = 0x00000011 (same as Unknown1 from the sub-file data header)
::* dword Unknown4 (same as Unknown2 from the sub-file data header)
::* dword Unknown5 (takes on a wide range of values)
::* dword NumRecords (always the same as the NumRecords from the matching sub-file data)
:* (0...NumRecords) RecordData (8 bytes each)
::* dword Index = Uniquely identifies the record in the sub-file data, same as the first 4 bytes in the uncompressed sub-file dataq
::* dword Offset = Offset to the start of the sub-file data from the beginning of the file.