Assets - Tkachov/ALERT GitHub Wiki
Summary
Assets are pieces of data stored in game's archives. They are similar to normal files, but, unlike them, there could be multiple assets with the same filename. Such variants are stored in different spans, and there could be only one variant of the same asset in each span. Different variants could represent localized assets (voices or subtitles for different languages) or just store complementary data (SD and HD versions of the same texture).
Despite having a filename, assets are typically referenced by their ID. This ID is a CRC64 of filename, which is why it's also called "asset's hash" sometimes. In ALERT, to reference exact variant of an asset, /{span}/{ID} notation is used, with span being decimal integer and ID being hexadecimal uppercase. For example:
| Filename | CRC64 of filename | ALERT reference |
|---|---|---|
| localization/localization_all.localization | BE55D94F171BF8DE |
/0/BE55D94F171BF8DE |
All assets' IDs are listed in toc, and it also stores information on where to find data that corresponds to those assets. Data is stored in archives, which are files next to 'toc', and names of those files are also stored in 'toc'. Some archives could be compressed with DSAR. In SO, assets could also be duplicated in different archives (probably to increase lookup/access speed). In modding, 'toc' is tweaked so it looks for existing assets in new archives, or to know about new assets, that were not present in game before. Since RCRA, archives are named like "actors" and assets of corresponding type are stored together in such archives.
Most of the assets in game are wrapped into DAT1 format. Assets of different type — such as .model or .texture — have different sections in their DAT1, which store different information according to their type. Magic — first 4 bytes of the asset — helps identify asset's type.
Not all of the assets are wrapped into DAT1. For example, .movie assets are just renamed .bik, Bink Video. And, there is a special type of assets, wems — Wwise audio files. Those don't have a real filename, and thus their asset IDs are not CRC64, but simply wem number in hexadecimal. As number is 32-bit, this means one half of asset ID is 0. However, a few most significant bits of asset IDs are used as flags, so wems' asset IDs end up looking like E000000000036B29 (meaning the original wem number is 0x36B29 = 224041).
Some statistics for assets in games can be found on Assets Reports page.
Magic = version?
Even though all assets with the same extension used to have the same magic (in MSMR, MM, RCRA), it seems that this actually is not asset type, and instead a field that indicates version. For example, magic for .material in RCRA has changed from 7C7BD7D6 to 88730155 in one of the updates, and it was found that both are CRC32 of commit message-like string:
| CRC32 | Message |
|---|---|
7C7BD7D6 |
kBuiltMaterialBaseVersion: 134-abezrati: Revamp FX Lighting - V1, kBuiltShaderVersion: 116-rfernandez: Updated calculations in managed buffer raw view handler that are used in RT material hit shaders |
88730155 |
kBuiltMaterialBaseVersion: 134-abezrati: Revamp FX Lighting - V1, kBuiltShaderVersion: 117-hvonck: Reverted a VFX fix integrated during the VFX overhaul, which breaks VFX dependent on the broken behaviour |
This can also explain why some assets have the same magic (such as .animset and .performanceset, or .conduit and .config), and why it might be a bad idea to rely on this magic value as asset type indicator. Instead, we probably should use extension or dag type value.
Types
| dag type* | Extension | Description |
|---|---|---|
| 0 | .level | Not researched enough. Obviously, describes "level". There's only one level in SO, MSMR, MM and RCRA (despite latter having different planets, and warehouses/buildings separate from open world in MSMR/MM). |
| 1 | .zone | Not researched enough. Describes hexagon (?) tiles that worlds consist of. Probably lists actors that should be present in a zone, with some triggers or whatever. |
| 2 | .actor | Not researched enough. Describes game actors, with their components, references to models, etc. |
| 3 | .conduit | Not researched enough. |
| 4 | .config | Binary JSON-like structures holding data. There are different types of configs, with different structure they allow. Possibly, original structures are described using DDL. |
| 5 | .cinematic2 | Not researched enough. Possibly, describe cut-scenes' camera and actors movement, as well as actors spawns and other actions. |
| 6 | .model | Stores different model data, such as submeshes, LODs, geometry, skeleton, shapekeys, references to materials, etc. |
| 7 | .animclip | Not researched enough. Stores base state, frames deltas, "custom tracks", "triggers", morph data. |
| 8 | .animset | Not researched enough. Stores references to animclips. |
| 9 | .material | Not researched enough. Stores reference to material template, shader, texture and scalar parameters' values. |
| 10 | .materialgraph | Not researched enough. Stores shader, texture and scalar parameters' values. |
| 11 | .texture | Stores DDS-like pixels data, with a custom header (that should be enough to reconstruct DDS header). |
| 12 | .atmosphere | Not researched enough. Determines environment settings, such as lighting and cubemap. |
| 13 | .visualeffect | Not researched enough. Particles and other VFX? |
| 14 | .soundbank | Stores Wwise .bnk and some other audio-related data. |
| 15 | .localization | Stores text keys and corresponding localized values. |
| 18 | .zonelightbin | Not researched enough. |
| 19 | .levellight | Not researched enough. |
| 20 | .nodegraph | Not researched enough. Used somewhat like visual programming to define missions order? |
| 22 | .wwiselookup | Not researched enough. |
* — byte value used in dag's $\color{#A0266B}{◆}$ Asset Types section.
Pages for types contain information about sections used in assets of that type. Just like in files, pages start by linking the code that works with them. It works, so it's the most precise documentation there is.