Skip to main content
The Frosty Toolsuite plugin system allows you to extend the editor and mod manager with custom functionality. Plugins can add asset editors, context menu actions, custom handlers, and more.

What Can Plugins Do?

Plugins extend Frosty’s functionality by:
  • Custom Asset Editors - Create specialized editors for game asset types
  • Asset Definitions - Define how assets are displayed, imported, and exported
  • Context Menu Actions - Add right-click actions in the Data Explorer
  • Menu Extensions - Add custom menu items to the editor
  • Custom Handlers - Handle special processing for specific asset types
  • Execution Actions - Run code before/after mod execution
  • Type Editors - Provide custom UI for editing specific data types

Plugin Architecture

Plugins are .NET assemblies (DLL files) placed in the Plugins/ directory. The PluginManager discovers and loads plugins at startup.

Plugin Lifecycle

1

Discovery

The PluginManager scans the Plugins/ directory for DLL files at startup.
2

Loading

Assemblies are loaded and their attributes are read to determine what extensions they provide.
3

Startup Phase

Startup-level extensions are registered (profiles, type overrides, global type editors).
4

Initialization Phase

After a game profile is loaded, game-specific extensions are registered (asset definitions, editors, custom handlers).

Load Types

Plugins have two load phases controlled by the PluginLoadType enum: Startup - Loaded before any game profile:
  • Profiles
  • Type overrides
  • Global type editors
  • Startup actions
Initialize - Loaded after profile selection:
  • Asset definitions
  • Custom handlers
  • Menu extensions
  • Tab extensions
  • Context menu extensions
  • Execution actions

Plugin Manager Types

Plugins can target different parts of Frosty:
public enum PluginManagerType
{
    Editor,      // Frosty Editor
    ModManager,  // Frosty Mod Manager
    Both         // Both applications
}
Most attributes accept a PluginManagerType parameter to control where the extension loads.

Core Classes

From ~/workspace/source/FrostyPlugin/Plugin.cs:8:
public class Plugin
{
    public string Author { get; }         // From PluginAuthorAttribute
    public Assembly Assembly { get; }     // The loaded plugin assembly
    public string Name { get; }           // From PluginDisplayNameAttribute
    public string Version { get; }        // From PluginVersionAttribute
    public PluginLoadStatus Status { get; }  // Load success/failure status
}

Example Plugin Structure

A typical plugin project structure:
MyPlugin/
├── Properties/
│   └── AssemblyInfo.cs          # Plugin metadata and registrations
├── MyAssetDefinition.cs         # Asset definition class
├── MyAssetEditor.cs             # Custom editor
└── MyPlugin.csproj

Getting Started

Create a Plugin

Step-by-step guide to building your first plugin

Asset Editors

Learn to create custom asset editors

Custom Actions

Add context menu items and commands

Attributes Reference

Complete plugin attribute reference

Plugin Discovery

From ~/workspace/source/FrostyPlugin/PluginManager.cs:139:
foreach (string item in Directory.EnumerateFiles("Plugins", "*.dll", SearchOption.AllDirectories))
{
    FileInfo fileInfo = new FileInfo(item);
    m_plugins.Add(LoadPlugin(fileInfo.FullName, PluginLoadType.Startup));
}
The PluginManager recursively searches for all .dll files in the Plugins/ directory and its subdirectories.

Profile Validation

Plugins can specify which game profiles they support using attributes:
// Only load for Star Wars Battlefront II
[assembly: PluginValidForProfile((int)ProfileVersion.StarWarsBattlefrontII)]

// Don't load for Anthem
[assembly: PluginNotValidForProfile((int)ProfileVersion.Anthem)]
Without these attributes, plugins load for all profiles by default.

Next Steps

Creating Your First Plugin

Follow the step-by-step guide to create a functional plugin with a custom asset editor

Build docs developers (and LLMs) love