It's been a while since I tested an early version of this game. Does the current version have controller support? (Xbox controller, ps5 controller)

WOOOOOO ITS NSFW FRIDAY

Feedback on the Current Dialogue Trigger Blueprint System Hello team, I wanted to share some constructive feedback on the current dialogue placement system being used for the camp area. The recent work on making dialogues easier to place via a drag-and-drop Blueprint is a solid step forward, and the goal of supporting both trigger-box and NPC interaction activation is exactly the right direction. That said, the current implementation has some structural issues that will become increasingly difficult to maintain as more dialogues are added across the camp and future areas. Current Implementation Right now, the system relies on a Blueprint that can be dropped into the level. Designers assign a dialogue asset and choose how it should activate (via trigger box or interaction). The Event Graph currently contains two separate entry points: An On Interactable Event path An On Component Begin Overlap path Both paths feed into a series of Branch nodes that check various conditions (including an “Is Player” check, a “Trigger Automatically” boolean, and an “Extra Bool” used to prevent the dialogue from firing more than once). Once the conditions pass, the graph calls Get Narrative Component → Begin Dialogue, then sets the Extra Bool to true. This approach works for a first iteration, but it introduces several problems that will scale poorly. Issues with the Current Approach Redundant and hard-to-read logic Multiple Branch nodes are stacked in a way that makes the flow difficult to follow at a glance. The same kinds of checks are being repeated across two different entry points, which increases the chance of bugs when one path is updated and the other is not. Fragile one-time trigger system Using a local “Extra Bool” to prevent the dialogue from replaying is not robust. It does not persist cleanly across level reloads, does not scale well when multiple instances of the same dialogue type exist, and is disconnected from Narrative’s own state-tracking tools. Unnecessary runtime checks The “Is Player” check on every overlap event is inefficient. This can be handled entirely through collision channel settings so the event only fires when the player enters the volume. Tight coupling and limited reusability The current design is an Actor Blueprint rather than a more flexible component. This makes it harder to attach the same dialogue-trigger behavior to existing NPCs or other actors without duplicating logic. Maintenance cost As more dialogues are placed throughout the camp (and later areas), any change to the trigger rules will require carefully updating this increasingly tangled graph. This will slow down both designers and programmers. Recommended Improvements A cleaner architecture would significantly improve both usability and long-term maintainability. Here are the key changes I recommend: 1. Introduce a Trigger Type Enum Create an enum called something like EDialogueTriggerType with the values: Overlap Interact Both Expose this as a public variable on the Blueprint. This single setting can control which events are active, eliminating the need for two parallel, partially duplicated execution paths. 2. Collapse the start logic into a single reusable function Create a function (e.g., TryStartDialogue) that contains the core logic: Check whether this dialogue has already been played If not, call Begin Dialogue Mark it as completed Both the Overlap and Interact events simply call this function after a quick enum check. This removes almost all of the current Branch spaghetti. 3. Use Narrative’s built-in state tracking Instead of a local Extra Bool, use Narrative’s conditions (such as “Has Completed Task” or Node Visited). This keeps dialogue state consistent with the rest of the Narrative system and survives level transitions more reliably. 4. Improve collision setup Configure the trigger box/sphere so it only generates overlap events with the Player channel. This allows the “Is Player” check to be removed entirely. 5. Consider converting this to an Actor Component Making the system a component rather than a full Actor would allow it to be added to any existing NPC or volume with minimal setup, further reducing duplication. Expected Benefits Much cleaner and more readable Event Graph Easier for designers to place and configure dialogues Lower risk of bugs when adding or modifying dialogues Better integration with Narrative’s existing tools Significantly lower long-term maintenance cost as the camp (and future areas) grow The current drag-and-drop concept is good. With the structural improvements above, it can become a robust, scalable system that supports the full journey through the camp without becoming a maintenance burden. I’m happy to help implement or prototype the cleaner version if that would be useful. Looking forward to your thoughts. Best regards.