OPTIONAL C++ BUYER INTEGRATION EXAMPLES This source is a local teaching inventory adapter, not a complete bag or equipment system. Blueprint-only customers do NOT need these files or a C++ project: use the included BP_CatalogExample and its Blueprint provider interface instead. Use your own game module 1. Start with YOUR existing C++ game project. Find its Source/ directory. 2. Copy DISBuyerInventoryComponent.h to that module's Public folder and DISBuyerInventoryComponent.cpp to its Private folder. Do not copy any .uplugin, module entry point, private test harness or generated build directories. 3. In the header replace DISBUYEREXAMPLE_API with YOUR module's export macro. For a module named MyGame this is MYGAME_API. This is a source-copy substitution in your own game, not an edit to DialogueInteractionSystem's C++ core. 4. Add "DialogueInteractionSystem" to your module's PublicDependencyModuleNames in its existing Build.cs. Preserve the dependencies and game module already there. Core, CoreUObject and Engine are also required. See BUILD-RULE-SNIPPET.txt. 5. Build YOUR editor target with the supported engine. Add DIS Buyer Inventory Component to your own local-player manager actor or Player Controller Blueprint. Keep that owner alive while it owns units. This example is local and session-only. First successful connection 6. Turn on Show Plugin Content in the Content Browser. Open DialogueInteractionSystem Content > DialogueInteractionSystem > Examples > DA_BuyerItems. Its package path is /DialogueInteractionSystem/DialogueInteractionSystem/Examples/DA_BuyerItems. Duplicate it into YOUR project's Content folder (for example DA_MyItems), or create a Data Asset of class DISItemCatalog. Open the copy and expand Items. Add an entry with Stable ID Buyer.Potion.10027, your display name, YOUR own mesh, optional icon and physical settings. Stable IDs are permanent keys, not display labels. 7. After the player is possessed, call Connect Catalog on your component, passing that local Player Controller and your catalog. Check its bool and Failure. Call it once/session; duplicate connection or catalog registration refuses. 8. Call Spawn One from YOUR button/gameplay event with that Stable ID and a safe world transform. One call creates one unit. The example adds no automatic spawn and changes no hotkeys. Use normal interaction to pick the visible unit up. 9. Units is the example's temporary array. Select Carried Unit with the exact actor belonging to the chosen unit, then Place Selected or Drop Selected. Invalid selection does not fall back to another bag item. Check each bool result. 10. Starting placement keeps the inventory unit. Cancel Placement retains it. Successful placement/drop calls the provider's one-unit release at commit. Physics flags depend on the item definition; visual settling requires play-test. Minimal event wiring for this optional native component 1. Your manager's Begin Play: get the possessed local Player Controller, then call Connect Catalog on DIS Buyer Inventory Component with DA_MyItems. If possession is not ready at Begin Play, call from your existing player-ready event instead. 2. Branch on Connect Catalog's return value. On false, display/log Failure and stop; do not spawn or treat a duplicate registration as success. 3. Create a SEPARATE buyer-owned button/gameplay event for Spawn One. Pass Buyer.Potion.10027 and your chosen safe world transform. Do not wire spawning directly into Begin Play unless your game deliberately wants that behavior. 4. Check Spawn One's returned actor. On null, display/log Failure; on success retain the exact actor/instance association for your own UI. No new key binding is added. 5. Approach the world actor and pick it up normally. Select that carried actor before calling Place Selected or Drop Selected; check their return values too. Connect your real inventory instead of the teaching array Try Accept Item: validate YOUR capacity/rules, add exactly one unit, then return true. Can Release Item: read-only check for YOUR equipped/locked/reserved restrictions. Try Release Item: recheck and remove one authoritative unit only at actual commit. Replace the example operations; do not also run them alongside your real bag. False means nothing changed; true means the synchronous transfer already finished. Do not Delay, destroy actors, re-enter DIS transactions or call asynchronous storage from these callbacks. Queue unrelated follow-up work after the callback returns. Other integration points Try Equip Item intentionally refuses. YOUR equipment adapter owns slots, visuals, fitting, animation, stats and rules. This kit does not implement combat/equipment. Resolve Table Placement Item returns an explicitly selected eligible carried actor. Register your table as a placement surface using a catalog definition or Register Placement Surface, then set the local DIS Dialogue Subsystem's Table Inventory Provider to your component. Existing eligible registry items may be considered before its fallback resolver; do not rely on a hover to reserve or consume stock. For inventory-only items use Create Carried Catalog Item with your registered ID and provider; associate the representation with one EXISTING inventory unit. Creation is not a grant. Your inventory schema/virtual stacks remain YOUR game. State and removal notifications On Observed Item State is for UI refresh only, not a second inventory grant. On Representation Removed reports Instance ID, Definition ID and Was Carried even when the actor can no longer be read. Remove stale UI references by unique ID. Make UI removal idempotent if observing both events. Neither event should re-enter an item transaction. EndPlay removes the subsystem observation binding. The example discards stale actor references; YOUR game decides saved-unit recovery. Destroying a provider does not silently transfer its units to the demonstration bag or a new provider. Deliberate session reconstruction/reconnection needs your policy. Optional action connection Copy DISBuyerActionComponent.h/.cpp into the same buyer module and replace the header export macro as above. Add the component and a DISInteractableComponent to YOUR actor. On the interactable select Custom Action, set both IDs, and disable Auto Complete Demo Action. After local possession call Connect Action with the local Player Controller and that actor's interactable. Check Return Value/Failure. Accept Requests chooses a local teaching success/refusal. Defer Completion leaves one request pending: YOUR system then calls Finish Request or Cancel Request. Finish Request's return acknowledges completion; Succeeded is your result. The sample counter commits only after acknowledgement. Real transactions need YOUR reservation/rollback on late results. On Observed Completion is an observer, not a second reward grant. Disconnect Action cancels pending and removes only this component's bindings; an explicit later reconnect is allowed. EndPlay disconnects. Optional logical equipment connection Copy DISBuyerEquipmentComponent.h/.cpp as well as the two inventory files into YOUR module, updating each export macro. Add DISBuyerEquipmentComponent instead of the plain inventory component; do not connect both to the same unit. Use its inherited Connect Catalog, Spawn One and Select Carried Unit. A successful public Hold Demo Item request dispatches TryEquipItem to this provider. Equipped Unit points to the same owned actor. The example has one logical slot and refuses a repeat/occupied slot without a second grant. CanReleaseItem vetoes equipped units. Call Unequip Unit with that exact actor, check its bool/Failure, then use normal Drop Selected or Place Selected. Destruction clears the matching instance reference. Replace the sample slot transaction with YOUR rules, attachments/meshes, animation and combat. Unequip does not remove a unit from inventory or destroy its actor. Scope All six .h/.cpp files are optional human-readable teaching source, without a plugin descriptor, module entry point or private test harness. They are not automatically compiled into DialogueInteractionSystem. Blueprint customers use the editable BP_CatalogExample, BP_EquipmentCatalogExample and BP_CustomActionExample instead. No save/load, multiplayer authority, crafting, production inventory or equipment is supplied. Keep your catalog/assets cooked and test the packaged game as well.