Concept: The Integration Layer

Every Crimson Fab plugin compiles and ships alone: it depends on no other Crimson plugin, not even CrimsonCommon. Each type has exactly one owning plugin. When a feature needs two plugins at once - an inventory item in a UI context menu, an ability set granted by equipment, the camera lock-on driving motion warping - the code that joins them lives in CrimsonCore, under Source/CrimsonCore/{Public,Private}/Integration/<Plugin>/.

How the plugins expose themselves

What CrimsonCore installs

Forwarding events onto the message bus

Plugins no longer broadcast on CrimsonCommon's UCrimsonMessageSubsystem. For projects that want one global channel tree, bind the plugin's native delegate and re-broadcast; UCrimsonCorePartyMessageForwarder is the worked example.

#include "Messaging/CrimsonMessageSubsystem.h" // CrimsonCommon
#include "Party/CrimsonPartySubsystem.h"          // CrimsonTeams

PartySubsystem->OnPartyMessageNative.AddUObject(this, &ThisClass::HandlePartyMessage);

void UMyForwarder::HandlePartyMessage(FGameplayTag Channel, const FCrimsonPartyMessage& Message)
{
    UCrimsonMessageSubsystem::Get(this).BroadcastMessage(Channel, Message);
}

Waiting for a plugin to be ready

Components added by Game Feature actions arrive after their owner. Wait on the owning plugin's feature state rather than binding in BeginPlay; CrimsonCore may also use UCrimsonExperienceManagerComponent::CallOrRegister_OnExperienceLoaded* directly.

#include "Components/GameFrameworkComponentManager.h"
#include "CrimsonInventoryTags.h"

if (UGameFrameworkComponentManager* GFCM = UGameFrameworkComponentManager::GetForActor(Owner))
{
    Handle = GFCM->RegisterAndCallForActorInitState(Owner, CrimsonInventory::SystemReadyFeatureName, FGameplayTag(),
        FActorInitStateChangedDelegate::CreateUObject(this, &ThisClass::HandleInventoryReady), /*bCallImmediately*/ true);
}
// Params.Implementer is the inventory manager. Unregister with UnregisterActorInitStateDelegate(Owner, Handle).