try PlayerController->SetInputMode
Thanks, I did try that. I should be more specific. When the mouse is not pressed down, it works fine, but when I press it down, the mouse can move a little, but is pulled back constantly towards where I first clicked, as if there is a tick function or something overriding its location.
Hey, sorry about that. Turns out that this is somehow caused by using the function “Set Input Mode Game and UI” and has nothing to do with this plugin.
Hello!
Has anyone integrated this Dialogue Plugin with a quest system?
Any suggestions?
you can grant quests through events with parameters, what I suggest is keeping quest definitions in data table and use row id when granting it. Gameplay tags are pretty useful for tracking quest progress.
1 Like
The plugin doesn’t seem to be working with the gamepad if you use CommonUI (ie., when the viewport client class is set to CommonGameViewportClass). I sort of assume that inputs are being routed in a way that the dialogue widget doesn’t recognize and was hoping somebody could suggest a fix. (Or perhaps CommonUI versions of the widgets are floating around somewhere…?) I imagine that I am missing something that would be blindingly obvious to an actually competent UI programmer! Sorry to bug you: I absolutely love Dialogue Plugin but CommonUI cures so many headaches…
In Unreal Engine 5.4.4 I noticed this was happening.
So I tired switching the widget over to the show/hide method of displaying widgets. Create it once, then only change the visibility. As opposed to creating the widget every time. That ended up just created more headaches.
After some more searching I finally happened across a post that mentioned a “garbage collection” node.
So after switching everything back to using the “create widget” method. I added one as follows and everything is working.
I still usually see at least one (no slate widget), but I’m okay with that. As opposed to the pile up that was happening. My entire project is dialogue so I figure this would have been a disaster eventually. Can’t be sure as I couldn’t find any details on “(No Slate Widget)”, and didn’t want to assume. I may not be any good but I do try to practice good garbage collection when I know I need to.
Also I don’t know if this is because of something I accidentally did somewhere or not. But from what I could tell my modifications to the blueprints only change cosmetic things when compared to the “DemoDialogueWidget”.
Hope this helps people from the future.
It’s generally not advised to manually call the GC, it can cause hiccups. PIE was likely leaving those objects in memory for a longer time than a Release build would’ve. If the explicit call to GC cleans up the resources, then it’s proof that there’s no references to those widgets that prevent them from leaving memory, i.e. there’s no memory leak. I’d recommend letting GC do its job on its own terms.
But if you want to clean-up in PIE, e.g. for easier debugging, that’s another matter. You can check if you’re in PIE and force GC to clean up.
Okay thanks for the clarification! That makes a lot of sense, and gives me some peace of mind. It initially didn’t make sense to me because as far as I knew UE was better than that with GC. I just figured something may have changed as things often do. I’ll kick the GC to the curb and monitor things when I do release builds. Thanks again!
Small question. Any chance of getting the ability to group text nodes? Like how you can collapse/expand nodes in BP. Would help a lot to clean up large dialogues. Things can get pretty unruly pretty quick. Especially with long back and forth conversional type stuff that reads more like a script.
I know I could break things up into multiple dialogue files, which I might do in the future. This was just a thought I had while editing a long back and forth.
Could you please tell me how I can end/delete a dialogue that has been started? I don’t want to deal with C++ right now, so I decided to find a workaround. The idea is that I want the NPC to just say one phrase after another, and then the dialogue ends (basically, like getting a quest over the radio). For now, I just set up an event on the last phrase that hides the widget. But how do I destroy the dialogue itself?
Hey, loving the system, but it seems that dialogues are overwriting each other for some reason. I can make multiple dialogues and when opening one of the previous ones, it has some of the later ones dialogue, and it overwrote what was previously written there. Any way to avoid this? Thanks!
Not sure what you mean by collapsing and expanding. Could you show a schematic drawing? Otherwise, breaking them into multiple dialogue files is the way to go.
Looks like you’re adding multiple dialogue widgets on top of each other. In other words, it’s a bug in your code. Add some checks to make sure you don’t do it.
When you add a dialogue to the viewport, save it as a reference in any blueprint, like character.
Then create a dialogue event that gets your player character and calls “remove from parent” on the dialogue reference. It’ll destroy the widget.
It’s not the widgets, it’s the actual “DialoguePlugin.Dialogue” classes themselves (where all of the the dialogue is written and where you write the NPC/PC dialogue and add the events and conditions etc. You know? Where you make a dialogue tree.) The lines I’ve written there are being overwritten with lines I write in another dialogue class, so I completely lose the dialogue I wrote previously.
If I open two dialogue trees, created using this plugins dialogue class, in the editor, sometimes one of the them will take the dialogue from the other dialogue that I’ve opened, and it overwrites its own dialogue with the other dialogues lines. I hope I’m making sense.
I see. Please provide repro steps + what version you’re using.
When you say it happens “sometimes”, could you be more specific? Once per minute/hour/week/month? Could you find a series of actions that reproduce the issue most of the time?
I’m using version 4.26, with the latest version of the plugin available for that engine version. I haven’t been able to pinpoint exactly what it is that causes the issue, but it seems more likely to occur when I duplicate a dialogue class. When I change the dialogue in the duplicated class, the changes (sometimes) apply to the original as well. So far, I haven’t encountered this issue when creating a new dialogue class for each dialogue, so I’ll stick to doing that for now. I’ve been using the plugin for just over two weeks and have experienced this problem around 10 times or so. I apologise, I can’t get more specific than that as I randomly work on the dialogue whilst doing other work.
Thanks for the info, I tried reproducing it in 5.4, but couldn’t make it happen. Maybe it’s even an engine bug, who knows. I haven’t changed any major logic in years.