Concept: Connecting Crimson Plugins

Every Crimson plugin works on its own. None of them depends on another Crimson plugin - not even CrimsonCommon - because Fab builds and ships each plugin alone. When you own two or more plugins, you connect them in YOUR project (or with CrimsonCore, the free integration example), never by making one plugin depend on another.

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).

Doing it yourself (without CrimsonCore)

1. Put the glue in YOUR game module (or a small project plugin) that lists both Crimson plugins in its Build.cs. Never add a Crimson dependency to a Crimson plugin.
2. Bind the plugins' delegates (...Native in C++, the BlueprintAssignable twin in Blueprint) and call the other plugin's public API from the handler.
3. Wait for readiness with ModularGameplay: RegisterAndCallForActorInitState(Actor, <Plugin>::SystemReadyFeatureName, FGameplayTag(), ...); for the experience, the GameState feature Crimson.Experience.Loaded.
4. Where a plugin exposes a hook, setting or extension point (for example FCrimsonActionBarIntegrationHooks, UCrimsonInventorySettings::ItemInstanceClass, UCrimsonGameplayAbility::Extensions), plug your own implementation in there.
5. If you gate pawn setup on HaveAllFeaturesReachedInitState, register the plugins' Crimson.SystemReady.* states after your last init state, or the gate will wait forever (CrimsonCore does this in UCrimsonCoreInitStateSubsystem).