Skip to main content
Frosty Toolsuite is built on a modular architecture designed to load, modify, and manage Frostbite engine game assets. The system consists of three primary layers: the SDK layer, the Core layer, and the Plugin layer.

​
Core Components

The architecture is built around several key managers that coordinate asset handling:

FileSystem

Manages game file paths, catalogs, and data sources

AssetManager

Tracks and manages all EBX, RES, and chunk assets

ResourceManager

Handles CAS/CAT archive reading and decompression

PluginManager

Loads and coordinates plugin extensions

​
System Layers

​
SDK Layer (FrostySdk)

The SDK layer provides low-level access to Frostbite data structures and file formats. Key Classes:
  • FileSystem - Path resolution and catalog management (FileSystem.cs:58)
  • AssetManager - Asset tracking and modification (Managers/AssetManager.cs:440)
  • ResourceManager - CAS/CAT archive handling (Managers/ResourceManager.cs:10)
  • TypeLibrary - Runtime type information system
  • ProfilesLibrary - Game-specific configuration profiles
Responsibilities:
  • Reading and writing Frostbite file formats (EBX, RES, chunks)
  • Managing game catalogs and superbundles
  • Handling asset compression/decompression
  • Providing game profile abstraction

​
Core Layer (FrostyPlugin/FrostyCore)

The Core layer builds on the SDK to provide editor and mod management functionality. Key Classes:
  • PluginManager - Plugin discovery and lifecycle (PluginManager.cs:18)
  • FrostyProject - Project file management (FrostyProject.cs:16)
  • App - Application-wide state and managers
  • Config - User configuration and settings
Responsibilities:
  • Plugin system and extensibility
  • Project save/load operations
  • Asset modification tracking
  • UI framework integration

​
Plugin Layer

Plugins extend functionality through well-defined extension points: 
// Example: Asset Definition Plugin
[RegisterAssetDefinition("TextureAsset", typeof(TextureAssetDefinition))]
public class TextureAssetDefinition : AssetDefinition
{
    public override void GetSupportedFileTypes(List<string> extensions)
    {
        extensions.Add(".dds");
        extensions.Add(".png");
    }
}

​
Data Flow

1

Initialization

FileSystem loads layout.toc and catalogs to build the game file index
2

Asset Loading

AssetManager reads superbundle TOC files and populates asset registries
3

Data Access

ResourceManager retrieves compressed data from CAS archives
4

Modification

AssetManager tracks changes and maintains modified asset state
5

Export

FrostyProject serializes modifications to .fbproject or .fbmod files

​
Asset Management Architecture

The AssetManager maintains three primary registries:
Entity data stored in ebxList dictionary:
private Dictionary<string, EbxAssetEntry> ebxList = 
    new Dictionary<string, EbxAssetEntry>(StringComparer.OrdinalIgnoreCase);
private Dictionary<Guid, EbxAssetEntry> ebxGuidList = 
    new Dictionary<Guid, EbxAssetEntry>();
Provides lookup by name (case-insensitive) or GUID.

​
Modification Tracking

Frosty tracks asset modifications at multiple levels: Asset States:
  • IsAdded - Asset created by user
  • IsModified - Asset or linked asset has changes
  • IsDirty - Asset has unsaved changes
  • HasModifiedData - Asset data has been altered
ModifiedAssetEntry Structure: 
public class ModifiedAssetEntry
{
    public Sha1 Sha1;              // Hash of modified data
    public byte[] Data;            // Compressed modified data
    public object DataObject;      // Deserialized object (EBX/Resource)
    public long OriginalSize;      // Uncompressed size
    public bool IsDirty;           // Has unsaved changes
    public List<Guid> DependentAssets;  // Asset dependencies
}
From AssetManager.cs:326.
The system uses a lazy modification approach - assets are only fully loaded and deserialized when accessed for editing. This keeps memory usage low even with large game files.

​
Cache System

Frosty maintains a cache to speed up subsequent loads: Cache Contents:
  • Asset registry (EBX/RES/Chunk lists)
  • Bundle and superbundle structure
  • Asset metadata (type, size, location)
  • Dependency graphs
Cache Invalidation: The cache is regenerated when:
  • Game version changes (patch detection)
  • Cache version mismatch
  • Profile changes
  • Cache file corrupted or missing
Cache files are stored in Caches/{ProfileName}_*.cache.

​
Profile System

Profiles provide game-specific configuration: 
public class Profile
{
    public string Name;           // Internal identifier
    public string DisplayName;    // User-facing name
    public int DataVersion;       // Game version ID
    public string Deobfuscator;   // Deobfuscation strategy
    public string AssetLoader;    // Asset loading strategy
    public List<FileSystemSource> Sources;  // Data paths
}
Profiles are stored in compiled Profiles.bin and loaded via ProfilesLibrary.cs:12.

​
Thread Safety

Most AssetManager operations are NOT thread-safe. The UI layer must ensure operations are serialized or use appropriate locking when accessing assets from background threads.

​
Next Steps

Frostbite Engine

Learn about Frostbite file formats and structure

Asset System

Understand EBX, RES, chunks, and bundles

Plugin System

Extend Frosty with custom plugins

Build docs developers (and LLMs) love

Get started for freeTalk to us