CrimsonCommon
CrimsonCommon is the one shared layer the whole Crimson suite is built on. It holds contracts - interfaces and data types that let plugins talk to each other without depending on each other - plus the foundation pieces every game needs: replicated tag stacks, a message bus, the CommonUI layer system, modular Actor/Player base classes, and the logging macros. It contains no game logic: nothing here implements a feature, it only defines the shapes features agree on.
Two ways to read this
Use the Blueprint / C++ / Both switch at the top of the window. Blueprint readers get editor screenshots; C++ readers get code; Both shows everything side by side.
What's included
| Area | Key Types | Purpose |
|---|---|---|
| Tag Stacks | FCrimsonTagStackContainer, FCrimsonFloatTagStackContainer | Replicated (GameplayTag -> count) maps on a FFastArraySerializer - ammo, charges, stacks, buildup |
| Ability bridge | UCrimsonAbilitySet, FCrimsonAbilitySet_GrantedHandles, ICrimsonAbilitySystemOwner | Grant a bundle of abilities/effects/attributes, and revoke it - across plugins, with no GAS-plugin dependency |
| Interaction contracts | ICrimsonInteractableTarget, ICrimsonInteractionInstigator, FCrimsonInteractionOption, FCrimsonInteractionQuery | The data + interfaces the interaction system speaks (the runtime scanner lives in CrimsonInteraction) |
| Messaging | UCrimsonMessageSubsystem, ECrimsonMessageMatch | Tag-routed, struct-typed message bus - a dependency-free drop-in for GameplayMessageSubsystem |
| Context menu | UCrimsonContextAction, UCrimsonContextActionGatherer, ICrimsonContextActionProvider, ICrimsonContextActionContributor, UCrimsonContextActionPlayerComponent | Server-validated action menu contracts (Use / Drop / Lock / Open...): one shared gather path, actions resolved by stable id + occurrence, tri-state availability, and server-side anti-cheat hooks |
| UI foundation | UCrimsonPrimaryGameLayout, UCrimsonGameUIPolicy, UCrimsonUIExtensionSubsystem | CommonUI layer stack + UI extension points - replaces the CommonGame/GameUIManager plugins |
| Modular actors | ACrimsonModularCharacter / Pawn / PlayerController / PlayerState / GameMode / GameState / AIController | Game-Feature-extensible base classes - replaces the ModularGameplayActors plugin |
| Player layer | UCrimsonCommonGameInstance, UCrimsonCommonLocalPlayer, UCrimsonUserSubsystem, UCrimsonSessionSubsystem | Login / privilege / session plumbing - a self-contained port of Epic's CommonUser |
| Input contracts | FCrimsonChordRequirement, ECrimsonGamepadSensitivity, ICrimsonInputBindingProvider | Shared input types so CrimsonInput and CrimsonSettings agree without a cross-plugin dep |
| Teams contract | ICrimsonTeamAgentInterface, FOnCrimsonTeamTagsChangedDelegate | Team/faction membership interface (the full system lives in CrimsonTeams) |
| Utilities | UCrimsonTagLabelSettings, ECrimsonDisplayablePerformanceStat, FCrimsonAsyncMixin, CRIMSON_LOG_* | Tag display names, perf-stat enums, async loading mixin, and the project-wide logging macros |
| MCP tooling (editor) | UCrimsonMCPSettings, FCrimsonMCPToolRegistrar, TCrimsonMCPTool | The master switch + low-level base for exposing a plugin's editor tools to AI agents over MCP (in CrimsonCommonEditor) |
Plugin dependencies
| Type | Name |
|---|---|
| Crimson | None - CrimsonCommon is the root of the suite; it is the only plugin with no sibling Crimson dependency |
| Engine plugins | GameplayAbilities, ModularGameplay, EnhancedInput, CommonUI, OnlineSubsystem (+ OnlineSubsystemUtils) |
| Engine modules | Core, CoreUObject, Engine, CoreOnline, GameplayTags, GameplayTasks, AIModule, UMG, NetCore, CommonInput, DeveloperSettings |
The Cardinal Rule
No Crimson plugin may depend on another Crimson plugin - except this one. When two plugins must communicate, the contract lives here and each side talks to the interface, never to the other plugin. See Concept: Decoupling Patterns.
Where to go next
- New here? Start with Quick Start - swap in the modular base classes and replicate your first shared type end to end.
- Need a specific task? See the How-To pages (grant an ability set, make an actor interactable, broadcast messages, push UI, add a context action, set up logging, add MCP tools).
- Want the mental model? Read the Concept pages (decoupling patterns, modular actors & player layer, tag stacks & replication).
- Looking up a signature? Jump to API Reference.